A Novel About Project Management
Inspired by George Gamow
‘s story-like books about the secrets of physics, Tom DeMarco delivered a great book about project management. Since his lectures are wrapped with a nice story it makes them a) nice to read and b) easily understandable because the story is sort of a real world example of what DeMarco wants to teach us.
It all starts with Mr Tompkins, the central character of the book, being laid off from his job as a manager. While attending some HR lectures he’s kidnapped. A few hours later he finds himself in the fictitious post communistic country of Morovia where he’s offered a job to build up the countries software industry. He accepts and from that point on the reader is learning about management by simply following the adventures of Mr Tompkins as a top manager. Luckily Mr Tompkins writes all his experiences down into a diary.
His diary starts with the Four Essentials of Good Management:
- Get the right people.
- Match them to the right jobs.
- Keep them motivated.
- Help their teams to jell and stay jelled.
(All the rest is Administrivia)
I’m pretty sure I can’t just copy all entries 1:1 here due to copyright issue or such, but let me try to sum up the key points I got from reading The Deadline
- Change is essential to all success in project work, but people need to feel save in order to embrace change and take risks.
- Threats are a bad people motivator or tool for increasing performance.
- Management is not a completely technical discipline at all: Management involves heart, gut, soul and nose. However, you can try to model your hunches. You can use models to simulate results and tune the models by comparing these results with the actual results.
- Don’t try to hire alone – two guts are more than twice as good as one. Also listen more than you speak.
- Productivity improvement always comes from long-term investment, never short-term.
- You can’t and shouldn’t avoid risks. Just you need to manage them. Part of that is to have a method to discover early symptoms of a risk. A good method to do so is to appoint a risk officer, one person who is not expected to maintain a Can-Do attitude. Another method could be to establish easy and / or anonymous channels for bad news.
- Keep good teams together.
- A lost day at the beginning of the project is as bad as a lost day at the end.
- Pathological Politics: You have to be willing to put your job on the line any day, even though that doesn’t guarantee that this sort of tactic will work out.
- Pathology has effects on team size: Leanly staffed projects become unsafe (Because it might be argued that you didn’t put enough men power on the project)
- Metrics are useful but don’t worry necessarily about the units. For a first try that could be anything. Try to collect archaeological data to derive productivity trends.
- People under pressure don’t think any faster! Also extended overtime is a productivity reduction tactic. Short bursts of pressure however can make people focus better and increase the sense that the work is important.
- Anger and contempt in management are always counter productive. When upper management is abusive, lower management is likely to mimic the behavior.
- If a specification of a software product doesn’t come to the point (doesn’t at least specify input and output of the system) it’s often a sign of unresolved conflict among the various system stakeholders.
- Conflict deserves respect. Conflict is not a sign of unprofessional behavior.
- Negotiation is hard; mediation is easy. BUT: the parties need to agree on mediation and it can’t come from upper management, rather from someone who is not involved or wouldn’t have any advantage from the one or the other outcome.
As always a summary can’t tell the whole story so I really recommend everyone who is interested in the topic and who has come that far reading this article to get a copy of The Deadline at Amazon:
Even in a 5 out of 5 stars book, there’s always one point you don’t totally agree with. For me that is DeMarco’s suggestion to invest the major amount of project time into the design phase of the project, so that coding can be pushed rather to the end. This should improve the quality of the software and also limit the need of QA and later refactoring (which is expensive). In my mind this won’t work in most real life projects because the requirements are just to fuzzy and become more stable in a rather iterative process. Therefore the software development process should also be rather iterative like suggested for example in various agile methodologies
Additional Resources:
I'm a Software Developer, currently working at