I was surprised to see a reference to Fred Brooks’ 1975 classic, The Mythical Man Month(1), in a recent blog post(2); it was suggested as required reading for those involved with fixing the problems with healthcare.gov. The blog focused on the idea that throwing additional staff at a floundering project is likely to make things worse.

For those unfamiliar with Brooks’ classic work, it presents lessons learned from his time as manager of the OS/360 development effort. I’m probably telling more about myself than I should, but I have a dog-eared copy in my personal library and think it should be a must read for all IT project and program managers. The book covers a host of risk management topics, most of which are as relevant today as they were almost 40 years ago.

Estimation: Consistent application of an estimating discipline that considers performance on prior projects is key if the risk of delivering projects over budget and behind schedule is to be avoided. Brooks highlighted the importance of considering the amount of time likely to be spent on administrative and other non-technical tasks rather than focusing exclusively on technical activities. He also argued that testing involves a greater percentage of project effort than managers and developers typically estimate at the outset. While estimating discipline doesn’t change the level of effort or time required to deliver results, it does provide a more reasoned view of what you can expect.

Progress tracking: Actively tracking and reporting project progress not only provides a primary source of data for future project estimates but also reduces the risk of major project delays and overruns. Defining interim milestones and monitoring progress against them is critical to success.  To paraphrase Brooks, “major project delays don’t happen at once, they happen one day at a time”.

Communication: While software development methodologies have evolved significantly since Brooks’ days, the need for stakeholders to have a common understanding of project objectives, core requirements, deliverables to be produced and key roles and responsibilities has not. Minimizing project delivery risks requires communication and documentation. Yes, documentation, the bane of most IT staffers, has an important role to play in successful project delivery.

Staff skills and experience: One of the healthcare.gov development challenges that has been widely discussed in the press is the lack of a cohesive design; one that could accommodate the high number of users expected and enable delivery of a positive user experience. Some have suggested that the government would have done better by seeking assistance from top tier technology firms rather than relying on their traditional service providers. In The Mythical Man Month, Brooks cites the importance of conceptual integrity (i.e. design integrity) and the use of expert resources to lead both the overall design effort and the development of critical components.

Change management: On large projects where requirements changes are inevitable and design changes are a distinct possibility, a formal change management process is a critical requirement. On time, on budget delivery of a quality solution is jeopardized when the potential for change is not acknowledged and the process for handling changes is not clearly defined. Effectively planning for and managing change are themes that run throughout Brooks’ classic work.

While advancements in technology have enabled the delivery of many products and services that were unthinkable 30+ years ago, advances in project and program management discipline have lagged far behind. It seems that some of the lessons documented in The Mythical Man Month have yet to be learned.

Do you have any lessons learned from IT projects that aren’t listed here? Tell us about it in the comment section below. And as always, if you’re having difficulty with an IT project, we’re here to help. Get in touch.

References

(1)Brooks, Jr, F. P. (1975). The Mythical Man Month, Essays on Software Engineering. Massachusetts: Addison-Wesley.

(2)Yglesias, M. (2013). Obamacare's "Man Month" Problem.