The DeadlineTom DeMarco
I have never had so much fun reading about business, psychology, software development, and project management all at the same time. DeMarco very effectively uses fiction to explain some best project management practices; it’s both a thrilling page-turner and an indispensable manual. Over the course of the novel, the protagonist keeps a journal of learnings that sum the book up quite well:

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.)
Safety and Change
People can’t embrace change unless they feel safe.
Change is essential to all success in project work (and in most other worthwhile endeavors).
A lack of safety makes people risk-averse.
Avoiding risk is fatal, since it causes you to miss out on the associated benefit as well.
People can be made to feel unsafe by direct threats, but also by the sense that power may be used against them abusively.
Negative Reinforcement
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.
Worse still, if the target doesn’t get met, you may actually have to make good on your threats.
The Manager’s Essential Body Parts
Management involves heart, gut, soul, and nose.
lead with the heart,
trust your gut (trust your hunches),
build soul into the organization,
develop a nose for bullshit.
Battle Command As a Metaphor for Management
By the time the battle begins, the manager’s real work is already done.
Interviews and Hiring
Hiring involves all the managerial body parts: heart, soul, nose, and gut (but mostly gut).
Don’t try to do it alone — two guts are more than twice as good as one.
Ask new hires to undertake one project at exactly the level of competence they have already proved, to defer real stretch goals till the next time.
Ask for pointers: The person you are most inclined to hire may well know of other good possibilities.
Listen more than you speak.
All these things work better if you stack the deck.
Productivity Improvement
There is no such thing as a short-term productivity fix.
Productivity improvement comes from long-term investment.
Anything that promises immediate term results is likely to be snake oil.
Risk Management
Manage projects by managing their risks.
Create and maintain a census of risks for each project.
Track the causal risks, not just the ultimate undesirable outcomes.
Assess each risk for probability and likely cost.
Predict, for each risk, the earliest symptom that might indicate materialization.
Appoint a risk officer, one person who is not expected to maintain a Can-Do attitude.
Establish easy (perhaps anonymous) channels for bad news to be communicated up the hierarchy.
Playing Defense
Cut your losses.
You can improve overall performance more by containing your failures than by optimizing your successes.
Be aggressive about canceling failed efforts early.
Don’t take chances on team jell if you don’t have to: Seek out and use preformed teams.
Keep good teams together (when they’re willing) to help your successors avoid problems of slow-jelling or non-jelling teams.
Think of a jelled team — ready and willing to take on a new effort — as one of the project deliverables.
A day lost at the beginning of a project hurts just as much as a day lost at the end.
There are infinitely many ways to lose a day…but not even one way to get one back.
Modeling and Simulation of the Development Process
Model your hunches about the processes that get work done.
Use the models in peer interaction to communicate and refine thinking about how the process works.
Use the models to simulate results.
Tune the models against actual results.
Pathological Politics
You have to be willing to put your job on the line any day…
…but that doesn’t guarantee that pathological politics won’t affect you.
Pathological politics can crop up anywhere, even in the healthiest organization.
The defining characteristic of pathological politics is that goals of personal power and influence come to override the natural goals of an organization.
This can happen even when the pathological goal is directly opposed to the organizational goal.
Among the bad side effects of pathology: It becomes unsafe to have a leanly staffed project.
You can’t expect to cure pathology from beneath.
Don’t waste your time or jeopardize your position by trying.
Sometimes, your only option is to bide your time, waiting for the problem to resolve itself, or for a good opportunity for you to move on.
Miracles may happen (but don’t count on them).
Metrics
Size every single product.
Don’t sweat the units — while you’re waiting to achieve objective metrification, use subjective units.
Form synthetic metrics from all the primitives (countable characteristics of the software) available to you.
Collect archaeological data to derive productivity trends from now-ended projects.
Tinker with the formulation for your synthetic metric until its values give the best correlation to Effort for the set projects in your archaeological database.
Draw a trend line through your database, showing expected Effort as a function of values of the synthetic metric.
Now, for each new project to be estimated, compute value of the synthetic metric and use it to pick off expected Effort from the trend line.
Use the noise level around the productivity trend as an indicator of what tolerance to apply to the projections.
Process and Process Improvement
Good process and continually improving process are admirable goals.
They are also very natural goals: Good technical workers will focus on them whether you tell them to or not.
Formal process improvement programs cost time and money; a given process improvement effort may well set project work back. Even if productivity gains materialize, they are unlikely to offset the time spent on process improvement for those projects that host the program.
A project can hope to gain enough from a single well-chosen method improvement to repay the time and money invested in the change.
Projects cannot realistically hope to accommodate more than one method improvement over their duration. Multi-skill improvement programs (for instance, increasing by an entire CMM level) are most liklely to make projects finish later than they would have without the program.
The danger of standard process is that people will miss chances to take important shortcuts.
Particularly on overstaffed projects, standard process will be observed rigorously as long as it generates sufficient work (useful or not) to keep everyone busy.
Changing the Way Work Gets Done
There is no way to get projects to perform substantially beyond the norm without making large reductions in the total amount of debugging time.
High-performing projects spend proportionally far less of their time in debugging and far more of their time in design.
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 (appreciate) where they’re coming from and why.
The Effects of Pressure
People under pressure don’t think any faster.
Extended overtime is a productivity-reduction tactic.
Short bursts of pressure and even overtime may be a useful tactic as they focus people and increase the sense that the work is important, but extended pressure is always a mistake.
Perhaps managers make so much use of pressure because they don’t know what else to do, or are daunted by how difficult the alternatives are.
Terrible suspicion: The real reason for use of pressure and overtime may be to make everyone look better when the project fails.
The Angry Manager
Anger and contempt in management are contagious. When upper management is abusive, lower management mimics the same behavior.
Managerial contempt is supposed to act as a goad to get people to invest more in their performance. It is the most frequent “stick” of carrot-and-stick management. But where is the evidence that contempt has ever caused anyone to perform better?
A manager’s use of contempt to goad workers is more a sign of the manager’s inadequacy than of the workers’.
Ambiguous Specification
Ambiguity in a specification is a sign of unresolved conflict among the various system stakeholders.
A specification that doesn’t contain a complete cesnsus of inputs and outputs is a nonstarter; it simply doesn’t begin to specify.
Nobody will tell you if a specification is lousy. People are inclined to blame themselves rather than it.
Conflict
Whenever there are multiple parties to a development effort, there are bound to be conflicting interests.
The business of building and installing systems is particularly conflict-prone.
Most system development organizations have poor conflict-resolution skills.
Conflict deserves respect. Conflict is not a sign of unprofessional behavior.
Declare up front that everybody’s win conditions will be respected. Make sure that win conditions are elicited at all levels.
Negotiation is hard; mediation is easy.
Arrange up front that when win conditions are mutually exclusive or partly so, the parties will be expected to move into mediation to resolve conflict.
Remember: We are both on the same side; it is the problem that’s on the other side.
Role of the Catalyst
There is such a thing as a catalytic personality. Such people contribute to projects by helping teams to form and jell, and to remain healthy and productive. Even if our catalysts did nothing else (they usually do a lot else), their catalytic role is important and valuable.
Mediation is a special case of the catalytic role. Mediation is learnable with a small investment.
The small ceremony beginning, “may I help by trying to mediate for you?” can be an essential first step in conflict resolution.
Human Error
It’s not what you don’t know that kills you,…it’s what you know that isn’t so.
Staff Level
Early overstaffing tends to force projects into shortcutting the key design activity (to give all those people something to do).
When work is divided over a large staff prior to completion of design, the interfaces among people and among work groups are not minimized.
This leads to increased interdependence, meeting time, rework, and frustration.
Ideal staffing requires a small core team for most of the project, and then significant numbers of people added late in the process (as late as the last sixth of scheduled time).
Awful suspicion: Projects that set out to achieve ‘aggressive’ schedules probably take longer to complete than they would have if started with more reasonable schedules.
Project Sociology
Keep meetings small by making it safe for unessential people not to attend. A published agenda, rigorously followed, is the easiest way to make nonattendance safe.
Projects have need of ceremony.
Use ceremony to focus attention on project goals and ideals: small meetings, zero-defect work, etc.
Take steps to protect people from abusive anger.
Remember: Anger = Fear. Managers who inflict abusive, angry behavior on their subordinates are almost always doing it because they’re afraid.
Observation: if everybody understands that Anger = Fear, anger will be a transparent signal that the angry person is afraid; since there is an inclination not to reveal fear, he or she won’t be able to vent the anger anymore. (This doesn’t solve the angry person’s problem, but it sure can make it easier on everyone else.)
Radical Common Sense
A project needs to have both goals and estimates.
They should be different.

The Deadline
Tom DeMarco

I have never had so much fun reading about business, psychology, software development, and project management all at the same time. DeMarco very effectively uses fiction to explain some best project management practices; it’s both a thrilling page-turner and an indispensable manual. Over the course of the novel, the protagonist keeps a journal of learnings that sum the book up quite well:

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.)


Safety and Change

  • People can’t embrace change unless they feel safe.
  • Change is essential to all success in project work (and in most other worthwhile endeavors).
  • A lack of safety makes people risk-averse.
  • Avoiding risk is fatal, since it causes you to miss out on the associated benefit as well.
  • People can be made to feel unsafe by direct threats, but also by the sense that power may be used against them abusively.


Negative Reinforcement

  • 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.
  • Worse still, if the target doesn’t get met, you may actually have to make good on your threats.


The Manager’s Essential Body Parts

  • Management involves heart, gut, soul, and nose.
  • lead with the heart,
  • trust your gut (trust your hunches),
  • build soul into the organization,
  • develop a nose for bullshit.


Battle Command As a Metaphor for Management

  • By the time the battle begins, the manager’s real work is already done.


Interviews and Hiring

  • Hiring involves all the managerial body parts: heart, soul, nose, and gut (but mostly gut).
  • Don’t try to do it alone — two guts are more than twice as good as one.
  • Ask new hires to undertake one project at exactly the level of competence they have already proved, to defer real stretch goals till the next time.
  • Ask for pointers: The person you are most inclined to hire may well know of other good possibilities.
  • Listen more than you speak.
  • All these things work better if you stack the deck.


Productivity Improvement

  • There is no such thing as a short-term productivity fix.
  • Productivity improvement comes from long-term investment.
  • Anything that promises immediate term results is likely to be snake oil.


Risk Management

  • Manage projects by managing their risks.
  • Create and maintain a census of risks for each project.
  • Track the causal risks, not just the ultimate undesirable outcomes.
  • Assess each risk for probability and likely cost.
  • Predict, for each risk, the earliest symptom that might indicate materialization.
  • Appoint a risk officer, one person who is not expected to maintain a Can-Do attitude.
  • Establish easy (perhaps anonymous) channels for bad news to be communicated up the hierarchy.


Playing Defense

  • Cut your losses.
  • You can improve overall performance more by containing your failures than by optimizing your successes.
  • Be aggressive about canceling failed efforts early.
  • Don’t take chances on team jell if you don’t have to: Seek out and use preformed teams.
  • Keep good teams together (when they’re willing) to help your successors avoid problems of slow-jelling or non-jelling teams.
  • Think of a jelled team — ready and willing to take on a new effort — as one of the project deliverables.
  • A day lost at the beginning of a project hurts just as much as a day lost at the end.
  • There are infinitely many ways to lose a day…but not even one way to get one back.


Modeling and Simulation of the Development Process

  • Model your hunches about the processes that get work done.
  • Use the models in peer interaction to communicate and refine thinking about how the process works.
  • Use the models to simulate results.
  • Tune the models against actual results.


Pathological Politics

  • You have to be willing to put your job on the line any day…
  • …but that doesn’t guarantee that pathological politics won’t affect you.
  • Pathological politics can crop up anywhere, even in the healthiest organization.
  • The defining characteristic of pathological politics is that goals of personal power and influence come to override the natural goals of an organization.
  • This can happen even when the pathological goal is directly opposed to the organizational goal.
  • Among the bad side effects of pathology: It becomes unsafe to have a leanly staffed project.
  • You can’t expect to cure pathology from beneath.
  • Don’t waste your time or jeopardize your position by trying.
  • Sometimes, your only option is to bide your time, waiting for the problem to resolve itself, or for a good opportunity for you to move on.
  • Miracles may happen (but don’t count on them).


Metrics

  • Size every single product.
  • Don’t sweat the units — while you’re waiting to achieve objective metrification, use subjective units.
  • Form synthetic metrics from all the primitives (countable characteristics of the software) available to you.
  • Collect archaeological data to derive productivity trends from now-ended projects.
  • Tinker with the formulation for your synthetic metric until its values give the best correlation to Effort for the set projects in your archaeological database.
  • Draw a trend line through your database, showing expected Effort as a function of values of the synthetic metric.
  • Now, for each new project to be estimated, compute value of the synthetic metric and use it to pick off expected Effort from the trend line.
  • Use the noise level around the productivity trend as an indicator of what tolerance to apply to the projections.


Process and Process Improvement

  • Good process and continually improving process are admirable goals.
  • They are also very natural goals: Good technical workers will focus on them whether you tell them to or not.
  • Formal process improvement programs cost time and money; a given process improvement effort may well set project work back. Even if productivity gains materialize, they are unlikely to offset the time spent on process improvement for those projects that host the program.
  • A project can hope to gain enough from a single well-chosen method improvement to repay the time and money invested in the change.
  • Projects cannot realistically hope to accommodate more than one method improvement over their duration. Multi-skill improvement programs (for instance, increasing by an entire CMM level) are most liklely to make projects finish later than they would have without the program.
  • The danger of standard process is that people will miss chances to take important shortcuts.
  • Particularly on overstaffed projects, standard process will be observed rigorously as long as it generates sufficient work (useful or not) to keep everyone busy.


Changing the Way Work Gets Done

  • There is no way to get projects to perform substantially beyond the norm without making large reductions in the total amount of debugging time.
  • High-performing projects spend proportionally far less of their time in debugging and far more of their time in design.
  • 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 (appreciate) where they’re coming from and why.


The Effects of Pressure

  • People under pressure don’t think any faster.
  • Extended overtime is a productivity-reduction tactic.
  • Short bursts of pressure and even overtime may be a useful tactic as they focus people and increase the sense that the work is important, but extended pressure is always a mistake.
  • Perhaps managers make so much use of pressure because they don’t know what else to do, or are daunted by how difficult the alternatives are.
  • Terrible suspicion: The real reason for use of pressure and overtime may be to make everyone look better when the project fails.


The Angry Manager

  • Anger and contempt in management are contagious. When upper management is abusive, lower management mimics the same behavior.
  • Managerial contempt is supposed to act as a goad to get people to invest more in their performance. It is the most frequent “stick” of carrot-and-stick management. But where is the evidence that contempt has ever caused anyone to perform better?
  • A manager’s use of contempt to goad workers is more a sign of the manager’s inadequacy than of the workers’.


Ambiguous Specification

  • Ambiguity in a specification is a sign of unresolved conflict among the various system stakeholders.
  • A specification that doesn’t contain a complete cesnsus of inputs and outputs is a nonstarter; it simply doesn’t begin to specify.
  • Nobody will tell you if a specification is lousy. People are inclined to blame themselves rather than it.


Conflict

  • Whenever there are multiple parties to a development effort, there are bound to be conflicting interests.
  • The business of building and installing systems is particularly conflict-prone.
  • Most system development organizations have poor conflict-resolution skills.
  • Conflict deserves respect. Conflict is not a sign of unprofessional behavior.
  • Declare up front that everybody’s win conditions will be respected. Make sure that win conditions are elicited at all levels.
  • Negotiation is hard; mediation is easy.
  • Arrange up front that when win conditions are mutually exclusive or partly so, the parties will be expected to move into mediation to resolve conflict.
  • Remember: We are both on the same side; it is the problem that’s on the other side.


Role of the Catalyst

  • There is such a thing as a catalytic personality. Such people contribute to projects by helping teams to form and jell, and to remain healthy and productive. Even if our catalysts did nothing else (they usually do a lot else), their catalytic role is important and valuable.
  • Mediation is a special case of the catalytic role. Mediation is learnable with a small investment.
  • The small ceremony beginning, “may I help by trying to mediate for you?” can be an essential first step in conflict resolution.


Human Error

  • It’s not what you don’t know that kills you,…it’s what you know that isn’t so.


Staff Level

  • Early overstaffing tends to force projects into shortcutting the key design activity (to give all those people something to do).
  • When work is divided over a large staff prior to completion of design, the interfaces among people and among work groups are not minimized.
  • This leads to increased interdependence, meeting time, rework, and frustration.
  • Ideal staffing requires a small core team for most of the project, and then significant numbers of people added late in the process (as late as the last sixth of scheduled time).
  • Awful suspicion: Projects that set out to achieve ‘aggressive’ schedules probably take longer to complete than they would have if started with more reasonable schedules.


Project Sociology

  • Keep meetings small by making it safe for unessential people not to attend. A published agenda, rigorously followed, is the easiest way to make nonattendance safe.
  • Projects have need of ceremony.
  • Use ceremony to focus attention on project goals and ideals: small meetings, zero-defect work, etc.
  • Take steps to protect people from abusive anger.
  • Remember: Anger = Fear. Managers who inflict abusive, angry behavior on their subordinates are almost always doing it because they’re afraid.
  • Observation: if everybody understands that Anger = Fear, anger will be a transparent signal that the angry person is afraid; since there is an inclination not to reveal fear, he or she won’t be able to vent the anger anymore. (This doesn’t solve the angry person’s problem, but it sure can make it easier on everyone else.)


Radical Common Sense

  • A project needs to have both goals and estimates.
  • They should be different.
  1. youshouldgothere said: Ok I need to read this
  2. phraznikov posted this
Short URL for this post: http://tmblr.co/ZFL64ybozgPo