The Deadline: A Novel about Project Management


The Deadline - A Novel about Project Management

by Tom DeMarco, American original edition published in 1997.

Ever wanted to know what project management is about? Tom DeMarco breaks it down in this delightful fiction about a kidnapped project manager. Just like George Gamow’s use of the character Mr. Tompkins to explain modern scientific theories, DeMarco uses his character – Webster Tompkins – to define project management rules and methods.

A quick summary

The story starts with the abduction of Webster Tompkins, taken to the fictitious Eastern Bloc country of Morovia, recently converted into a public company.

There our protagonist is given the task to carry out six extensive software development projects with a huge development team and considerable deadline pressure.

Having many employees, he creates a laboratory environment for project management experiments. The idea is to split the projects into 18 teams, 3 for each of the 6 projects. The teams are of varying sizes, with variable expertise, age and composition, and are also managed differently. With the teams competing against each other, Webster Tompkins can evaluate different project management methodologies. As in any real-life scenario, the teams face problems during the project, such as changes in deadlines, content and much more.

At the end of each chapter, Webster Tompkins summarizes his thoughts and insights into the difficulties of the modern science of management, using software development as an example.

DeMarco describes not just a project but a sophisticated program.

The author follows the style of the typical thriller while at the same time managing to incorporate project management elements easily and comprehensibly. You don’t have to be an experienced project manager to follow the content, beginners or juniors are quickly shown where the pitfalls of projects can or do lie. In an entertaining and exciting way, the author provides easily understandable insights into project management.

So, what do we learn?

Let’s sum up what DeMarco has to say in four sections:

1.- Four principles of good management (everything else is administrative)

  • Choose the right people.
  • Entrust the right people with the right tasks.
  • Motivate the employees.
  • Help the teams to get started and take off.

These are obvious points, but it is observed, that especially in large companies, often little care is taken. Project staff are often selected for their availability rather than for their expertise. Be it that the necessary special knowledge is missing, because the “boss” was appointed to the team rather than the employee who could contribute valuable information, or, know-how carriers are sent without authority to decision-relevant meetings. Also, the motivation of project staff is underestimated time and again. Thinking that “the cooperation in the project is enough motivation” just doesn’t cut it!

Tom DeMarco or his protagonist correctly recognizes here that the success of the project is decisively dependent on the human factor – his selection – as well as the distribution of tasks and not just the motivation and leadership. It is not without reason that the author uses the metaphor of “commanding a battle” for management, stating, “At the beginning of the battle, the actual work of the manager is already done: job interview and recruitment.”

2.- Risk Management

  • Manage projects by managing their risks.
  • Carefully keep a record of the risks of each project.
  • Explore the causal risks rather than just end up with the unwanted consequences.
  • Estimate the likelihood of its occurrence and the alleged costs for each risk.
  • For every risk, anticipate the very first symptom with which it is likely to appear.
  • Appoint a Risk Officer, a staff member who will release you from the We-Can-Do attitude.
  • Set up informal (perhaps even anonymous) channels through which bad news can be communicated up to the highest hierarchical levels.

Anyone who has already led a project knows about the importance of risk management, but also how great the opportunity is to treat this issue without the right focus. Never the time seems right. At the beginning of each project, analysis of project goals, planning and resource organization comes first. If the project is already up and running, deadline changes, target shifts, and budget expansions are so demanding in terms of time that there is hardly any room left for risk management as well. Tom DeMarco rightly notes that projects can be managed successfully through risks, as they are the main reason for significant deviations in the predefined project triangle (target / deadline / budget). A risk statement in detail, at least at the beginning, basically provides a clear overview of possible dangers that can be counteracted at an early stage. A clear risk analysis with likelihood of occurrence, estimated costs, leading to risk value, is considered essential.

However, DeMarco goes beyond the textbook instruction and gives useful tips on how to deal with the problems of risk realization, “recognizability of damage” and “escalation” in practice. Firstly, anticipating risk realization may be a useful indication of the occurrence of a risk. The risk officer, who should just NOT believe in the project’s success, or rather should be against it, is a great help for the early recognizability of the damage. It often happens in projects that the further up a problem or risk is escalated, the criticality is weakened. A so-called “red” marked risk may possibly arrive “green” at the board or at the highest level. Therefore, the proposal of informal or anonymous communication up to the highest hierarchical level deserves the utmost approval.

3.- Metrics

  • The size of each product must be measured.
  • It is necessary to break your head over measuring units – as long as they have no objective mass, choose subjective measuring units.
  • Make synthetic mass from all available primitives (countable software properties).
  • Collect archaeological data to derive productivity trends from completed projects.
  • Keep experimenting with the formulation of the synthetic metric until your values ​​are optimally correlated with the development effort for the projects studied in your archaeological database.
  • Place a trend line through your database showing the expected development effort as a function of synthetic metric values.
  • Now, to estimate the cost of each new project, calculate the value of the synthetic metric and use it to read the expected development effort from the trend line.
  • Take the fluctuation margin around the productivity trend as an indication of the tolerances you must expect in your extrapolations.

Using metrics brings several benefits to the software development process. A crucial point is the improvement of planning security, in the effort analysis. The often-usual effort estimation by an experienced programmer based on the “feeling” can be improved by metrics especially for very complex projects. In the further execution, the project becomes manageable, but above all controllable for the project manager. It is rightly emphasized in “The Appointment” that without a certain amount of data, the results obtained are not conclusive, the possibility of comparisons is not yet given. Ideally, this data mass is obtained from the individual project team. However, values ​​from other teams or other companies (archaeological data) can also be used as starting values. However, these cannot reflect the specific circumstances of the individual team or its environment.

However, it should be noted that the synthetic metric used as an estimation and measurement method, based on a larger volume of data, is not always easy and visually presentable. Basically, it is not the programmers or project managers who decide how much money is spent on what, but the middle to higher management, and it is precisely this that the result of the method graphically and not be presented too complicated, which can lead to further challenges.

4.- Ambiguous Specifications

  • Ambiguity in a specification indicates a conflict between different stakeholders in a system.
  • A specification that does not contain a complete list of inputs and outputs is a flop; it does not even meet the requirements for a specification.
  • No one tells you that a specification is lousy. People tend to blame themselves, not the specification.

The quality or minimum requirements of a specification (in this case requirement specification or specification) has been controversial again and again. DeMarco gives a relatively simple formula by which to check at least the minimum, namely the inputs and expenses. It is assumed that each specification consists of two parts: the set of all procedures that determine how the behaviour of a system depends on events (processes), and the set of all inputs and outputs (data) on which the behaviour depends based. Since these are data or control flows, they can be enumerated in list form. The complexity of the system is then determined by the method, but not by the data. However, if these are missing, the “simple” basis is missing.

Ambiguity in a specification – if wanted – is specified by DeMarco rightly as a conflict between interest groups. This shifts the problem solution to analysts or programmers, who then must choose a side, or to the test phase, where ambiguity emerges in unambiguousness, but for one side only.


“The Deadline” is a compelling book that keeps the suspense until the end and satisfies the thirst for knowledge of the reader interested in project management. Despite concentrated knowledge transfer, the principles of project management are self-explanatory, and the diary-like summaries after each chapter provide a successful reiteration of the previously read. DeMarco has thus managed not only to tell a fun story, but also to convey basic knowledge. If his knowledge transfer seems very basic at first, one must soon realize that his conclusions and advice go beyond the usual non-fiction literature.

So, a bit heavy for a reader without PM experience but given his light-hearted approach I would recommend you keep going. Project management is all about knowing the variables in play and where possible controlling them to give you the best possible outcome.

Want to make a comment? Absolutely, please do so.

I can only recommend everyone to join Webster Tomkins on his adventure in Morovia and be inspired by him and his diary entries.

Leave a Reply