Have any of you read Deadline, by Tom DeMarco? Believe it or not, it is a novel about software project management. I read it years ago, back in the ‘90s, and fell in love with it. The basic premise is that the world’s best project manager is kidnapped and forced to manage a project for some evil person. The project manager is given way too many people for his project, so he decides to split the people into a number of teams and play with different project parameters for each team. Some teams get too many people, some get too few, some get too much work or constantly changing requirements, and so on. Through DeMarco’s eyes, we get to see how the different teams handle their own particular burdens, how it affects their delivery date, morale, and so on. It’s pretty educational and interesting.
- Schedule flaws
- Requirements inflation
- Specification breakdown
- Under performance
Each of these risks can cause a project’s plan to go off track and lead to projects that deliver late, build the wrong thing, waste time, and so on. Fortunately for me, being an Agile consultant, each of these risks is addressed by some aspect of the Agile methods, either directly through one of the 4 Agile principles in the Agile Manifesto, or in one or more of the individual methods.
In the upcoming posts in this thread, I will address one or more of the above risks. I’ll share examples from real projects of how and when they occur; how to know they are happening; and specifically how to mitigate them. Whenever possible, I’ll discuss metrics that are useful in measuring the effect of the risk, and how you can know if your mitigation efforts are actually helping.
Be looking for these posts to come out about once a week, with a week off for the Agile2010 conference in early August.
Thanks for reading,
Brian Button (bab)
VP Engineering, Director of Agile Methods