The 9 topic areas of project management knowledge
Limited financial resources is the one constraint of any project. Costs include the people and equipment who do the work, the materials they use, and all the other events and issues that require money or someone's time in a project.
The project team has to organize the work in oder to to mantain the actions within the budget available.
In project management there are various tools and procedures that help manging costs, like Cost Estimating, Budgeting, Cost and Schedule Control System, Cost Analysis.
See Project planning phase; Project Execution and control
| Process | Project Phase | Key Deliverables |
|---|---|---|
| Cost Estimating | planning |
Project Activities Costs (in word)
|
| Cost Budgeting | planning | |
| Control and Manage Costs
Established in the Project Budget Tasks
|
Execution | Cost Estimates (updates), Cost baseline (updates) |
CPI = EV/AC
EAC = BAC/CPI
ETC = EAC - AC
CV = EV - AC
SV = EV - PV
SPI = EV/PV
VAC = BAC - EAC
See also
For many development projects, the bulk of project costs are tied to staffing. In this case, the best way to estimate project cost is to prepare a detailed project schedule using Microsoft Project (or a similar tool), and to use the resource management features of that software to identify the types, quantities, and phasing of different types of labor.
Project cost estimating is usually performed by summing estimates for individual project elements into a project total. The pieces can vary in size and number from a few large chunks of a project with known costs to hundreds or thousands of discrete tasks or individual work packages.
Bottom-up estimates are often prepared by contractors to support their proposal bid process. This involves using a detailed WBS and pricing out each work package making up the project. This method may be laborious and time consuming, but it can result in a fairly accurate estimate if the work content is well understood.
Top-down estimates use rules of thumb, parametric models, analogies, or cost estimating relationships (CERs). CERs based on historical experience can provide data such as the cost to develop a source line of software or the cost per square foot for a building construction project.
Sometimes project cost goals are a forced-fit to the amount of money available in the budget. This will require the project manager to initiate a cost estimate to find out if the project is feasible. Adjustments in scope may be needed so the project can survive.
"Design-to-Cost" is a process where cost goals for development, acquisition, or operations and maintenance are used as design parameters, along with technical performance, in the systems design trade-off process. In cases where the absolute value of a dollar threshold needs to be contained, the project definition, conceptual design, and development can address performance trade-offs to fit the project within a predetermined cost envelope.
"Cost as the Independent Variable" is an affordability based method for planning project scope. It starts with a fixed budget and works backwards, through an iterative process of prioritizing and selecting requirements, to arrive at a project scope achievable within budget constraints.
Costs can usually be estimated with acceptable accuracy by using relevant historical cost data, a well constructed and documented estimating methodology, and a good understanding of the work content to be performed. This approach involves putting as much detail into understanding the tasks as possible and generating assumptions with whatever shreds of knowledge may be available.
If equipment is to be acquired, a recent analogous vendor quote will be helpful. Experience shows, however, that analogous cost data are often not analogous. For this reason, the cost estimator will want to determine whether configurations are really similar; changes are anticipated; things like start-up, installation, and spare parts are included; and if there are costs left out. These same principles apply to using costs from similar projects or service contracts. Find out what the cost data include and what has been left out. It is sometimes useful to take available cost data and shape it using size and complexity factors to estimate costs for analogous, yet distinctly different, project efforts.
If you estimate only the requirements you are sure of, your estimate will usually be low. If your estimate for the number of source lines of software is uncertain, you may want to add an uncertainty factor to the estimate (15-35%). It may be prudent to add a contingency factor to account for expected changes, or to allocate management reserves to deal with later eventualities.
When a cost estimate is done well, the most likely problems will be: (1) scope left out, (2) not understanding the technical difficulty, and (3) changes.
Cost estimates are done for different reasons, and the purpose of the estimate usually imparts a bias to the numbers. "Marketing estimates" are likely to be low, while good "budget estimates" are likely to be high. When judging the accuracy of an estimate, you need to know the source of the estimate and the purpose for which it was derived. If the estimate was proposed by a project advocate, you may want to use caution before putting those numbers in your budget.
Cost estimates that hinge on assumptions about staff or asset availabilities or schedule dependencies outside the manager’s control should be considered areas of cost risk and managed accordingly.
As a project manager, you need to understand if your cost estimates are sound or if you are buying into an inevitable cost overrun due to under-estimating. The adverse consequence of a cost estimate that is too conservative is that it can kill an otherwise viable project by making it look unaffordable.
Good cost estimating requires a supportive environment in the organization. One way to help this is to develop projects using standard work breakdown structure categories, and then collect actual costs in a historical cost database. A cost database for software, for instance, could be used to collect data related to cost per line of code, software sizing algorithms, costs for function points, or cost data from bottom-up functional descriptions and tasks.
A well-structured cost estimate can become unmanageable after the third or fourth "what-if" iteration unless each change is meticulously documented. Even knowing this fact well, experienced cost estimators are constantly reminded of it when trying to reconstruct or explain cost estimates that were prepared some months or years back. It seems that one can never document a cost estimate too well or record assumptions too thoroughly. An aid to this process is using a PC spreadsheet to prepare your estimate, and then keeping all the important data and adjustment factors visible in cells, rather than hidden in formulas. If the assumptions, factors, and data sources are not obvious in your cost estimate documentation, then it is not done yet.
Put assumptions like uncertainty factors, mark-ups, and quantity multipliers in cells and where they can be accessed globally, then you can do iterations quickly, and your assumptions will be visible for reviewers and clearly documented for future reference. It is sometimes helpful to document your cost estimating methodology in a narrative form. This can help with subsequent reviews and audits, and it can lay the groundwork for developing an organization-wide cost estimating methodology.
When you construct a cost estimating spreadsheet with each cost driving factors in a single cell, it can be used to conduct cost sensitivity analysis. You can vary an uncertain quantitative assumption and the plot it against the range of results. If total project or product cost is relatively insensitive to a given variable, it can be left alone. If the project cost is sensitive to an uncertain assumption, specific efforts should be focused on gathering additional data to lessen that uncertainty.
See also