After working in the industry for a while, most of us pick up a few stories about projects that would not die. We almost never use the word fail; projects in IT do not fail when we can just change the scope to reflect the work performed. This tendency causes us to drag projects on long after they could profitably be closed, searching for a good "end point." I witnessed this process in action on a project I led, and it forced me to think about why we do such things.
The client hired my company to assist with a data center and operations tools upgrade as part of a much larger multiyear "IT capacity and Y2K upgrade." The project was in year three of its five-year planned cycle. We were the latest systems integrator to take up the challenge, although a number of specialist teams from our competitors continued on the project during our tenure. I joined the team as a senior architect and general busybody.
After a few weeks on the project, I felt uneasy. Something about the way the client treated us seemed off. I went back and reviewed the project and its deliverables. Then I called some of the key stakeholders off the record to talk about their current needs. Finally, I layered current project work over the gap created by looking at the deliverables and needs. All three pointed us in different directions.
Naively believing that such chaos could not help the client, I asked for a meeting with my project manager and the executive sponsor. In the meeting, I drew my three-pronged diagram, showed how operational tasks were being done by $200-an-hour consultants, and suggested that a reevaluation of the project would streamline activity.
The sponsor stared at me over his interwoven fingers throughout the presentation. When I finally stopped talking, he asked me the one question I had not considered: "Why do you think we let it get into this condition?"
The many reasons to keep the project going
That one rocked me. Like most technical folks, I thought in strictly digital terms. Order, meeting deadlines, and managing realistic expectations were right. Chaos, missing objectives, and drifting scopes were wrong. No one wanted to do the "wrong thing," so, of course, drift happened though the accumulated weight of the unconscious mistakes we all make every day.
I went off to think about it. Then I called my mentor. Eventually, he coaxed me into admitting that maybe, just maybe, more was involved with a project than just the objectives and work.
After going back through my notes, I laid out a few basic reasons for keeping a project running and in a state of great confusion. Most of them curdled my blood even though I realized they could be valid. They included the following.
Find value before quitting
Sometimes, a project continues on and on simply because no one has found any value in it yet. But people have tied their political reputations, millions of dollars, and thousands of people-hours into some kind of value proposition. Even with proper expectation setting and hard work, the business can change before we deliver that value. This creates a situation in which the project sponsors and workers quest desperately for some kind of value, hoping it will be enough to eventually justify all of their work.
Keep initial promises
Projects started at the beginning of a new executive's term tend to take on a life and force of their own. The executive's reputation within the organization can be made or broken by the project. Failure, or even failing to meet objectives, becomes unacceptable. If the initial project was ill-conceived to begin with, the promise can hold it up for as long as the executive continues with the company.
Professional inability to fail
As part of our profession, consultants do not talk about or admit to failure. Project managers, consultants, and programmers hate to talk about the times we dropped the ball. Even when we get thrown off of projects, we talk about "partial success" and "referenceable clients." This kind of paid optimism leads our profession to drag projects out long past the point when they should be buried.
Projects as battlefields
Projects represent carefully segregated arenas in which the organization's political struggles can be enacted. In particularly large organizations, an otherwise useless project can continue for years because the executives regard the sandbox as more important than the expense. Projects like these can be particularly frustrating for consultants, since we often believe that a project fundamentally exists to produce something.
Movement of organizational responsibility
Sometimes a project becomes an organizational hot potato. No one wants the project to end on their watch, because they'll end up taking the blame for the failure. So it migrates though the organization, consuming whole departments. These projects linger on for years sometimes. In the three times I've become involved with these projects, twice I had to accept blame for the failure in my consulting organization.
A very long project may actually be an excuse to get around problems within the company. If an executive finds a highly successful consulting team who helps him with one project, he naturally wants to continue the association. He may find it easier to extend the project to another area than start a new one. Over time, this can create what appears to be a bloated, multilayer project. In reality, the "project" contains several discrete units pushed together for political reasons. It can even include "operational projects" involving dozens of people, set up outside of the stifling grasp of the corporation's political structure.
Our discussion covered other topics as well, some of which were even more controversial. The basic gist was that although we as professionals conceived of projects as creating unique products, most of our clients regarded projects as just one part of a larger system of behavior. Within that larger context, the production goals of the project could fade from the spotlight.
My mentor ended our conversation by pointing out to me that we, as consultants and professionals, face a professional challenge every time we walk into one of these "dying projects." Do we fight to bring the project in line with its production needs, try to get it closed down, or surrender to the outside factors driving the process forward? By answering that question first, we can better align our work to the client's greater needs.