An issue that occurs in many organizations that adopt the CMM is an unreasonable focus on meeting schedule.  At a previous employer, which was certified at CMM level 3, there were huge penalties for being even a day late.

This myopic focus on reliable schedules gets pushed down from the top-level management to the middle management and finally to the project managers (PMs).  The PMs then tell their project team before the project starts that they cannot be late.  Now most people are very smart people, and will adjust their behavior according to what is measured. 

So the tech lead calls his developers together, and they come up with a high (for them) estimate.  Say the estimate for a web-based survey application is 40 man-days.  The tech lead then doubles this, telling the PM that it will take 80 man-days.  The PM then triples this, committing to a schedule of 160 man-days.  This may seem like a contrived example, but I have taken the exact multipliers from a real life company.

Taking the median consulting rate for all types of consultants for this purely contrived example (rates for 2002 available at Realrates.com), $75 per hour, the web-based survey is going to cost $96,000 even though the developers could be really close to getting it done with only $24,000.  This is also applicable to in-house corporate development, since internal IT divisions always have a billing rate to develop cost estimates.

The funny thing is, everybody in the steering committee (which meets to decide which projects get funded and which do not, also known as a program management board) knows the estimates are very high, but if they force a PM to reduce an estimate, the PM will record it somehow that the estimate is not achievable.  Nobody on the steering committee wants that, since they have just gotten into a contest to see how slowly the development team can work.  And the developers are always up for this short of behavior if it means “getting back at management.”

The only person that loses is the customer that wanted an inexpensive web-based survey in about 2 months.

The problem is that the developers’ 40 man-days estimate was likely a 50 percent estimate.  In other words, they were sure that they could finish the project in 40 days on average.  Technical problems might come up, and it would take longer.  But due to Parkinson’s law, tasks (or projects) will rarely, if ever, be finished sooner.  This kind of estimating is more like a 95 percent estimate.  The developers are relatively sure, except in the case of a meteor shower (or regional blackout), that they will finish on time.

This is exactly what we wanted, right?  Except that the developers don’t think any given task will take as long as the task’s estimate, so they don’t start until the amount of time left is equal to the 50 percent estimate anyway.  And then if something comes up, the schedule is impacted.

The answer to this in agile software development is to do short iterations of fixed time and quality with variable scope.  This idea is not new; it was introduced under the term “timeboxing” as early as 1988.  Here, instead of penalizing developers if they miss the schedule, they are rewarded if they can fit in more functionality.  Of course there will be times that the functionality has to be reduced if there is a particularly nasty technical snag.  But with a strong working relationship, perhaps cemented by a couple iterations of solid performance, a customer should be amenable to reduced functionality if they see genuine effort on the part of the developers.