cost_management

COST MANAGEMENT Submitted By: Ashwath Rao(56) Satish Bhagwat(7) Chakravarthi(52) Govardhan(53) Sai Charan(50) Gopichand(51) Ashwin Guntur(5) Project Cost Management Cost management is the process whereby companies use cost accounting to report or control the various costs of doing business. The term CM is widely used in business today. Unfortunately there is no uniform definition. We use CM to describe the approaches and activities of managers in short run and long run planning and control decisions that increase value for customers and lower costs of products and services. For example, managers make decisions regarding the amount and kind of material being used, changes of plant processes, and changes in product designs. Information from accounting systems helps managers make such decisions, but the information and the accounting systems themselves are not cost management. Cost management has a broad focus. It includes – but is not confined to – the continuous reduction of costs. The planning and control of costs is usually inextricably linked with revenue and profit planning. For instance, to enhance revenues and profits, managers often deliberately incur additional costs for advertising and product modifications. Cost management is not practiced in isolation. It’s an integral part of general management strategies and their implementation. Examples include programmes that enhance customer satisfaction and quality as well as programmes that promote blockbuster new product development. Learning Objectives • • • • • • • Understand the importance of good project cost management Explain basic project cost management principles, concepts, and terms Describe how resource planning relates directly to project cost management Explain cost estimating using definitive, budgetary, and rough order of magnitude (ROM) estimates Understand the processes involved in cost budgeting and preparing a cost estimate for an information technology project Understand the benefits of earned value management and project portfolio management to assist in cost control Describe how software can assist in project cost management The Importance of Project Cost Management • • • IT projects have a poor track record for meeting cost goals Average cost overrun from 1995 CHAOS study was 189% of the original estimates; improved to 145% in the 2001 study In 1995, cancelled IT projects cost the U.S. over $81 billion What is Cost and Project Cost Management? • • • Cost is a resource sacrificed or foregone to achieve a specific objective or something given up in exchange Costs are usually measured in monetary units like dollars Project cost management includes the processes required to ensure that the project is completed within an approved budget Project Cost Management Processes • • • • Resource planning: determining what resources and quantities of them should be used Cost estimating: developing an estimate of the costs and resources needed to complete a project Cost budgeting: allocating the overall cost estimate to individual work items to establish a baseline for measuring performance Cost control: controlling changes to the project budget Basic Principles of Cost Management • Most CEOs and boards know a lot more about finance than IT, so IT project managers must speak their language – Profits are revenues minus expenses – Life cycle costing is estimating the cost of a project plus the maintenance costs of the products it produces – Cash flow analysis is determining the estimated annual costs and benefits for a project – Benefits and costs can be tangible or intangible, direct or indirect – Sunk cost should not be a criteria in project selection Cost of Software Defects When Defect is Detected User Requirements Coding/Unit Testing System Testing Acceptance Testing After Implementation Typical Cost of Correction $100-$1,000 $1,000 or more $7,000 - $8,000 $1,000 - $100,000 Up to millions of dollars It is important to spend money up-front on IT projects to avoid spending a lot more later. Resource Planning • • The nature of the project and the organization will affect resource planning Some questions to consider: – How difficult will it be to do specific tasks on the project? – Is there anything unique in this project’s scope statement that will affect resources? – What is the organization’s history in doing similar tasks? – Does the organization have or can they acquire the people, equipment, and materials that are capable and available for performing the work? Cost Estimation Tools and Techniques • 3 basic tools and techniques for cost estimates: – analogous or top-down: use the actual cost of a previous, similar project as the basis for the new estimate – bottom-up: estimate individual work items and sum them to get a total estimate – parametric: use project characteristics in a mathematical model to estimate costs Typical Problems with IT Cost Estimates • • • • Developing an estimate for a large software project is a complex task requiring a significant amount of effort. Remember that estimates are done at various stages of the project Many people doing estimates have little experience doing them. Try to provide training and mentoring People have a bias toward underestimation. Review estimates and ask important questions to make sure estimates are not biased Management wants a number for a bid, not a real estimate. Project managers must negotiate with project sponsors to create realistic cost estimates Cost Budgeting • • • Cost budgeting involves allocating the project cost estimate to individual work items and providing a cost baseline For example, in the Business Systems Replacement project, there was a total purchased cost estimate for FY97 of $600,000 and another $1.2 million for Information Services and Technology These amounts were allocated to appropriate budgets as shown in next slide Cost Control • Project cost control includes – monitoring cost performance – ensuring that only appropriate project changes are included in a revised cost baseline – informing project stakeholders of authorized changes to the project that will affect costs Earned value management is an important tool for cost control • Earned Value Management (EVM) • • • EVM is a project performance measurement technique that integrates scope, time, and cost data Given a baseline (original plan plus approved changes), you can determine how well the project is meeting its goals You must enter actual information periodically to use EVM. Earned Value Management Terms • • • The planned value (PV), formerly called the budgeted cost of work scheduled (BCWS), also called the budget, is that portion of the approved total cost estimate planned to be spent on an activity during a given period Actual cost (AC), formerly called actual cost of work performed (ACWP), is the total of direct and indirect costs incurred in accomplishing work on an activity during a given period The earned value (EV), formerly called the budgeted cost of work performed (BCWP), is an estimate of the value of the physical work actually completed Earned Value Calculations Rules of Thumb for Earned Value Numbers • • Negative numbers for cost and schedule variance indicate problems in those areas. The project is costing more than planned or taking longer than planned CPI and SPI less than 100% indicate problems Earned Value Chart Project Portfolio Management • • Many organizations collect and control an entire suite of projects or investments as one set of interrelated activities in a portfolio Five levels for project portfolio management – Put all your projects in one database – Prioritize the projects in your database – – – Divide your projects into two or three budgets based on type of investment Automate the repository Apply modern portfolio theory, including risk-return tools that map project risk on a curve Using Software to Assist in Cost Management • • • Spreadsheets are a common tool for resource planning, cost estimating, cost budgeting, and cost control Many companies use more sophisticated and centralized financial applications software for cost information Project management software has many cost-related features Balancing effort/cost against benefit/quality and risk By now, you may have gathered enough ideas and information to form a recommendation about the estimated time and effort for the project, but is your client organisation interested in bartering or gambling? The effort you put in can be balanced against the benefit you expect and the level of risk you are willing to accept. You would probably put much more effort into defining, building and testing an algorithm to calculate the fuel required for a manned mission to Mars than you would for the fuel required to drive to the next city and back. Suppose you could deliver 80% of the overall benefit for only 20% of the effort - but with twice the risk of failure. Would your client organization accept that? This is a particularly important consideration with eProjects where the imperative is to deliver rapid benefits. It is common to address the 80% of normal customer needs that can be met in a simple manner and ignore the 20% of difficult situations that would take much more effort. Often, you might ignore non-standard orders, error handling, cancellations, etc and leave those processes for manual intervention. The COCOMO model    Developed at TRW, a US defense contractor Based on a cost database of more than 60 different projects Exists in three stages o Basic - Gives a 'ball-park' estimate based on product attributes o Intermediate - modifies basic estimate using project and process attributes o Advanced - Estimates project phases and parts separately Project classes    Organic mode small teams, familiar environment, well-understood applications, no difficult non-functional requirements (EASY) Semi-detached mode Project team may have experience mixture, system may have more significant non-functional constraints, organization may have less familiarity with application (MODERATE) Embedded Hardware/software systems, tight constraints, unusual for team to have deep application experience (HARD) Basic COCOMO Formula    Organic mode: PM = 2 .4(KDSI )1.05 Semi-detached mode: PM = 3(KDSI )1.12 Embedded mode: PM = 3 .6(KDSI )1.2 KDSI: thousands of delivered source instructions M: project complexity multipler -- initially 1.0 PM: person-months Effort estimates COCOMO -- Time to Develop    Organic mode: TDEV = 2 .5(PM )0.38 Semi-detached mode: TDEV = 2 .5(PM )0.35 Embedded mode: TDEV = 2 .5(PM )0.32 TDEV: time (months) to develop Note that TDEV does not depend on number of people assigned. COCOMO examples   Organic mode project, 32KLOC o PM = 2.4(32)1.05 = 91 person months o TDEV = 2.5(91)0.38 = 14 months o N = 91/14 = 6.5 people Embedded mode project, 128KLOC o PM = 3.6(128)1.2 = 1216 person-months o TDEV = 2.5(1216)0.32 = 24 months o N = 1216/24 = 51 peoples COCOMO assumptions    Implicit productivity estimate o Organic mode = 16 LOC/day o Embedded mode = 4 LOC/day Time required is a function of total effort NOT team size Not clear how to adapt model to personnel availability Intermediate COCOMO    Takes basic COCOMO as starting point Identifies personnel, product, computer and project attributes which affect cost Multiplies basic cost by attribute multipliers which may increase or decrease costs Drivers of effort There are many other factors that will influence the effort it takes to deliver a successful business solution. Let's finish up with an inventory: People   Process Strength of sponsorship Availability of good resources for the project team Organisational resistance to change Organisational complexity Organisational culture Morale Local cultures Ease of communication Number of locations involved Number of departments to be restructured Number of staff affected Amount of retraining required Impact on external people or bodies (eg customers, suppliers, regulators)  Technology                    Number and complexity of processes to be reengineered Extent to which processes are intertwined Extent to which the process is within the control of the Project Sponsor (eg dependence on action from external supplier) Degree of improvement required (eg 10% faster is easy; 90% faster will be more of a challenge) Quality of support for these processes from commercially available software products Availability of best practice knowledge concerning the processes within this industry        Functionality of IT system Complexity of the technology to be used Development techniques and languages to be used Use of packaged software or component based technology Amount and complexity of integration and interfacing with legacy systems Familiarity of development staff with the technology to be used Productivity of development staff Desired quality of solution Acceptable risk levels - eg depth of testing required Level of documentation required FUNCTION POINT MODEL The function point metric was devised in 1977 by A. J. Albrecht, then of IBM, as a means of measuring software size and productivity. It uses functional, logical entities such as inputs, outputs, and inquiries that tend to relate more closely to the functions performed by the software as compared to other measures, such as lines of code. Marciniak provides a good capsule introduction to the application of function point measurement Function point definition and measurement have evolved substantially; the International Function Point User Group (IFPUG), formed in 1986, actively exchanges information on function point analysis (FPA). The original metric has been augmented and refined to cover more than the original emphasis on business-related data processing. FPA has become generally accepted as an effective way to      estimate a software project's size (and in part, duration) establish productivity rates in function points per hour evaluate support requirements estimate system change costs normalize the comparison of software modules TECHNICAL DETAILS Basic function points are categorized into five groups: outputs, inquiries, inputs, files, and Interfaces. A function point is defined as one end-user business function, such as a query for an input. This distinction is important because it tends to make a function point map easily into useroriented requirements, but it also tends to hide internal functions, which also require resources to implement. To make up for this (and other) weaknesses, some refinements to and/or variations of the basic Albrecht definition have been devised, including     Early and easy function points. Adjusts for problem and data complexity with two questions that yield a somewhat subjective complexity measurement; simplifies measurement by eliminating the need to count data elements. Engineering function points. Elements (variable names) and operators (e.g., arithmetic, equality/inequality, Boolean) are counted. This variation highlights computational function. The intent is similar to that of the operator/operand-based Halstead measures Bang measure. Defines a function metric based on twelve primitive (simple) counts that affect or show Bang, defined as "the measure of true function to be delivered as perceived by the user" . Bang measure may be helpful in evaluating a software unit's value in terms of how much useful function it provides, although there is little evidence in the literature of such application. The use of Bang measure could apply when reengineering (either complete or piecewise) is being considered, as discussed in Maintenance of Operational Systems--An Overview Feature points. Adds changes to improve applicability to systems with significant internal processing (e.g., operating systems, communications systems). This allows accounting for functions not readily perceivable by the user, but essential for proper operation.  Usage Considerations There is a very large user community for function points; IFPUG has more than 1200 member companies, and they offer assistance in establishing a FPA program. The standard practices for counting and using function points are found in the IFPUG Counting Practices Manual. Without some standardization of how the function points are enumerated and interpreted, consistent results can be difficult to obtain. Successful application seems to depend on establishing a consistent method of counting function points and keeping records to establish baseline productivity figures for your specific systems. Function measures tend to be independent of language, coding style, and software architecture, but environmental factors such as the ratio of function points to source lines of code will vary. The proliferation of refinements and variations of FPA noted in Technical Detail has led to fragmentation. To remedy this, a Joint Technical Committee (JTC1) of the International Standards Organization (ISO) has been working since 1993 to develop ISO standards for sizing methods. This standardization effort is now called Functional Size Measurement. Counting the function points needed for FPA remains largely a manual operation. This is an impediment to use. Wittig offers an approach to partial automation of function point counting There are continuing concerns about the reliability and consistency of function point counts, such as   whether two trained human counters will produce the same result for the same system the lack of inter-method reliability resulting from the variations described in Technical Detail These reliability questions are addressed in a practical research effort described in Kemerer . Siddiqee presents FPA as a good measure of productivity in a large software production environment in Lockheed Corporation . Any systematic FPA effort should collect the information into a database for ongoing analysis as the code is developed and/or modified. Maturity FPA is in use in many industrial software companies; IFPUG is large, with more than 1200 member companies, and offers many resources. As noted above, however, an ISO-level standard is still in the making. Costs and Limitations Currently, function point counting is a time-consuming and largely manual activity unless tools are built to assist the process. Wittig and Kemerer cite that it took more than five days to count a 4,000 function point system. However, the level of acceptance by software companies indicates that FPA is useful. Training in FPA is highly recommended; IFPUG can assist in securing training and locating FPA tools .