the project graveyard

institutional memory and persistent issues

Frequently, companies operate on legacy systems and inefficient processes that are not well suited for today's needs. There is never enough time to fix everything, so we tend to live with more difficulties than we should. In time, the decision process that led to today's situation can be lost, leaving us with only the issues and little appreciation for the struggles of the past, or worse possible alternatives today had those decisions not been made. Frequently, someone will ask why some problem persists, but we can only offer the same rough answers that inevitably sound like excuses: there's no time, we have worse problems, the people who knew that system have left.

IT projects are hugely prone to failure—according to one annual survey, only 1 in 3 are deemed successful. As has been noted many times, they don't usually fail in one catastrophic way, but instead accrue small failures and become more hopeless as they drag on. Rather than discuss project failure broadly, in this article I want to address just one element of these problems: the missing linkage to the past. I have found a mechanism that can help the organization digest IT project failures and teach itself how to avoid repeating them in the future. I call this tool a "project graveyard", and use it to address the following common but potentially difficult questions.

• Why things are the way they are, despite persistent problems. You might be dealing with a network design that hinders the use of cloud services; it might be apparent that the network was designed for a different time when applications were internal.
• Who is impacted by different situations that exist. Unless someone spells it out for them, the organization might not understand that a current project exists to deal with the loss of five thousand man-hours a year to needless manual processes.
• Where certain time/manpower went when previous efforts failed. How do we account for those hires we made a year ago to address a specific set of problems.
• What dependencies exist between different circumstances. The tangled web of dependencies that often exists behind an intractable problem is usually itself a key problem and something that can't be entangled by a newcomer.
• When did it get like this?
• How can we avoid repeating past mistakes when attempting to deal with a problem?
• Why don't we try again right now?

Note that a project graveyard is different from a known issues list; both will share links to current and past initiatives, and both detail problems. But the latter focuses on problems that the user community will experience directly, while the former surfaces the underlying problems that let the issues persist.

I also want to clarify that what I'm speaking of is not the same thing as the various project document artifacts that might be collected by a project management office: this differs in being a) chronologically organized and b) published by the people who did the work. The key difference here is to have something public written in the voice of the actors for the use by the IT team, not buried away in some PMO catalog—written to tick off a check-box by project managers looking to put something behind them, and hidden from sight.

users of a project graveyard

The foremost users of a project graveyard are the people working on the projects. It's their work, they should have a say in how that effort paid off and they should be able to demonstrate how the company otherwise benefited when an effort failed.

But there are numerous other users:

• Internal Audit will want to understand progress on current efforts but also when the organization discovers new complexities that may entail risk or themselves represent risks. The project graveyard can provide such insight.
• Operational Risk Management will similarly have an interest in the ongoing maturity of the organization, and to understand the firm's attempts at achieving its goals and mitigating its problems. When a project has failed, a cogent write-up can provide ORM with assurance that IT understands the causes of these failures.
• Senior management will want an accounting for the investments made in people, time, money, and tools. When a project has failed, the graveyard description will give those answers and will suggest their remediation in the future without the executive having to ask.
• Financial and Human Resources functions will need to understand the department's activities and the ramifications for expenditure, stresses, and development. Out-of-control spending and the burnout of personnel are clear signs of a mis-managed project.
• Procurement will need to understand when purchases or vendor engagements succeed or fail. The project graveyard can be a good indicator to systemic problems with a given vendor.
• The Project Management Office may or may not have a governance program that includes a retrospective. The value of the IT team's views as recorded in the project graveyard for the PMO will be the subject matter expertise presented and the focus on the complexities, dependencies, and other technical or operational or organizational matters that the harried PM may not comprehend.
• New employees can be directed to the project graveyard as an introduction to the company they've joined, and as training in the department's challenges and its ways of working. Just the fact that the organization is so transparent about its outcomes will teach a new employee something valuable about the culture.

Several of these parties can inadvertently suggest (or demand) that a previously abandoned project be started anew. When someone asks, "Why aren't you doing ___?", the project graveyard provides the answers. I have found that all manner of inquirers have appreciated the ready availability of a comprehensive telling of past efforts and all that can be concluded and extrapolated.

And finally, any new project undertaken can refer to past project graveyard entries in its project brief. These explicit linkages can help the new project's team understand destructive patterns or common pitfalls that should be avoided. These references can be used to help win and retain funding for the new project, and help keep the project team focused.

building a graveyard

What I call a project graveyard is a catalog of past projects. It's a list of dated initiatives, each linked to the original project brief and a summary of the project's outcomes. Such descriptions help any reader re-live the experience of the project team and understand whether something succeeded and why.

Each project summary should explain the basics: the client or customer for the project; its purpose or objective; the scope of work involved; the team members who worked on the project; and when it occurred. If possible, it should also explain the budget or other investments. And of course, it must enumerate the outcomes or results. If the project failed, it's particularly important to include a retrospective on what led to the failure. This should include an honest assessment in the deficiencies in people, processes, and tools—but should also include perspectives such as timing, unforeseen organizational challenges, and technological uncertainty.

For example, should a modest technical project involving an outside vendor fails, the project graveyard's entry should capture all contributing factors, such as:

1. A clash in work ethic that presented problems in one team being unable to work at the speed of another.
2. Someone attempted to misapply agile concepts to something that wasn't iterative—like a change in network infrastructure.
3. A lack of vendor technical skills occurred—despite the vendor being contracted for their technical skills.
4. Immature internal processes produced red tape that stalled the project.
5. The project was initiated without a feasibility review phase, and show-stopper problems were discovered only once the money had been committed.

There are several techniques that can improve the value of a project write-up. The tone of the entries should remain neutral; it's not a time to air grievances or settle scores. A timeline of events can help explain cause-and-effect, and can ground the eventual outcome in readily-ingested bite sizes. Content provided by SME's (not project staff alone) and links to published sources can lend credibility to the entry. Links to known issues, other past projects, and contacts for different teams help people find more context.

A project graveyard gets truly interesting when it answers the "why" questions. This turns the project graveyard into something more than a collection of tombstones. It's a living portrait of the environment and a guide to the future as much as it is a signal of the past.

Somewhat more sensitive are the many types of fallacious thinking that can cause a project to start based on a false premise, or to be sabotaged by poor thinking during execution.

As an example: a large program may show little sign of turning around, but the organization feels committed due to sunk cost. Sunk cost is a common fallacy and that type of thinking can become part of the culture if not corrected. A graveyard entry for some portion of that project should point to the futility of further investment.

Documenting the fallacies that contributed to a project can obvious embarrass its participants. So this has to be handled with care and respect. But if we do not catch and correct these behaviors they will not address themselves. watch for the "bandwagon" fallacy, the "appeal to authority" fallacy, the "middle ground" fallacy, and others.

beyond story-telling

I consider 90-95% of projects to be of value simply because they represent an attempt at dealing with something that needs changing. The only real type of failure when it comes to persistent problems is not to try anything. Even if a project fails, it was a demonstrating to the organization that it's good to try, and that it's also OK to fail, and that lessons can always be learned.

Once built and maintained, a project graveyard can go well beyond answering the questions above. It will, by listing the sort of ambitious undertakings the team attempts, demonstrate an organization's growing maturity, experience, and capability. Having a story framed positively will remind people of their struggles, the victories they experienced, and that the organization grew to some extent as a result of the effort. The graveyard becomes a manifestation of the team's can-do culture. It will become a source of pride.

conclusion

There is no shortage of uses for a project graveyard. From providing the basic facts to inspiring the work-force, I have found the project graveyard to be an invaluable way of communicating what is, what was, and why. I thoroughly recommend the construction of such a graveyard: build it and see what happens.