[597] in magellan
Fwd: Ten Things You Don't Want to Hear During a Project, 2/7/01
daemon@ATHENA.MIT.EDU (Greg Anderson)
Mon Feb 19 09:24:22 2001
Message-ID: <3A912C90.2A660C01@mit.edu>
Date: Mon, 19 Feb 2001 09:24:35 -0500
From: Greg Anderson <ganderso@MIT.EDU>
MIME-Version: 1.0
To: magellan@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Good morning,
As a follow-up to the Friday discussion with Jim on project management,
he forwarded this piece from the Cutter newsletter.
Greg
Going through older email, I found this today. Much of it is very
appropriate to the conversation about successful projects yesterday.
.................................................................jim
>Date: Wed, 7 Feb 2001 08:38:40 -0700 (MST)
>Subject: Ten Things You Don't Want to Hear During a Project, 2/7/01
>From: itjournal@cutter.com
>Sender: owner-itj_list@cutter.com
>Precedence: bulk
>Apparently-To: <jdb@mit.edu>
>
>
>Welcome to The Cutter IT E-Mail Advisor, the weekly e-mail service
>for subscribers of the *Cutter IT Journal* (tm).
>
>TEN THINGS YOU DON'T WANT TO HEAR
>DURING A PROJECT
>
>by Payson Hall
>
>If business projects are part of your profession, you know that many
>projects fail to live up to their potential. Some projects fail to
>achieve their schedule or budget goals or fail to deliver everything
>initially promised. Other projects simply fail altogether. Many of
>the problems faced by projects can be avoided, or at least contained,
>by effective project management practices. Taking a cue from David
>Letterman, this article highlights ten of the most frequent reasons
>for project failure and examines some alternatives and remedies for
>each.
>
>1. This project is too important to fail.
>
>Often the response to concerns expressed about some important part of
>the project, this statement generally sends the message that
>"negative thinking" is unacceptable. Get over it -- any project, no
>matter how important, can fail.
>
>Probably the single most dangerous project management attitude is one
>that denies failure is a possibility. Identifying project problems
>early and working to address them increases the likelihood of project
>success. Team members must be encouraged to voice issues and
>concerns, not be reprimanded for "negative thinking."
>
>2. Everyone knows this budget is unrealistic, just don't tell the
> sponsor.
>
>A project is not a project unless it has a "sponsor" or "client," a
>person who is funding the effort and ultimately believes the value of
>a project is worth the cost. Sometimes a misguided project manager
>or team leader comes to believe that he or she is a better judge of
>the client's needs or what is justified than the client. When this
>occurs, the frequent result is that new information suggesting the
>project cannot be achieved within the initial budget is ignored or
>suppressed to avoid "upsetting the sponsor."
>
>This goes beyond misguided to unethical if you put yourself in the
>sponsor's shoes. Imagine providing a contractor with detailed
>blueprints for your dream house, a plot of land, and a fixed budget
>that you both agree to at the beginning of the construction project
>(your entire life's savings). Three months into the project, the
>contractor realizes there isn't enough money to complete the project.
>When do you want to know? As soon as possible! You won't be happy,
>but you need timely information to deal with the situation. Spending
>all of your money for half of a house denies you the chance to make
>informed decisions about reducing the scope of the house, postponing
>parts of the construction, or perhaps canceling the project to cut
>your losses. Good project managers remember that the project belongs
>to the sponsor.
>
>3. This is going to be a real stretch and mean lots of long hours
> over the next year, but if we work hard, we might pull it off.
>
>This statement usually precedes confusion and overtime, is followed
>by frustration and blaming, and is almost never followed by a
>successful project. As a rule, if a credible schedule can't be
>developed at the start of a project with the staff assigned working
>full time, it's pretty safe to say that the project will not be
>accomplished on time and within budget. Planning on "going to the
>whip" and overcommitting the project team from the start of the
>project almost always leads to one or more of the following:
>
>* Morale problems
>* Personnel turnover
>* Failure to achieve the goals of the project as scheduled, scoped,
> and staffed
>
>4. Aaarg! The network is down again!
>
>We have all heard this, or something similar (the copy machine is
>broken, the truck won't start, the parts aren't in stock, etc.), from
>time to time. Murphy is an honorary member of every project team.
>The point is that project teams require tools and support to do their
>work efficiently and effectively. The tools may consist of hardware
>or equipment, and support may be composed of the people needed to
>maintain those tools and assist the team with their use. If the
>tools and support are an afterthought, or insufficient resources are
>allocated to provide them, the project is in trouble. Most project
>plans make unrealistic assumptions about the productivity of the
>project team from the beginning. Productivity rapidly drops to zero
>when necessary tools and support are unavailable or unreliable.
>
>5. We can fix that during the next phase of the effort.
>
>Hearing this is usually a sign that the schedule is in trouble and
>someone is about to declare a phase of the project complete --
>whether it is complete or not. Consider also the word "fix," which
>suggests that something is broken. Although there are occasions
>when it might be prudent to delay correcting defects immediately,
>it isn't prudent nearly as often as it is suggested. Common sense
>tells us that it is cheaper and faster to fix an error in the
>blueprint with a pencil than to move a misplaced foundation with a
>jackhammer. Delay in fixing obvious problems is frequently short
>sighted, since the correction will usually take more time and
>resources later and may affect the quality of the final product.
>Additionally, after you hear this phrase several times on a project,
>the team will usually begin to reply under their breath "There is
>never time to do it right, but always time to do it twice." This
>response speaks volumes about the morale problems and lack of
>cohesiveness this tactic can create on a project, along with
>schedule and cost overruns.
>
>6. Have they found a replacement for the project manager yet?
>
>This can suggest disaster for several reasons. First, good project
>managers are hard to find but instrumental to project success. A
>project manager is like a pilot who is steering the effort toward
>completion. If the project manager is missing, who is flying the
>plane? The project manager should have a back-up ready to keep
>things on course should the project manager be hit by a truck, win
>the lottery, or (heaven forbid) get sick and be out for a week or
>two. No significant amount of time should pass on a project without
>a project manager at the helm.
>
>A second consideration when the project manager is missing is: why?
>When a project is in trouble, the project manager is usually one of
>the first to know. If the project manager doesn't have the skills
>or can't get the support from the sponsor to resolve the situation,
>he or she will sometimes strap on a parachute and jump. Whenever a
>project loses a project manager in the middle, it's reasonable to
>worry about his or her motivation for leaving. Additionally, if team
>members feel they have to periodically ask if there is a project
>manager, it suggests pretty terrible project communication.
>
>7. Here's the last spec we published, but you must understand this is
> an evolutionary process; the spec will never be completely up to
> date.
>
>This one seems subtle, but it can suggest a real problem. Most
>projects (high-tech, low-tech, no-tech) end up discovering omissions
>and errors as they go forward. These must be addressed as they are
>detected. The problem suggested by this phrase is that it appears
>our speaker has given up trying to define the end product up front
>or keep the specification current. When we stop trying to build and
>maintain reliable specifications or descriptions of our work
>products, we lose control over the definition of the final products
>and the costs and schedule required to build them.
>
>8. We've been in a crunch till now, but I think this new [tool,
> method, person] will get us caught up.
>
>This statement suggests what I call magical thinking -- with the
>right ingredient, everything will be all right. Project managers
>whose projects are behind who would rather believe in magic than
>face the facts frequently fall prey to consultants or tool vendors
>who offer facile answers to difficult problems. Unfortunately,
>someone occasionally finds a tool or expert or method that does
>seem to save the day for a project, which propagates the myth that
>there is a tool/method/expert that will save any project if you look
>hard enough.
>
>In general, if a project is in a "crunch" for an extended period of
>time, what is needed is not a magical cure but a more mundane review
>of the current schedule and resource plans and constraints, a review
>of the work products that are being produced, and an evaluation of
>the trade-offs that might make sense given the experience to date.
>It's not as exciting as a miracle cure, but it's almost always more
>reliable.
>
>9. I thought we all agreed to change that!
>
>It is essential to define a project's goals up front. Once defined,
>it is important to track and communicate changes to the definition
>in a systematic way. This is called change control or change
>management.
>
>When done poorly, change control is a bureaucratic waste of time.
>When it is not done at all, projects rarely deliver what was agreed
>to, and they often require more resources and time than should have
>been needed, due to the amount of rework required to get things to
>come together. Satisfaction with the end product can also be
>problematic because there will probably be several conflicting
>views about what the end product was supposed to be. When change
>control is done well, proposed changes to the project's work products
>are evaluated for overall impact to the project's schedule, scope,
>and resources. If a change is approved, it is clearly and quickly
>communicated to the team to minimize rework.
>
>10. Two months! That task can't possibly take two months! I
> estimate five weeks will be enough.
>
>Have you ever noticed the paradox suggested when a project manager
>says, "Mary, you are the most qualified specialist I have for this
>part of the work. Give me your best estimate regarding how long it
>will take," and in the next breath argues with the answer?
>
>Some of this is due to the limited training most people have
>regarding how to build and validate estimates. But much of it goes
>back to magical thinking. We would all like to think that just
>saying something makes it so; this is rarely the case. Second-
>guessing estimates is one of the most destructive things a project
>manager can do because it undermines the commitment of the team and
>the credibility of the schedule. The people doing the work must be
>involved in the creation of estimates for their work. If the people
>doing the work don't believe in the estimates, estimates become just
>numbers and dates on paper with little bearing on reality.
>
>This is not to say that it's unreasonable to discuss the rationale of
>estimates with the estimators. It should always be possible to say,
>"Mary, let's talk about the scope of the work as you see it to make
>sure we both understand and agree what must be done" or "Mary, let's
>review your assumptions about the resources required to do this work,
>are there any additional resources I could obtain that would help you
>do the job more quickly?" or "Mary, what assumptions are you making
>about the work that are driving your estimates? Let's make sure we
>agree on the environment in which the work will be done and the
>resources available." But the final say must rest with the person
>you trust to do the work; otherwise what you are saying is that you
>don't trust them to do the work -- so you must have the wrong person!
>
>Defining, planning, and managing business projects requires project
>management skills that take time to learn and practice to master. It
>isn't hard to fail -- failure is easy. There is an old Scandinavian
>proverb that says: "When the terrain and your map disagree, believe
>the terrain!" Effective project management avoids or minimizes most
>of the situations described above by encouraging effective and timely
>communication, acknowledging that plans are educated guesses about
>the future, and getting the project team to deal with reality as it
>is revealed, rather than trying to deny it as long as possible.
>
>-- Payson Hall
>Payson Hall is a systems architecture and project management
>consultant to system development projects and organizations. He
>developed and teaches a project management course for systems
>development organizations throughout North America and Europe.
>He can be reached at payson@catalysisgroup.com.
>+++++++++++++++++++++++++++++++++++
=======================================================================
James D. Bruce jdb@mit.edu
Professor of Electrical Engineering and 617.253.3103 Voice
Vice President for Information Systems 617.253.0750 Fax
Massachusetts Institute of Technology
77 Massachusetts Avenue, Room 10-219
Cambridge, MA 02139-4307
=======================================================================
