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.
