Schedule, the Eternal Enemy

“More projects have gone awry for lack of calendar time than for all other reasons combined” - Frederick Brooks, The Mythical Man-Month. 

These words were penned by Frederick Brooks in “The Mythical Man-Month” over 35 years ago.  Think back to that time for a moment.  The first personal computers were being born as kits assembled by electronic hobbyists.  Serious programmers considered them to be toys.  A good knowledge of COBOL could get you a job just about anywhere.  Computers and IBM were virtually synonymous.  Structured programming was the process improvement silver bullet of the day.  Something called ARPANet, the parent of the Internet, had come into existence.  And software projects experienced serious problems because they weren’t given enough time to complete and test their work.  Everything has changed except for the last item.

Why?

Over this span of time a host of solutions have been attempted with very modest results.  Only the elephant in the living room has been ignored:  since project schedules are chronically and habitually underestimated, why not allocate more time to them at the outset?  The reasons for doing so are compelling:

• Projects grow over time.  Part of this comes from new requirements being added on and can be addressed with a good change management system.  The other, less visible part comes from what I call Project Dark Matter.  As a project progresses from concept through design into implementation we learn a great deal more about what has to be done to complete it.  Almost always, this translates into more work to be done.  The details of this work only become known through the learning; they cannot be known in advance.  Since they are there, the responsible thing is to plan for them. 
• Building in extra time on the front end will not cost you more on the back end.  Actually, it will cost you less.  Yes, less, because you can complete the work with fewer people.  Go ahead and model this with your favorite parametric estimation tool (we, of course, prefer SLIM-Estimate).  Notice that I used the words “plan” and “in advance”.  They’re crucial.
• The delivered product will have better quality.  Now quality, at least in the Business IT world, gets lots of lip service.  Unfortunately, we usually try to test it in rather than build it in.  Testing is important.  However, a project that is under schedule pressure normally shortchanges testing, and under time pressure, developers make more mistakes.  If the product is being developed for an external customer, poor quality may result in new sales that don’t occur and a tarnished reputation.  Ashton Tate, the developer of the ill-fated dBase IV, is the textbook example of the high cost of poor quality:  they went out of business.  If the product is for internal use, poor quality may compromise the work it was intended to support while costing more to maintain than a project with fewer defects.

There are a host of reasons why optimal schedules exist (and why compressing a project’s schedule is a bad idea).  They make for an interesting study.  However, if we could just get the decision makers to learn from the past and plan for the future based on that experience, many cost, quality, and schedule problems would never occur.