domingo, febrero 05, 2012

The Deadline

"The Deadline: A Novel About Project Management" fue escrito por Tom DeMarco, coautor del famoso "Peopleware: Productive Projects and Teams". Como su título lo indica, el libro es una novela sobre gerenciamiento de proyectos, muy amena y entretenida.

La historia comienza cuando el protagonista, Mr. Tompkins es despedido de su trabajo y abducido por una espía de un país emergente cuyo objetivo es mejorar la industria de software local. El objetivo de Mr. Tompkins es terminar ciertos proyectos para una fecha específica, de ahí el título del libro. El recorrido es muy interesante, nos enteramos de como arma el equipo, como organiza los proyectos, como selecciona líderes y como resuelve todo tipo de problemas, desde personales hasta políticos.

Este libro fue escrito en 1997, y tiene varios conceptos que ya no aplican o por lo menos no son compatibles con mi orientación y "mindset" ágil. Por ejemplo, recomienda hacer un diseño detallado del software y recién escribir el código en los últimos meses, y también se utiliza mucho el método de punto de funciones para medir el tamaño del software.

Para resaltar los aprendizajes que el autor nos quiere dejar sobre project management, Mr. Tompkins completa un diario personal al final de cada capítulo, con los aforismos o puntos más importantes aprendidos luego de cada situación. Se los dejo, estimo estar de acuerdo con un 90% de estos puntos, disfrutenlos!
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.
·         So ……  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 of 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 jellied team – ready and willing to take on a new effort – as one of the project deliverables.
·         A day lost at the beginning of 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 interactions to communicate and refine thinking about how the processes work.
·         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.
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 archeological 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 archeological 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 likely 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 proportionately far less of their time in debugging.
·         High-performance projects spend proportionately 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 (much like abused children who go on to become abusive parents). 
·         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'. 
Ambigous Specification  
·         Ambiguity in a specification is a sign of unresolved conflict among various system stakeholders.
·         A specification that doesn’t contain a complete census 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 an 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; meditation 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. 

The road to wisdom, well, it’s plain    
     and simple to express,
Err and err and err again,
    but less and less and less.
                                                - Piet Hein

Roll of the Catalyst 
·         There is no such 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 short cutting 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 later in the process (as late as the last sixth of scheduled time).
·         Awful suspicion: Projects that set out to ‘achieve’ 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'’ problem, but it sure can make it easier on everyone else.)
Pathological Politics (Again) 
·         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).
Lean and Mean 
·         Lean and Mean is a formula developed in failing companies by the people responsible for the failure.
·         It is the opposite of any organization’s natural goal: to be prosperous and caring.
·         Whenever you hear the phrase “lean and mean” replace it with what it really connotes: failing and frightened. 
Radical Common Sense  
·         A project needs to have both goals and estimates.
·         They should be different.