Death March III
How to Manage a Deeply Troubled Project and Survive
ALBERT H. SMITH
Here, you will learn the traits of a troubled project early enough to turn it around. We will identify the specific actions needed and how to implement them. You will learn what to do if you have to finish the project, but cannot turn it around. Sadly enough, this can, and does, happen.
Keywords: program management, risk management, turnaround, project management
The title of this paper comes from a book of the same title, Death March by Ed Yourdon. The first edition of this book was published in 1997 (Yourdon, 1997), and the second, in 2004 (Yourdon, 2004); hence, this paper is “Death March III.” In essence, we are going to cover how to manage deeply troubled projects. In this discussion, the troubled work is referred to as a project. It equally applies to a program. Also, I am assuming the project is being done by a systems integrator, under contract with a customer, but what's covered here also applies to an IT internal project being done for a user organization.
First of all, a Death March Project (DMP) is not one that just has issues with scope, staffing, and meeting tight deadlines. All projects are like that. A DMP is one where the normal parameters for a project are out of line by at least 50% (Yourdon, 1997, p.2). This means that the staffing, schedule, and/or budget is at least half of what a normal person would expect. From a risk management perspective, a DMP is a project where an unbiased, objective risk assessment determines that the likelihood of failure is >50% (Yourdon, 1997, p.4).
Now that's a good theoretical definition, here's a practical one… you are working for a systems integrator, you have a fixed price contract which is signed, and after a while you realize that based on your current projections, the project will be > 100% behind schedule, and >100% over the budget as agreed in the fixed-price contract. Now, this could be made worse by the fact that the contract has no provision for scope control, or to cancel it for cause or convenience.
How does a situation like this happen in the first place? Or, said another way, how did the contract vary so much from reality? Well, if one rigorously follows The Standard for Program Management – Third Edition, this might not happen. In the Formulation activity within the Definition Phase of the Program Life Cycle (PMI, 2013a, p.68), one makes sure that the estimates are correct and the contract supports the estimates. On a project, this is done in the Initiating Phase of the Project Life Cycle in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI, 2013b, p.30). Assuming one did not follow these best practices, this situation may have been caused by some or all of the following: the work effort was vastly underestimated because not enough was known about requirements, scope, and technology, and appropriate contingencies were not included; the contract had no provision for control of requirements volatility; the team was not ramped up fast enough and got behind schedule; and/or the contract was signed to meet some arbitrary cut-off date/or sales quota with the hope that all contract imperfections would be cured with change orders.
Now what does one do when they realize they are managing a project like this? Well, if this situation was caused by any impropriety on anyone's part, one can resign from the project as recommended by the PMI. Short of that, what do you do? There are three things one can do in increasing order of risk to the livelihood of the project manager: cancel the project; renegotiate the project; or “tough it out” to the bitter end. Canceling the project will not happen because of anything you do. Canceling a contract depends on what the downside is from doing it. It's a business decision which happens “above your pay grade,” as they say.
Renegotiation of the contract depends on how much each party is suffering and how important this project is to the sponsor organization. Both parties’ business cases are in jeopardy at this juncture, which may provide the impetus to renegotiate the contract. There are “soft” reasons why this will not happen, which will be discussed later.
Toughing it out means just that, you have to do what you can to finish the project. One proceeds with renegotiation and performs triage regularly. One follows the practices in the PMBOK® Guide, but they are done differently and are much harder. One will know every word in the contract and constantly will try to use it to your advantage. But, everything is driven by what we will call Death March behaviors on the part of the stakeholders.
If it is commonly known that a project is severely behind schedule and over budget, why don't the stakeholders do something about it? First, a bad contract is the responsibility of both parties who sign it, and both parties suffer. Depending on the contract wording, one party can suffer a lot more than the other. The business cases for both parties will never be met. When the contract was signed, expectations were set for budgets, revenue projections, profit projections, individual bonus projections, etc. All of these projections will not come true. The stakeholder's bosses start to ask the following questions:
- Why are you behind schedule?
- Why are you spending more that you projected? Why do you need more people?
- Why can't we reduce the number of staff?
- Why are you in the third year of a project you said would be done in one year?
So, why don't the stakeholders do something about this? Because “doing something about it” means someone has to admit they were in the wrong. That does not occur very often in the current corporate world.
Now, how do you survive? Hopefully, you were asked to save this project and were not there in the beginning. If you were indeed there in the beginning, you have bigger problems, assuming you are still there and have not been replaced. You have to focus on four areas: Business Case Management; Risk Management; Stakeholder Management; and “Peopleware.”
Business Case Management: The original business case is blown. You must develop a doable estimate to complete, keep it current, and communicate it to all stakeholders regularly. You need to sell it to the stakeholders, even in the face of the above behaviors. You will not make friends.
Risk Management: The big risk has already happened. You are now in contingency execution. If you are with a Systems Integrator, you are trying to prevent a disaster, which is to go to court and/or write-off millions of dollars.
Stakeholder Management: Negotiate and communicate openly and honestly “on both sides of the isle,” as they say. You have to be the voice of reason. You have to be viewed as the one who is trying “to do the right thing to bring the project to closure.” You must always be trying to renegotiate the terms of the contract so you can deliver something of value.
And lastly, Peopleware, from the book of the same name by Tom DeMarco and Tim Lister (DeMarco & Lister, 1987). The nature of a DMP is that of continuous negotiations and will put you in an adversarial relationship with owners/customers/senior managers (read stakeholders). Treat your team like family and protect them from the political battles happening all around them. Give them a copy of Death March, so they know why this is happening to them.
In closing, I sincerely hope the reader never has to experience a DMP, but if you do, you now know how to prevent it, and how to survive it. A few statistics on the project referred to in this discussion, which I just finished managing (I was not there at the beginning, by the way).
Type: Application Development and Managed Services (MS)
Average Development FTEs (Full Time Equivalent workers): 100
Average MS FTEs: 60
Project Start Date: August 2010
Plan Dev Completion: August 2011
Actual Dev Completion: August 2015
Plan MS Completion: August 2016
Projected MS Completion: August 2021
Note: The views expressed in this white paper are mine, and Wipro Technologies (my employer) does not subscribe to the substance, veracity, or truthfulness of my views.
ABOUT THE AUTHOR
Albert H. Smith has over 30 years of experience in program and project management. Over the years, he has worked with 21 clients, in eight industries, and in seven countries. In the last ten years, he has specialized in large-scale program management in the financial services and telecom industries, successfully completing large programs for Merrill Lynch, JP Morgan Chase, Bank of Montreal, ANZ Bank, Barclays, FIAT SAVA, Citi, Charles Schwab, and First Data. He has been with Wipro for eight years and has completed large programs for Wal Mart, Ally Bank, Citi, and Avaya.
Prior to joining Wipro, he was a vice president at American Management Systems (AMS) in New York City, and before that, was with Accenture in Washington D.C. He has a bachelor's degree in industrial engineering, a master's degree in business administration, and holds the Project Management Professional (PMP)® certification.
He lives in Princeton, New Jersey with his wife, Tatiana, who is from Russia.
DeMarco, T., & Lister, T. (1999). Peopleware. (2nd ed.). New York, NY: Dorset House. Project Management Institute. (2013a). The standard for program management – Third edition. Newtown Square, PA: Author.
Project Management Institute. (2013b). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.
Yourdon, E. (1997). Death march. Upper Saddle River, NJ: Prentice Hall.
Yourdon, E. (2004). Death march. (2nd ed.). Upper Saddle River, NJ: Prentice Hall.
© 2016, Albert H. Smith
Originally published as part of the 2016 PMI® Global Congress Proceedings – Barcelona, Spain