Mr. Thompkin's Journal from Death March by Tom Demarco

Mr. Tompkins, a manager downsized from a giant telecommunications company, divides the huge staff of developers at his disposal into eighteen teams--three for each of the software products. The teams are different sizes and use different methods, and they compete against each other and against an impossible deadline. With these teams--and with the help of numerous "fictionalized" consultants who come to his aid--Tompkins tests the project management principles he has gathered over a lifetime. Each chapter in the book Death March by Tom Demarco closes with journal entries that form the core of the eye-opening approaches to management illustrated in this entertaining novel. This is my reflection on the journal entries of Mr. Tompkins from Death March.

Mr. Tompkin's Journal packages a concise collection of insightful project management principles, approaches, skills and best practices and summary points for review. Each journal entry presents a series of conclusions for new scenarios discussed in the chapter. It covers a broad array of technical subjects like risk management, project estimating, metrics, improving productivity, overstaffing effect, dealing with ambiguous specifications, modeling for simulation, process improvement as well as soft skills such as leadership, interviewing and hiring project staff, motivating performance, improving communication, team politics, team dynamics, anger management, conflict resolution and negotiation.

Most project management books and guides focus on the technical aspects of project management processes. However, the journal entries emphasize that it is the people along with the processes that are the indispensable foundation of any successful project. An interesting point that the journal mentions which I had not come across in any other project management book is in the “Playing Defense” entry: “Keep good teams together to help your successors avoid problems of slow-jelling or non-jelling teams. Think of a jelled team as one of the project deliverables”. In my previous organization, it was a policy to disperse the project team to different projects or even different department domains (from insurance to banking) once the project is complete. Sometimes, the resources would even be shuffled between projects while the project is still going on, which would put additional strain on the project team to get the new resource on-level. I believe that when resources are transferred between domains, the existing domain knowledge of the resource is wasted.  So, I completely agree that a jelled team is the most important resource and should be considered as one of the deliverables. This is especially true in bigger projects that last for more than a year, unless you are dealing with a geographically dispersed team (GDT), because of the time invested in promoting trust and making certain that everyone knows their contribution.

Another journal entry that I had not come across before in any other book was about “Negative Reinforcements”: “Threats are an imperfect way to motivate performance

No matter how serious the threat, the work still won’t get done on time if the time originally allocated for it was not sufficient”. This reminded me of one of my earlier projects which had stringent deadlines and the scope of the project increased because of requirements not being properly documented. The upper management made it clear that unless the team put in more hours during weekdays we will have to work on weekends. Not only, did the entire team have to put in more hours during weekdays, but we spent three consecutive weekends trying to meet the deadline, which ultimately had to be extended, which I think goes to prove another journal entry that “The real reason for use of pressure and overtime may be to make everyone look better when the project fails”.

The best part about the journal was that, apart from the realm of software and projects, it also offers some practical, positive, and philosophical advice such as “You can’t get people to do anything different without caring for them and about them. To get them to change you have to understand and appreciate where they’re coming from and why”. This is applicable not only to the project scenario, but also to life in general. The one I liked the most is “There are infinitely many ways to lose a day, but not even one way to get one back.” because sometimes people have a tendency to procrastinate and finish work at the last minute.

Thus, I think Mr. Tompkin’s journal helped me in comprehending a lot of important project and process concepts and made me think how I would react to certain situations and also to obtain a perspective about interacting with people while working in a team.