You know it; it’s fun to read about other people’s disasters. We all have just a touch of schadenfreude, if we’re honest about it. So, for your reading pleasure, I’m going to relate a story about a project gone wrong. It was a real learning experience for me, and maybe it will be for you too.

A few years ago, I joined a new Fortune 500 roll-up company as an IT project manager to manage an ongoing e-procurement project. The project sounded interesting and my co-workers were delightful. I moved my photos and a potted plant into my little beige office and innocently started working to ensure project success. I identified stakeholders, planned project communications, reviewed the project budget and schedule, and built a relationship with the outsourced development team. My past project management successes gave me confidence that I could get the job done.

However, it didn’t take long before I began to see a few cracks in the shiny veneer of this high-profile project. The proposed procurement system was supposed to integrate seamlessly with our back-office systems. Problem was, as a roll-up comprised of dozens of acquired companies, we had many different back-office systems. Some were industry-standard COTS systems, some were home-grown systems, and some were outdated COTS systems that had been heavily customized over the years. There was a naïve belief among business people, back in those early, heady days of “e-everything,” that the magic of the Internet would somehow smooth over all these traditional software development challenges. I wasn’t convinced. Meetings with the software development team did nothing to allay my concerns. What was worse, meetings with the business stakeholder team “in the field” revealed the fact that our different offices were operating with very different procurement processes, a fact that hadn’t been adequately addressed by the project team.

The procurement manager and I decided to put the project on hold and conduct a tour of several of our major locations to meet with management and procurement teams and verify our requirements and the overall project scope. Although everything that we learned reinforced our fears that the project scope was idealistic and the budget unrealistic, we had a grand time doing it. The teams we met were knowledgeable, enthusiastic, and ready to help us. We created pages of process flows and learned an incredible amount about our processes, our vendor relationships, and the industry we were operating within. However, no matter how much camaraderie we created, the sad truth was that everything we learned pointed in the same direction: the project I had been tasked to lead was inevitably going to fail. The project requirements did not match the reality we saw on the ground. Without major scope changes and/or major organizational changes, no amount of time or money was going to make it work.

When I got back to Houston and sat down with my manager and the CIO to discuss these findings, I was gobsmacked to discover that they had expected and hoped that the project would fail. To realize that I’d been hired to drive this train-wreck was very sobering. I’d gotten caught in a feud between two executives, a feud that cost the company well over a million dollars. In the end, the project was cancelled and replaced by two other projects: one to select a new ERP system to standardize our back-office and another to consolidate our purchasing spend and create strategic relationships with key vendors. Unfortunately, the company didn’t survive long enough to see the fruits of either of these projects.

Lessons learned?

First, it doesn’t matter how good the requirements look; if they’re not based in the everyday reality of your company’s operations, they’re not worth a used tissue.

Second, don’t take anything at face value. If I’d been less naïve and more cynical, I would have seen through the façade and pulled the plug sooner, saving everyone money and aggravation. Don’t be afraid to ask tough questions and look under all the rocks.

Third, cancelling a project can be a good thing. I thought when I stood in front of the board and told them to kill my project, I would be out of a job the next day. But they appreciated my honesty and recognized my hard work. I moved on to other projects and my standing in the organization was enhanced by the way I handled a really ugly situation.