This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
Plenty of projects, if not the vast majority, end up getting delayed… Some more than twice the initial estimated time and cost. This happened up until 1986, when the book was published, but it still happens today. I feel it is, sadly, very common.
But how does this happen?
How can we prevent it?
When sudden escalations (problems, emergencies) fall onto a project, we have a clear, visible and objective problem to solve. Despite the problem being difficult to solve, it is easy to address.
The problems that are difficult to address are the ones that are not easily visible, the ones that imperceptively but inexorably impact the project schedule negatively, delaying it.
Small stones on our way, like someone needed for a decision is ill, tests take too long to run, delaying all developers several times a day, not enough acceptance servers, meetings that take people out of the work they are really good at and really need to do, etc …
This is what makes the schedule slip, one day at a time.
To control this, Brooks gives us a few guidelines:
- Start by having a schedule with milestones;
- Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness, and it is more important that they are unambiguous than easily verifiable by the boss;
- Do not demean one-day schedule slips, under no excuse;
- Having a clear view of the project milestones dependencies. A PERT map is a perfect example of such a view. This allows us to understand how important a specific schedule slip is;
- The boss must not act on problems his managers can solve, as to not diminish the managers’ authority and foul up their other plans;
- Have a clear distinction between status-review meetings and problem-action meetings. This will contribute to honest status reports from the managers;
- Have a report with the milestones, their estimated completion date and their actual completion date. This will make visible any schedule delays;
- Have someone with no authority (not the boss, nor any manager) be in charge of asking the teams about the completion status of their milestones. This will contribute to more honest and accurate statuses possible. I feel that nowadays having a flat hierarchy is another way of doing this;
@hgraca 