There are all kinds of methods for estimating the cost of software development, based on the hours of effort required to build the system. As Project Managers the fundamental tool available to you is the break the work down and estimate the costs of each activity. Don't attempt to complete the Work Breakdown Structure, break the work down into the components you can foresee. You might want to solicit the help of a business analyst in this exercise. Your estimate will only be as reliable as the amount of information used to derive the estimate.

Development environments, test environments, and a production environment must be considered when costing IT projects. You may have all of these already in place so they won't add to your costs. If not, make certain that you identify all the environments that must be provided to deliver the project. Quality Assurance environments should be separate from the development environment. One of the environments must support integration testing. Other environments to consider are: the Quality Assurance environment, a staging environment, and the production environment. Quality Assurance environments are typically used for testing functionality, not performance or stress. If your system is "mission critical", you should consider a platform for performance and stress testing.

Delivering a project's goals and objectives within a budget cap will involve trial and error. The first pass likely will not yield a plan that fits within the budget, or if it does the budget may be too big or you missed something. As you whittle the budget down and approach the cap, you must ask yourself if the project is still capable of delivering the stated goals and objectives despite the reduction in scope. Risks are something else to be considered. Unless you took a wild guess at the right approach at the outset, any reduction of scope you made to reduce costs will be accompanied by an increased element of risk to the project's goals and objectives. To be feasible, a cheaper alternative must have risk responses identified to handle the new risks. Your project budget must include a budget for managing the risks to your project, so make sure you estimate the costs of the risk responses.

The process of estimating the costs of high level deliverables and activities will yield one of 2 results: either your project can fit within the established budget, or it can't. If you are unable to deliver the goals and objectives of the project within the budget cap, you will need to alert your sponsor immediately. Don't wait for the end of planning phase/beginning of implementation phase.

Some available methods used for estimating cost is Budget Range: Almost the same steps as you used to deal with the hard cap. Use the lower end of the range to put your estimates into context and as you approach mid range, begin to look for areas where scope can be reduced. The approach to reducing scope needs to include the identification of risks and estimates for the risk responses. A budget range provides you with more options when scoping the project. When you have thrown out the "Cadillac" solution because you assumed it would exceed the project budget, you may want to revisit that decision if your estimate is close to the lower bound.

Your budgeting exercise is almost certain to require the same type of reconciliation required for the hard cap so approach it in the same way. Compare the requirement or feature or function under consideration to the project goals and objectives. Does it directly support a goal or objective? Is there a cheaper, more cost effective way to deliver the same functionality? Don't forget to include an estimate for risk responses in the total budget.

No Cap: No budget cap makes the chore of budgeting for the project much simpler. Beware the project with no budget cap however, as organizations can rarely operate this way. If you are not given a budget cap it may be because you are expected to tell your sponsor how much the project is likely to cost and then let them make the decision on whether to proceed or not. If the project is in response to legislation, or there are other compelling reasons for performing the project, you will probably still have some guidelines to follow which will limit your spending. Do your best to have your sponsor state any expectations they have at all about the ultimate cost of the project.

The project scope or schedule will be the top priorities where there is no budget cap for the project. Planning spending for this project will require you to reconcile budget and scope/schedule in a different fashion than for projects with a hard spending limit. The system features and functionality should be more clearly defined in the case where scope is the top priority. They should also be more clearly defined where time to market is the top priority. The difference between these two scenarios is that in the case where features and functionality are the priority, delivering the full set will require the project to take however long it takes to build these. The feature set may have to be pared down where time to market is the driver.

You should have a Rough Order of Magnitude (ROM) estimate of the cost of the project at this point. This estimate should either fit under the stated cap, or within the range you were given for the project. The next step is to continue the breakdown of the work and assign a portion of the budget to each deliverable or task in the Work Breakdown Structure.

Budgets should be managed no differently on IT projects than on any other project. The reason that budget management is so challenging for project managers on these projects is that, typically the project manager of the project is not accountable for the budget and frequently does not even have insight into how that budget is assigned or tracked. Money is typically assigned from operational budgets to perform the project and responsibility for the money and tracking of expenditures is done at the operational level. The result of this disconnect between financial oversight and the project manager is that budgeting for project activities and measuring the project's performance to budget are not done in any formal way, and frequently are not done at all.