NEWS AT SEI
This library item is related to the following area(s) of work:Process Improvement
This article was originally published in News at SEI on: June 1, 2002
You’re on a project and it’s headed south. While everybody is trying their hardest, and you are doing your level best to help, you can feel it in your bones: the project is doomed to fail. What can you do? You have three choices.
While continuing to plug away is essential, it will not actually improve things, and it is not very professional. Often the best way to guarantee project failure is to keep working in the same way. Inertia is a form of surrender. You are acting helpless and hoping somebody will save the day, or at least hoping that the crash will not be fatal. So, plug away by all means, but do something else as well.
Choice two is to look for another job, either in your current organization or elsewhere. This is always an option, and you should consider it if things get bad enough, but job-hopping has serious drawbacks. First, the situation in the new organization may not be much better—and it could be worse. Second, since projects often fail, you cannot continually run from failure or your resume will look like an employment catalogue. While this is not as serious a concern as it once was, it costs money to hire, orient, and train people. Unless management believes you will stay long enough to recoup their investment, they will not hire you. Third, changing jobs is disruptive and could involve a move and a new home. Once you have done that a few times, it loses its charm. Finally, in any organization, it takes time to become established and accepted. Until you are known and respected by management, you will not be considered for the best jobs. By moving, you start all over again at the bottom of the seniority list.
Assuming that you don’t want to give up, disrupt your life, or become unemployable, your best choice is to fix the problems before it is too late. Doing this, however, is tricky and it could actually damage your career if not done properly. Remember, the bearer of bad news often gets the blame. So if you are outspoken about the project’s problems, expect to be made the scapegoat. This does not mean that you shouldn’t act like a professional and try to fix the problems, just that you must do it very carefully.
Since you must deal with management to solve most project problems, try to put yourself in their shoes. Consider the problems they face and decide what you could do that would help. In doing this, you can safely make three assumptions.
Managers have lots of ways to get information, and the higher they are in the organization, the more sources they have. Managers also often develop a good intuitive sense and they can smell trouble even before anyone tells them. Once managers have worked with a few projects, the troubled ones take on a distinct character. The people begin to look worried and uneasy, the laughter and fun disappear, and status reports get vague and imprecise.
There are also various test, support, financial, and administrative groups that deal with most projects, and their people will hear of, or at least sense, the first signs of trouble. These people will almost certainly have passed on what they have learned to management and, if it is bad news, you can be sure that it will travel fast. So, management either knows about the problems already or has a strong suspicion.
Busy managers have lots of problems. In fact, a manager’s time is largely devoted to solving problems, whether generated by the projects, passed down from higher management, or imposed by the customer. If you go to your manager with another problem, expect to be greeted like the plague. However, if you show up with an offer of help instead, you will likely be received with open arms.
You have a manager who is responsible for your assignments, evaluations, pay, and promotion. If your manager sees you as supportive, you can likely get help in fixing the project. However, if your manager suspects you of competing for his or her job or thinks that you are out to get exposure to senior management, expect to get cut off at the knees. If your manager is experienced, you will not even know that you have been skewered until much later, if ever.
So, watch the chain of command and start with your immediate manager. Don’t do anything your manager doesn’t know about and agree with. While that doesn’t mean your manager must know every step before you take it, be completely open and honest. Explain your approach, make sure you both understand the plan, and that you both agree on what you can do without prior approval. However, if the manager does not agree and you go over his or her head to a more senior manager, expect you or your manager to ultimately be fired.
If your manager agrees, he or she may let you carry the story upstairs, but most will do it themselves and you will not be involved or even get any credit. The key is to not worry about credit and visibility, but to concentrate on solving the problems. If you do that, sooner or later you will get plenty of visibility. There is a wonderful line by Dick Garwin, the designer of the first hydrogen bomb: “You can get credit for something or get it done, but not both” .
When you are on a troubled project, the basic survival strategy is to act professionally. It has six steps.
While problems come in many flavors, the most common involve unreachable goals. So stop and really think about the current situation and how it happened. Until you understand the problem, it will be very hard to fix.
Generally, the software problems I have seen are caused by either unrealistic schedules or inadequate resources. In either case, management has imposed, demanded, or agreed to a schedule that the current team is unable to meet. Under these conditions, just continuing to plug away and hoping for some kind of miracle merely postpones the day of reckoning and makes it harder to address the problems.
Schedule problems are particularly troublesome because they invariably lead to a host of other problems. When engineers strive to meet an impossible schedule, they are invariably working without a plan, or they have a plan that is unrealistic and useless in guiding the work. When you’re in trouble, panic is your worst enemy and that is exactly how teams behave without plans. Everybody rushes the requirements and design work so they can start coding and testing. Pretty soon, nobody knows where the project stands, modules are overlooked, fixes get lost, work is duplicated, and records are misplaced. The project is out of control.
Tiny projects can occasionally survive panics, but the larger they are, the harder they crash. The best rule to remember is: when you are in a hole, stop digging. Put down the shovel and make a plan. With few exceptions, when projects are in trouble, the most critical need is to make a plan. Involve the whole team and make as detailed and realistic a plan as you can.
While making a plan will sound plausible to anyone who believes in planning, most programmers can’t see how this could help them to get all their code written and tested. Unfortunately, there is no simple answer that will satisfy everybody. However, there are several reasons that, when taken together, should convince even a skeptical software professional.
So planning is not magic, but it sure helps.
Before running to your manager with a recommendation to make a plan, look at your own work. Make a list of what you must do and then make a plan for doing it. If this plan shows that you can finish on the desired schedule, maybe you overreacted and the team can finish on time. But if not, you will have a convincing story to show your manager about your problems and how you plan to address them.
In making this plan, observe a few cautions. To the extent that you can, base the plan on historical data [2, 3, 4]. Also, be discreet in making the plan. After all, if your manager thought planning was a good idea, the team would probably have a plan and you would not be in this mess. So get your story straight before talking about it. Next, if your friends or teammates have some planning experience, get them to review your plan and identify any holes or errors. Once you have a plan you believe in, talk with your manager.
In talking with your manager, concentrate on your own work and the plan you have made for doing it. If your plan shows that you can’t meet the committed dates, ask for guidance. Maybe your plan includes too many tasks or the manager might see some way to simplify the work. If this leads the manager to ask the other team members to make similar plans, you are on the road to success. But if not, and if the plan helped you to have a realistic discussion with your manager, discuss what you have done with your teammates and suggest that they do the same thing. Then, when more team members have plans, you can all go to the manager and show that the problem is bigger than he or she thought.
If, as is likely, the composite of all the team members’ plans shows that the project is in serious trouble, suggest that the team make a complete plan. If the manager agrees, he or she will then likely go to higher management to review the project and get agreement to a replanning effort. Then, with that plan, you, your teammates, and your manager will have a sound basis for renegotiating the team’s schedule. If you get this far, you will be able to turn the failed project into at least a partial success. If not, consider your other alternatives: either keep your head down and continue plugging away, or find another job.
As long as you continue to work quietly on a failed project, you are part of the problem. By taking a more active role and addressing your part of the job first, you can become part of the solution. This will help the project and your career, and it will help you to behave like a true professional. It will also lead to a satisfying and rewarding way to work.
In writing papers and columns, I make a practice of asking associates to review early drafts. For this column, I particularly appreciate the helpful comments and suggestions of Jim McHale, Julia Mullaney, Marsha Pomeroy-Huff, and Bill Peterson.
In these columns, I discuss software issues and the impact of quality and process on engineers and their organizations. However, I am most interested in addressing the issues that you feel are important. So, please drop me a note with your comments, questions, or suggestions. I will read your notes and consider them when planning future columns.
Thanks for your attention and please stay tuned in.
Watts S. Humphrey
 Broad, William J. “Who Built the H-Bomb? Debate Revives.” The New York Times, April 24, 2001, pg. D1.
 Humphrey, Watts S. A Discipline for Software Engineering. Reading, MA: Addison Wesley, 1995.  Humphrey, Watts S. Introduction to the Team Software Process. Reading, MA: Addison Wesley, 1999.  Humphrey, Watts S. Winning with Software: an Executive Strategy. MA: Addison Wesley, 2002.
Watts S. Humphrey founded the Software Process Program at the SEI. He is a fellow of the institute and is a research scientist on its staff. From 1959 to 1986, he was associated with IBM Corporation, where he was director of programming quality and process. His publications include many technical papers and several books. His most recent books are Introduction to the Team Software Process (2000) and Winning With Software: An Executive Strategy (2002). He holds five U.S. patents. He is a member of the Association for Computing Machinery, a fellow of the Institute for Electrical and Electronics Engineers, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. He holds a BS in physics from the University of Chicago, an MS in physics from the Illinois Institute of Technology, and an MBA from the University of Chicago.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.