- 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 Resource Constraints
Other resources for a software development organization include desktop computers, all servers, network, backup systems, printers, disk storage capacity, paper, meeting rooms, wall space, tables, chairs, desks, water fountains, vending machines, and toilets, to name just a few.
It is important to remember that because software is an innately human activity, the majority of the costs are incurred by the people. If a day is lost from a developer's time because a PC broke down, it is possible that Throughput for the whole system may have been lost. It is, therefore, vital to know where the constraint is within the system of software production. If a developer works in the constraint and produces a unit of production per day and the software production system averages $10,000 of Throughput per unit, then the cost of losing one developer for only one day could be $10,000.
It doesn't make sense to lose development or test resources because of a failure in equipment. It is essential to have enough equipment for everybody and a buffer stock. The team must not lose efficiency because there is no water in the fountain or tissue paper in the toilets.
How many resources are needed in the buffer? Again, this depends on the uncertainty. These days PCs are very reliable. Perhaps you only need one or two spares for a whole business unit. Servers do not seem to be so reliable. Disk drives seem to wear out. Networks can be unpredictable, too. So can the power supply. Is the organization located somewhere that lost its power due to exceptional weather conditions—flood, snow, or ice-storm? Is the location a place where the power grid is unpredictable and brown-outs are common? It is important to protect the most precious resource and the biggest constraint—developers. In order to do so, resources must be buffered.
Classifying Uncertainty
Meyer and colleagues have classified four types of uncertainty: variation, foreseen uncertainty, unforeseen uncertainty, and chaos [Meyer 2002 ]. The types of uncertainty encountered will affect more than just the buffer size for project constraints, they may affect the process or system method employed.
Variation
When tasks, activities, or work units can be classified through analysis and empirical data is available for those classifications, planning is straightforward and the degree of uncertainty is firmly bounded. It is bounded by the variance normally associated with that classification. For example, if it usually takes 4 to 8 hours to produce a Servlet to process an HTTP request, then it takes 6 hours + / - 2 hours. This is variance. It can be planned for explicitly.
Over a statistical sample of items of the same classification, the variance should average out. So, to follow the example, in a project with 500 distinct HTTP requests requiring 500 Servlets, the project manager could expect these to take 3,000 hours.
Foreseen Uncertainty
Foreseen uncertainty is identifiable and understood but may not happen. In the example, the user interface design for a website may have specified 500 HTTP requests. However, it is foreseeable that the UI designer will change the design and the total number of Servlets required will change.
There is far greater uncertainty associated with this problem. For example, a relatively mild redesign may involve 10% of the Servlets required. Some of these may have been coded already, in which case they are waste. When work completed is wasted, the effect is to increase the total amount of work required. There is a greater amount of uncertainty involved in foreseeable uncertainty. Both variation and foreseen uncertainty were classified by Edwards Deming as "common cause" variation, that is, they are endemic to the process.2
fn2Walter A. Shewart called this "controlled" variation [Wheeler 1992 ] page 3.
Unforeseen Uncertainty
This is most likely to occur when a team is pushing the bounds of known technology, such as a team working at the edge of extreme innovation and venturing into research or invention. It is not known, and cannot be known, in advance, if it will encounter a major impediment to its success.
When a team is operating at the edge of the envelope, an even greater buffer for uncertainty will be required.
Chaos
The difference between chaos and unforeseen uncertainty is that a team that encounters unforeseen uncertainty would at least have a firm idea of what it was trying to achieve. Such a team has firm goals and objectives. A team in a land of chaos doesn't necessarily understand what it is doing or where it is going. It could be that the market is not understood and that the potential customers are not even aware they have a need for a product. In this space, everything can change all of the time. Because there is no defined goal, there can be no defined plan.
Deming would classify, unforeseen uncertainty and chaos as "special cause" variation, that is, each event tends to be unique and unlikely to be repeated. Special cause variation is not endemic to the process.3