The Mythical Man Month Correspondence

For some time I've had some correspondence that I wanted to keep but wasn't sure where to - so this seems like a sensible place - all thanks to Andy Walmsley:

The trigger:

You may recall that in some earlier documentation on software projects and their challenges - produced for the E-Strategy Board - I referred to Fred Brookes' book on "The Mythical Man Month" which outlines the problems that arise - and which often makes projects overrun or go over budget.
These points are summarised here - http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Nick Shelness, former Chief Technology Officer at Lotus and now IBM Fellow and Lotus Fellow, has recently provided an update to Fred Brookes' experiences - based on his own. It's an 18 min presentation here - http://media.inf.ed.ac.uk/jamboree/2007/shelness.wmv

And a response

1. Unless we're talking about a completely unworkable and ridiculous
set of requirements, the "change challenges" (what a project really is when it's on the ground and running) presented to the project will never in and of themselves be the cause of complete ruination. They may introduce delays, but these can be managed enabling the project to stay on course and come to a successful conclusion.

2. Of crucial importance to the success of any project is communication. The project team (including the project manager) *need* to communicate every day for five minutes. All each person needs to say is what they did yesterday and what they intend to do today, nothing more complex than that. Any further discussion between individuals takes the form of breakout meetings after the main one has dispersed. Stakeholders should be informed immediately of problems or queries and fully engaged in their solution. Communication of this nature has been right at the core of every successful project that I have worked on. Lack of communication has been a major factor in every unsuccessful project that I have worked on. Of all the projects that I have worked on, I know of none that have been defeated solely by the change challenges that have been presented to them.

3. As a corollary of the above, it's all about the people and not the technology, the timescales or the particular management methodology. Any sensible change challenge can be overcome if everyone on the project is fully engaged, communicating effectively, and feels that their input and work are valued.

4. Following on from the two points above, the seeds of success or failure are often sown very early on in a project, though it may be days, months or years before anyone realises this. One of the most insidious forms of project failure can be seen in a scenario where communication either never starts, is not effective, or does not continue. In this case, the project can appear to be progressing very well right up to the point where it crashes into the buffers and the entire train gets derailed with extreme prejudice. The flip side of this is that if effective communication between all stakeholders is stated as one of the major goals of the project and adhered to religiously, the true state of the project is fully revealed on a daily basis and all stakeholders can take action to correct problems as and when they arise. Constant minor course corrections are infinitely preferable to trying to turn the thing round in its own length at the 11th hour.
Indeed, the former is generally always possible to achieve whilst the latter may prove to be impossible.

And another response:

A project with a completely ridiculous technical remit (fly to Mars using a ZX 81 as the guidance computer), a foolish deadline (here's some CDs, replace SAINT in a week), or a team with completely unsuitable skills (we're going to ask the accounts department to write the new finance system in C without any training at all) will always fail no matter how good the communication is.

Given a level playing field, regular (very regular) communication is the key to project success. It's all about managing change in tiny increments. In all projects (and, indeed, all aspects of human endeavour), the devil is in the detail and we ignore that detail at our peril. Thus, matching the atomicity of communication with the atomicity of the detail in tasks at hand is crucial. Daily communication between the members of the project team and (where necessary) other stakeholders serves to keep that detail under constant illumination. It also keeps all members of the project team within their comfort zones by helping them to understand exactly where the project is.

Beyond effective and timely completion of the project, there are many other advantages. This understanding provides control and a sense of control reduces stress. The corollary of course is that little or no control can cause great stress within the workplace. I often wonder whether organisations that "enjoy" high levels of sickness absence due to stress and its related maladies are failing at their communications and inadvertently robbing their staff of a sense of control (this is a complex issue though - there are many other factors to consider here). Notwithstanding, perhaps another simple equation could be increasing control = happier employees, thus happier employees = more engagement, and more engagement = higher productivity and a better end result.

Interestingly, the whole communications thing is just as applicable to ongoing operational issues as it is to work that is happening in the context of a project.