- Protecting the People Constraint
- Protecting the Time Constraint
- Protecting the Scope Constraint
- Protecting the Budget Constraint
- Protecting the Resource Constraints
- Local Safety
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Protecting the Budget Constraint
The budget for a development project is very important. If it is underestimated, money may run out and the project will fail to deliver. Failure to have enough money may result in a broken promise. Exceeding the budget represents another broken promise. Broken promises are bad for business.
Budget is buffered with money. It is that simple. How much money is needed? Once again, the size of the buffer will depend on the uncertainty. General operating expenses have a low uncertainty. Generally, the cost of the developers and their immediate overheads for office space and other costs are relatively predictable. A buffer will be needed to cope with technology and subject matter uncertainty. In other words, the larger the time buffer, the larger the budget buffer must be.
A budget buffer is needed to cope with time overrun, that is, use of the time buffer. More may be needed to cope with unforeseen costs related to technology or subject matter.
For example, if it is discovered that the team will have to invent a whole new class of middleware in order to meet the requirements, the project has been landed with some unforeseen work to meet nonfunctional (architectural) requirements. Perhaps, it is discovered that the team will need a new, expensive development tool, or the team chooses to buy components or mid-dleware to save time and reduce risk. Technology uncertainty or risk reduction can result in extra budget demands.
When the subject matter for a new software product is poorly understood, the estimate of its complexity may be in error. As the scope is investigated during analysis and design, an area of the requirements may prove to be much more involved than previously thought. This may result in the estimate of the inventory in the system increasing. I call this discovering of unseen inventory, the revealing of scope "dark matter." Dark matter is the stuff of the universe that is known to exist, but cannot be seen or measured. Every project has a degree of dark matter. The newer the subject matter, the more dark matter there is likely to be. If the project is a Human Resources Management system with a team that has done it all before, the chance of a significant mistake in the scope and inventory estimate is unlikely. However, if the project (writing in 2003) is a leading edge wireless, enterprise resource planning system designed to run over a public packet data network delivering ERP to mobile employees in a distributed B2B value chain, then it is new territory. The need for a budget buffer to cope with uncertainty is very important.