Introduction
"According to the Standish Group CHAOS Report 2003, each year in the USA there are approximately 175,000 projects in IT application development that spends $250 Billion. Among these, 31.1% of projects will be cancelled, 52.7% of projects will cost 189% of their original estimates, only 52% of required features and functions make it to the released product, and time overruns occur in 82% of the cases. In financial terms $55 billion dollars is wasted in these projects." (Madpat, 2005).This chapter suggests an innovative platform to analyze software projects in order to overcome the difficulties that are shown through the statistics. The first layer of the platform is based on costing theories in order to handle the cost overruns. At the second layer are the project management tools, and on the third layer is the software engineering. The last two layers give the needed information on the project scope and the development efforts. Connecting those three layers gives a better perspective on the projects, which is the best platform for decision making.
Cost management of a project is defined by the PMBOK (project management body of knowledge) (PMI, 2004) as one of the nine core activities of projects management. This activity is defined as an assembly of processes that include planning, estimating, budgeting, and controlling of project costs so that the process will be executed within the budget framework that has been designated for it. However, although it defines costing as a core activity, it does not provide the methodologies for the application mode of the costing (Kinsella, 2002).
The challenge in project management is described as " the effective allocation of resources within the framework of time, cost and delineation constraints that are balanced against the quality demands and nature of relations with the customer" (Kerzner, 2003. p.5). Hence, cost management should be viewed as part of the project management challenge.
Software projects can be analyzed through software engineering tools, CASE (computer-aided software engineering tools), that assist in the analysis and characterization of the software project and in the evaluation and measurement of the work productivity in the project.
Cooper and Kaplan (1998) analyze the integration between costing systems and operational systems. The integration that Cooper and Kaplan introduce, like the classic costing methods, does not provide a response to the project structure and the features of a software project (such as estimation difficulties, risk management, and lifecycle). This chapter recommends integrating costing systems and operational systems of software projects; the projects management tools and the software engineering tools.
The data presented highlights the significance of costing and the difficulties in costing and estimating software proj ects. These difficulties derive both from the implementation's limitations of a costing solution in an intricate and changing technological environment (Wouters & Davila, 2004) and from the unique features of projects in general and software projects in particular. The characteristics that obstruct the solving of the costing problem include the project lifecycle that leads to changing work capacities over time (Kerzner, 2003), uncertainty levels and exposure to risk (Rajkumar & Rush, 2000), and a difficulty in defining an evaluation of the project scope.
Given all this, the conclusion that becomes clear is that there is an objective difficulty in establishing an accurate cost framework for the software project, especially prior to its detailed planning. Such planning is executed through software engineering tools. Those tools assist the analysis of the software project and the estimation and measurement of the project's work productivity (Liong & Maciaszek, 2005).
We have seen that cost management within the software project framework requires the combining of software engineering with the involvement of the development team. However, the development team's ability to be fully involved in the cost management process is limited. The development team and projects managers function in monitoring the changing technological implementation throughout the project, and in the knowledge management of the project team. Hence, the amount of remaining time for the costing activity is small. Moreover, in order to accurately define the cost structure, there is a need for a costing model that includes, in addition to the direct costs of the project, also overhead costs in the organization. Project managers that work on the engineering and technical aspects of the system struggle with obj ectively defining and applying such a model (Wouters & Davila, 2004).
Given this, the chapter presents a model that allows the expression of each and every one of the cost's components (direct, indirect, risk, competitiveness), while it links three areas: project management, software engineering, and managerial accounting. The model will enable not only a retrospective analysis of the economic performances of the project/projects portfolio/software house, but also an in-advance evaluation of costs, economic feasibility, and economic risk level of the project/projects portfolio. The model introduces a new approach in the area of software project costing.
Theoretical Background
This section presents the theoretical and practical foundation for the research model from several aspects. Our objective is to integrate models of software projects with three disciplines: software engineering, project management, and managerial accounting.The first section reviews the foundation for the integration between the financial systems that serve the classic models of costing and other relevant systems.
The second section reviews the link between software engineering and project management. This section will emphasize the importance of the association between software engineering and project management tools as a managerial and costing necessity in the software project (or projects portfolio). In the third section, costing aspects are introduced and integrated. A basic integrative model for this association will be displayed, and we shall examine the extent of its compatibility with the costing need.
Integrated cost systems
In order to make important managerial decisions, detailed costing information is necessary. Detailed costing information is expected to include all types of costs that are required for manufacturing a product or providing a service. These are data that are based on financial systems and contain, in practice, costs that derive from the firms detailed income statement (and backup schedules). These data include the historical execution data and future estimations and forecasts (Needy, 2002).Otley (2001) proposes an integration of accounting and financial data for obtaining execution and evaluation measures. It is suggested that these measures will be supplemented by information that is not financial. The need of nonfinancial information has evolved in recent decades out of the comprehension that the costing analysis is not sufficient for it being an outcome analysis: this has created the need for performance measurement. Such measurement includes the accounting information and costing logic with the incorporation of figures that are not financial. Various models (such as balanced scorecard) deal with performance measurement (Needy, 2002), and provide an additional layer for the need to execute integration between financial and operational systems.
Williams (2004) supports the integration approach in accordance with the viewpoint that a modern accounting system is supposed to supply a framework for strategic management of the company's resources. In order to realize this conception, Williams proposes a multidimensional construct that clusters information from the company's systems on customers base, activity areas, and more, for the purpose of forming an accounting system that facilitates planning, improvement, and control, analysis and regulation of resources, and enhancement of profitability. Such a system is based on integrative information from a number of systems or from the arrays DWH (data where house)/BI (business intelligence) in five areas: costs, assets, quality/ service, time, and outputs.
The pioneers of the combining of financial and operational information are Cooper and Kaplan (1998), who developed the method of activity based costing (ABC) suggest, in light of the technological development of information systems, to define the integration between operational and financial systems for the purpose of building an accurate costing model.
software engineering and project management
The success of a software project depends on five software engineering areas that are related to each other: the development of the lifecycle of the software, process management, the model's configuration and language, software engineering tools, and project planning (Liong & Maciaszek, 2005. p.3). The combining between the formal tools of the software engineering and project management processes in its different stages has been proved by research as to result in a positive contribution to the efficacy of the project, and as an improver of the adherence to costs, technical requirements, and the schedules that were allocated to the project (Verma & Barker, 2003). In this study, the researchers argue that following the combination of the areas, it is difficult to separate the contribution of the software engineering from the total contribution. Hence, an initial support may be assumed for the essentiality of the association between the areas. The integration's foundation that was displayed may be extended since it is impossible to separate the costing activity, which deals with financial values, from the total managerial activity, thus, also for the purpose of cost management (cost execution), the combination between software engineering and project management must be considered.The combining of the areas is described as a comprehensive view of the software development process with the description of the products, resources, schedules, budgets, and the organizational structure that sustains the project. Such a framework provides not only the stages in the planning of the project's monitoring and controlling, but also strategies for managing project's risks (Rajkumar, 2003).
As an anchor for the costing model that will be presented in the study, a model that establishes, in a feasible way, the link between software engineering and the project manager's activities was chosen (Gelbard, Pliskin, & Spiegler 2002). The basis of this study is the mapping between the software engineering, which is implemented by CASE tools and project management tools. The mapping model allows a shift from an engineering description of the realized project, for example, as DFD (data flow diagram), to a description that includes also the project's schedule, which is usually portrayed through Gantt charts. The advantages of such mapping are as follows:
• The evaluation of the effort and costs over time while directly drawing from the engineering basis.
• Extended analysis of costs, time, and resources that also includes engineering parameters, such as complexity and demanded quality.
• Generic fittingness to every type of software project.
• A dynamic controlling of the project's process and evaluations of execution against the planning.
• The ability for "drill down" based both on functionality and intermediate products and on the level of the system's design.
• Integration with the development teams that allows reliable and accurate controlling and estimation.
Despite the model's advantages, it does not encompass project layers, such as an explicit allusion to the project's lifecycle and its risk management (including the cost of the risk). Moreover, the response is given at the single project level and does not reflect effects of project portfolio management, such as indirect costs, transportation of resources between projects, and the like.
On the other hand, the model's application allows an engineering and project insight in terms of time and cost of the project's constituents. Therefore, the gripping on to the model's advantages creates groundwork for the development of a costing model in software projects that will be built on the foundation of integration between the different areas.
cost models and methods
Detailed costing information is expected to include all types of costs that are required for manufacturing a product. Data based on financial systems, which contains costs, derived from the income statement and the estimation of the company's capital and assets, enclosed the historical execution data and future estimations and forecasts (Needy, 2002). Williams (2004) supports the integration approach according to the conception that a modern accounting system is supposed to supply a framework for strategic management of the company's resources. In order to realize this conception, Williams proposes a multidimensional construct that clusters information from the company's systems on customers base, activity areas, and more, for the purpose of forming an accounting system that facilitates planning, improvement and control, analysis and regulation of resources, and enhancement of profitability. Such a system is based on integrative information from a number of systems, or from the arrays DW (data warehouse), BI (business intelligent) in five areas: costs, assets, quality/service, time, and outputs. The pioneers of the combining of financial and operational information are Cooper and Kaplan, who developed the method of activity based costing (ABC) at the end of the eighties. Cooper and Kaplan (1998) suggest, in light of the technological development of information systems, to define the integration between operational and financial systems for the purpose of building an accurate costing model.In light of this, establishment of integration conception required definition not only of an enterprise costing model, but also definition of interfacing between the different areas and systems; that is, interface between SE aspects-tools, financial aspects-tools, and PM tools.
Cost management is a term that is used for a wide description of short-term and long-term managerial activities that are involved in planning and controlling of costs (Horngren, Dater, & Foster 2000). Table 1 presents variety aspects of costing model in a technological projects environment.
Costs analysis within the framework of technological environment must be carried out with the understanding of the project lifecycle.
Table 1. Aspects ofa costing model in a technological project environment
| Aspect | Description | Difficulties | |
| 1. | Planning | Costs estimation of the project and for each resource in the projects portfolio | Defining direct and indirect resources and their costs |
| 2. | Controlling | Costs analysis for each project and executed task | Attributing in-reality-costs to each project's task |
| 3. | TimeLine | Costs analysis over different time periods in planning and execution | Evaluating capacities of resources consumption over specified time periods |
| 4. | Tasks | Identification and costing of project's tasks (WBS items) | Matching the costs to each of the project's components |
| 5. | Overhead Allocation | A precise allocation of indirect costs | Determining the indirect cost generators in project's tasks |
| 6. | Risk management | The inclusion of risk element and its value as part of the costing | Estimating risk on the basis of risk factors in the different tasks |
| 7. | Scenarios | The ability to analyze alternative modes of action and costs | Defining assumptions and alternatives to the mode of cost's calculation |
| 8. | Profitability Analysis | The understanding of the profit that derives from each of the projects and the whole projects portfolio | The inclusion of all the cost factors in the model |
| • 5% | - Conceptualization |
| • 10% | - Feasibility study |
| • 15% | - Preliminary planning |
| • 20% | - Detail Planning |
| • 40% | - Execution |
| • 10% | - Testing and Commissioning |
A reinforcement of the need to include the project's tasks (or the WBS components) in a costing model is intensified in the light of the cost estimations that are founded on work hours' evaluation. It has been argued (Ooi & Soh, 2003) that according to traditional approaches of software costing (time-based estimations), there may be a bending towards time planning without linking it to the specific task and the role player that performs it. Therefore, it is suggested to include the detailing of the tasks (Ooi & Soh, 2003) and/or an elaborate planning of the various project's resources as part of the costing model.
The advantages of the resources' cost analysis throughout activities/tasks: more detailed information for managers, monitoring abilities, analysis of resources' cost and allocation, and a more accurate ability of overhead allocation (Elnathan & Raz, 1999; Jahangir, 2003; Kinsella, 2002; Ooi & Soh, 2003).
Indirect costs (overhead costs) include all types of costs that cannot be attributed directly to a specific task in the project marketing and sales expenses, office supplies, buildings' cost, professional services, information systems, computerization infrastructure, and the like. These costs are only occasionally incorporated in the project planning, but they carry great influence on the profitability of the portfolio and the projects' pricing decisions (Horngren et al., 2000). These costs are described as one of the "major headaches" (Kerzner, 2003). However, in this context, it has been argued that the ability to control costs is largely dependent on the monitoring of these costs.
Table 2 summarizes costing methods according to financial and engineering literature. The table also presents the common evaluation of model compatibility in light of entire costing aspects.
• Analogy: Cost estimation based on previous experience, using case based reasoning techniques (CBR).
Table 2. Costing methods according to financial and engineering literature
| Legend V - Good compatibility X - No compatibility P - Partial compatibility * - Adjustments are required | planning | controlling | Time Line | Task Resolution | overhead Allocation | Risk Management | Scenarios | Profitability Analysis |
| Top Analogy | v * | P* | X | X | P* | X | X | X |
| Software Down Parametric | v * | P* | X | X | P* | p* | v | X |
| Eng. Bottom Function Points | v | X | X | v | P* | v* | v | X |
| Up COCOMO II | v | P | X | v | P* | v | v | X |
| Target Costing | v | P | P | P* | P | X | P | v |
| costing Standard Costing | v | P | v* | v* | p | X | v | P |
| ABC | v | P | P* | X | v | X | v | v |
• Parametric: Cost estimation based on heuristics and thumb's rules (Jahangir, 2003). Similar to the analogy estimation method, a parametrical model is also based on accumulation of historical data of project costs. On the basis of these data, a mathematical model is defined for the prediction of costs (Kinsella, 2002). The level of accuracy of a parametrical model ranges on a wide scope of -25% to +75% (Kerzner, 2003).
• Function Points: A method that was first introduced in 1979 by Albrecht. Its objective is to assess the software system's size while using the user's requirements without direct dependence on the technological realization (Hale & Smith, 2001). The function points method is calculated in three steps, using the quantity and complexity of the functional components and the system attributes (Kemerer, 1993).
• COCOMO (constructive cost model): The model was first introduced in 1981 and since then, several modifications were made in order to suit fourth-generation languages, decrease in hardware costs, increase in QA levels, advanced and agile development methods. Current version, COCOMO 2.0 (Boehm, Clark, Madachy, Horowitz, Selby, & Westland, 1995), is not based upon line of codes, but on four submodels that match a spiral approach of software system development that are applied according to the stage of the lifecycle (The application-composition model, the early design model, the reuse model, and postarchitecture model).
• Target costing: Suits engineering framework in which there are several engineering activities simultaneously, and is utilized as a means for costs strategic management. The idea behind the method is that a product's cost must be based on the sum that can be received for it in the market, and in other words, the development cost should be the basis for the quantity and mode of investment in the development rather then the development's outcome.
• Standard costing: ascertains the cost framework while employing the amount of direct cost components and a standard price that was set for this unit. We shall formulate it concisely:
It should be accentuated that the standard price does not solely include the direct price of the component (price per working hour), and is intended to contain the meaning of the cost or the consumption of indirect resources (rent, computerization, etc.). In the calculation of the standard price, it is customary to rely on known performance data from the past (Horngren et al., 2000).
• Activity based costing (ABC): Is considered as one of the advanced models for predicting costs while incorporating managerial decisions. The model was developed in the eighties, and its main innovation is in the addition of nonfinancial elements to the costing model. The model is widely used in a variety of industries, such as agronomy, banking (Kao & Lee, 2001), and medicine. In the projects area, there is not much literature that discusses the application of ABC, however, there are a few studies that help to understand the method. These studies include the description of the method for software developing and assimilation (Ooi & Soh, 2003), the portrayal of the mode in which ABC can be taken on in projects (Elnathan & Raz, 1999), the implementation of ABC in favor of IT cost analysis in the organization, and a recommendation to include this model in PMBOK (Kinsella, 2002).
THE FRAMEWORK
The model proposes an approach to the integration between the financial systems that include the components of the financial reports and the software tools that serve the project management tools and software engineering tools, such as function points.The model will enable not only an in-retrospect analysis of the economic performances of the project/projects portfolio/software house, but also an in-advance evaluation of costs, economic feasibility, and economic risk level for the project/projects portfolio. The model enables the execution of sensitivity analyses for the purpose of exploring alternatives of planning and organizing (resource utilization, resource transportation between projects, etc.).
costing Framework as a Business process
In order to create a practical framework for costing, we have described the costing framework as a business process. The process combines four types of organization resources: software engineers (stages 1.1-1.3), project managers (stage 2.1), costing economists (stages 3.1-3.2), and managers (stage 4.1-4.2).Figure 1 illustrates the costing activities and collaboration between the personnel:
The connection between the engineering planning and the project managing is based on the "translation" of the engineering planning terms to working hours, engineering complexity description (AFP - Adjusted Function Points) converted to developing efforts (working hours). In addition, on the top of the engineering planning (developing efforts and tasks composition), there are more constraints that derived from the availability of the organization's resources. The project manager is testing the constraints, demands, and costs, and creates the optimal/ultimate GANT project. Those steps connected the managing and planning of the project to the engineering side that takes into account system complexity.
Figure 1. Costing framework as a business process
Thereafter, cost elements (that include direct cost calculations) are being introduced and overhead expenses are thereafter, added (indirect costs of the organization). The overhead expenses are based on the loading key that derives from the direct cost. At the end of this stage, we had for each project a "naive" estimation, namely, a cost that does not depend on political factors (such as require profitability) that find expression at the last stage.
In the final stage, after building the costing structure for the whole project, we have management intervention (with the collaboration of planning factors). Within this framework, management can define the policy for each project according to the project type, the customer, and so on. Political decisions could influence the basics cost structure (costing decisions) and/or determine the profitability level that is necessary for the project (pricing).
This model reflects the integrative framework of the organization, the management, and the project, and raises questions about the effectiveness and applicability level of the model.
conclusions
This work presents the costing of software projects as a business process that collaborates between entities in the organization.Costing models usually have three stages: defining a costing object, cost tracing for direct costs, and cost allocation for indirect cost. Due to the complexity of software projects, these stages are not trivial to comply with. For example, the project life cycle (PLC) and the different tasks in it require the costing object to include several objects (to match the WBS). We have defined the following features for a costing model in order to fulfill its goals. These features are supported by the suggested framework we describe, yet are only partially supported by other known models. They include
• Planning ^understanding and estimating project activities that spread over the lifecycle of the project (project life cycle- PLC)
• Task analysis - The tasks (processes) in each of these stages are described under the work breakdown structure. The WB S represents the required activities for the project's management in a hierarchical structure. For each component of the WBS, an evaluation of direct and indirect (overhead) costs must be included.
• Direct resources,- Derived from engineering requirements, they are the work effort (like programmers) and material (like servers)
• Direct cost - Direct costs are divided into costs of labor (usually work hours multiple by hourly rate) and other direct costs such as materials. It is recommended that these costs will include a managerial reserve. (Jurison, 1999).
• Indirect costs - All types of costs that cannot be attributed directly to a specific task in the project (marketing and sales expenses, office supplies). These costs have a great influence on the profitability of the portfolio and the projects' pricing decisions (Horngren at al., 2000, p.148, 439). Indirect costs are described as one of the "major headaches" (Kerzner, 2003. p. 524). The ability to control costs is largely dependent on the monitoring of these costs.
• Control- An analysis of actual vs. budget and the ability to create forecasts based on planning and partial implementation.
• Timeline - Planning and control activities should take under consideration different types and volumes of activities during the lifecycle. Therefore, the project timeline becomes part of the costing model and its implementation.
• Profitability - Understanding the "bottom line" of the projects. Profitability analysis requires both an allocation of direct and indirect costs as well as revenue allocation.
• Risk analysis - The obj ective of risk analysis is to predict the value of uncertainty (the risk) that is involved in future project activity (Rajkumar, 2003). The literature shows that one of the challenges of a costing system is to introduce and represent risks as part of the costing process (Rajkumar & Rush, 2000).
The major point raised by these requirements is that the costing model should include a variety of cost information supported by different personnel. The advantage of resource cost analysis throughout the project life cycle is the creation of more detailed information for managers, better monitoring abilities, a more accurate analysis of resources, and better control over overhead allocation (Elnathan & Raz, 1999; Jahangir, 2003; Kinsella, 2002; Ooi & Soh, 2003).
key terms
Activity Based Costing (ABC): A cost prediction model that has greatly improved the ability to predict a proper allocation of indirect costs among several activities and thereafter, between many products. Before using this model, one has to appreciate and understand the overall business (including its production and marketing). The model is not always applicable: a cost-benefit analysis is necessary before a final decision is made.CASE/AMD Tools: Software tools (computer aided software engineering), also named AMD tools (analysis modeling and design), to assist the entire system life cycle (SLC). This includes the analysis phase, design phase, testing phase, and even maintenance phase. CASE /AMD tools support the functional analysis phase using visual modeling notations, which can automatically be converted into code.
Cost Object: Anything for which cost data are desired. A cost object may be a product or a service. Cost object for projects can include a module, milestone, or a specific task. We recommend defining a cost object for a project as a WBS item.
Gantt Chart: A popular type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates (ES, EF, LS, LF) of entire project elements. Project elements comprise the work breakdown structure (WBS) of the project. Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percentage completion shadings and a vertical "today" line.
Project Cost Management: Defined by the PMBOK (project management body of knowledge) as one of nine core activities of project management. This activity is described as the collection of processes including planning, estimating, and budgeting cost control, so that the project will carry out within the intended budgeting framework
Project Management: A wide discipline that includes the knowledge base and techniques for planning, controlling, and implementing projects. The PMI (Project Management Institute) defines it as follows: "Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements."
Work Breakdown Structure (WBS): A technique for defining and organizing projects' tasks using a hierarchical tree structure. The first level contains one project outcome, and each level describes outcomes in details. Each level must include 100% of the total work (the sum of the work at the "child" level must equal 100% of the work represented by the "parent," and the WBS should not include any work that falls outside the actual scope of the project)