This chapter is from the book
This chapter is from the book
This chapter is from the book
Protecting the Time Constraint
Every finished product or project has a desired delivery date or a predicted delivery date. A desired delivery date is when the customer asked for delivery. A predicted date is when Engineering (or IT) estimated they could deliver it. The important thing is that a date is agreed upon by the software development organization and the customer. This date is a system constraint. A date gets promised, and it is bad business to break promises.
Sometimes, the delivery date has been set for hard business reasons. For example, a change in government regulations is being introduced, and the new product must be delivered in order for the customer to meet its legal obligations. In other words, the date constraint is imposed from outside the organization and is totally outside the control of anyone in the organization. Such hard delivery dates are common in heavily regulated industries such as investment, finance, banking, tax and audit, telecommunications, power generation, and other public utilities.
If the delivery date is a constraint, it must be protected by a time buffer. The length of the time buffer must be based on the uncertainty involved in the project. The uncertainty must be assessed with respect to the technology, people, subject matter, architecture and delivery environment, the maturity of the organization, and a number of other factors such as the reliability of upstream suppliers.
For example, consider a relatively mature software development organization that might audit as SEI SW-CMM Level 3.1 With a project that looks similar to one just completed, uses the same architecture, has an existing and experienced team, uses the same technologies, and has subject matter well known and understood by the everyone involved, the company might just be 100% certain that the project can be finished on time. In this case, with 100% certainty, I would use my minimum buffer number of 15%.
On the other hand, in a newly formed start-up with a new team, a poor understanding of the subject matter, and a new challenge that requires bleeding-edge technology, it is fairly certain that a lot can and will go wrong. This must be planned for. A good textbook answer for buffering in such a situation would be 200% [Goldratt 1997, p. 46]. In reality, it is only possible to get away with such a buffer, if there is no process maturity and no one making public guesses as to how long the project should take. In many cases, a development manager will find it impossible to gain agreement on 200%. In which case, I would suggest a fallback position of no less than 100%. Table 4–2 shows my rule of thumb numbers for time buffering.
Table 4–2 Certainty and suggested buffer sizes.
|
Certainty |
Buffer Size |
|
100% |
15% |
|
90% |
25%–30% |
|
80% |
50% |
|
50–70% |
100% |
|
-50% |
200% |
fn1The Software Engineering Institute (SEI) based at Carnegie-Mellon University has defined a Capability Maturity Model (CMM) for software engineering organizations—Level 1 being chaohie immaturity through to Level 5 representing optimizing performance.
In order to read this table, you must understand the measure of certainty. Certainty is the percentage likelihood that a task will be completed on time. The 100% certainty implies that similar tasks always complete on time. If only one in every two tasks tends to complete on time, then the certainty would be 50%. In reality, certainty is the gut feeling of the developers who are on the spot. If they feel confident, they may estimate 90% certainty. If they've never seen something before and have no idea how to do it, they are more likely to estimate -50% certainty. For example, if a developer estimates a job as 1 month, with a 40% certainty of completion, then the estimate should ideally be inflated by 2 to 3 months.