A colleague and I were talking today about project management, agile projects and I got to thinking about the point at which it is clear that a project has failed. What struck me was that I believe this point is actually much sooner than most would acknowledge. I believe there comes a point when most, if not all people on a project realize at some level that this project has failed - or will definitely fail without serious course correction. However, this point rarely leads to any serious action or course correcting - in fact most people won’t even acknowledge (publicly) that the project has reached this point.
Now, I am certainly not above this phenomenon. In fact, it’s one of my weakest traits as a project manager. When I look back at some of the projects I’ve been involved in, I can identify the point at which it became clear that we were not on a path to success. This is the point at which I begin to wake up in the middle of the night plagued by the endless list of to-dos and the bewildering feeling that we’re no where near where we need to be (or where we say we are). However, rarely did I take the steps necessary to correct this situation. Instead, I found myself doing what a lot of managers do in these situations:
- Cutting Corners - every time a new situation we hadn’t thought of rears it’s ugly head, we come up with a hack (i mean workaround) to eliminate it. We know that it isn’t really in the best interest of the project, but if we do it this way we don’t have to miss a deadline. And of course we can always fix it on the next phase (right - when was the last time you had the time on a project to go back and fix a hack from the previous phase??).
- Calling Meetings - what do we do if we feel like a project is spiraling out of control?? Call lots of meetings of course. Require everyone involved to provide you with a full status report and a list of all open issues and roadblocks. These meetings become an opportunity for the project manager to start distributing responsibility for failure to the various members of the team. They become a way to passively distribute blame and offload personal responsibility on others. Rarely are these meetings constructive, positive experiences where everyone works together in the spirit of getting things on track. Instead they become a forum for the managers to issue broad statements and ultimatums while immediately silencing anyone who voices an alternate viewpoint or tries to interject reality into the conversation.
- Issuing Ultimatums - the first time you hear “no matter what happens, we WILL ship on time” you know you’re in trouble. In fact, I would suggest that as soon as one feels the need to issue an ultimatum like that, the project has failed. Hearing statements like this tell you two things: 1) the person issuing the statement knows that the goals are unrealistic and 2) he doesn’t give a damn and would rather burn out the team than deal with reality.
- Adding People - this is probably the worst thing you can do. The only thing worse for productivity than bringing in a bunch of new people with no context and no background in the project is to ask for more frequent status reports. Adding people just means that all your current team members will have to spend half their time training the new people and the other half of their time correcting their mistakes.
The crazy thing about these activities is that they are a clear signal to everyone on the project team that the project is doomed. These actions effectively broadcast downward the trouble the project is in. This is the point (I believe) at which it becomes clear that the project has failed. Everyone knows it. Everyone feels it and while they still say “yes - it’ll be tough but i think we can do it”, what they are thinking is “there’s no way in hell”.
So why then do we not deal with these situations? Why do we not deal with the reality that the project is simply too big or too complex or too ambitious? For me, the answers are insecurity and unrealistic optimism.
Failure is a bad word. A failure in your career is a bad thing. Nobody puts failures on their resume. Ironically, failures are what we learn the most from because they force us to really examine the situation so we can avoid it in the future. Maybe even more ironic is the fact that acknowledging failure early enough might lead to eventual success. I would submit that if all project managers publicly, loudly, and clearly stated that a project was going to fail at the point at which they realized this was the case, that 50% of those projects would go on to be successful. Another 40% would be canceled and end up saving the organization a ton of money. However, the personal and professional security required to do something like that is something that most people lack. We’re afraid we’ll be seen as a skeptic - not a team player - a nay sayer. We’re afraid our superiors will say “well if you don’t think you can do it I’ll find someone who does”. And the fact is - there are plenty of eager individuals waiting to prove themselves who will say yes after you’ve said no.
So what do we do? Do we adjust the plan for success? Do we really dig into the details to see what we can possibly do to succeed? Nope. We hope. In essence, all we do is hope. We hope that the ultimatum we gave at the status meeting earlier will be taken seriously. We hope that the extra team members will be able to get up to speed quick enough to provide value. We hope that the corners we are cutting won’t impact usability, cause data corruption, etc. We hope that our superiors won’t drill into too much detail when we tell them the project is “tight, but on track”.
The fact of the matter is that many projects simply become more complex once they get underway. New requirements surface, assumptions are proved incorrect, and a whole host of other issues seem to crop up. This is bound to happen on any project. As project managers we try to plan for this, but sometimes it’s simply more than the schedule can bear. Unless we are secure enough to be vocal about the impact these issues have, and unless our superiors are able to really hear what we are saying without seeing it as descent and lack of commitment, we can’t be successful.
So I guess in the end my point is this. When you hear an IT manager or exec bemoan the fact that they spent $1.5M and in the end got nothing for it, I believe that by the time they had spent $500,000 it was clear to everyone on that team that no matter how much money they spent they were doomed for failure. The tragedy is not the failed project, but the fact that it took another $1,000,000 before anyone had the guts to say anything about it.