From the Sponsor’s Desk – Ignore These 7 Lessons at Your Project’s Peril

I have a passion for proven best practices. They are the collective wisdom of others who have gone before.

They can improve performance, reduce risk, accelerate delivery and increase satisfaction. They can be revised or discarded as appropriate. New ones can be added. But they should never be ignored.

In the following case, you’ll see how one project faired when the CEO dictated a certain course of action. Those charged with carrying out the project chose to carve a new path and ignored the lessons learned by others. They paid an all too familiar price.

Thanks to R.D. for the details on this story.

The Situation

This industrial services company had grown successfully over the years through a practical strategy of strong organic growth and complementary acquisitions. The company’s head office serviced the northeast. Five other regional offices covered the major metropolitan areas in the rest of the country.

The new CEO recently hired to replace the retiring leader, found the culture somewhat foreign. He was used to a fast paced, competitive, often combative environment as head of marketing in his old firm. At his new company, the pace was slower, more collegial, almost familial. But, what irked him most was the almost complete lack of instant access to key corporate performance indicators. Three of the regional organizations had been acquired. Business processes and supporting technologies were a hodgepodge of disparate purchased and home grown solutions. Getting an accurate and timely view of enterprise operations was costly and time-consuming.

His old firm had been a much larger organization. Prior to his arrival, it had implemented a full spectrum Enterprise Resource Planning (ERP) solution that covered all the vital corporate functions including customer management, sales, procurement, distribution, inventory, accounting and human resources. It also provided executive dashboards so senior management could tap in and drill down on actual corporate performance at will. This capability wasn’t available at his current company.

The CEO was frustrated with this lack of access to operational information. While his senior management team and the regional general managers didn’t seem to be bothered by the current situation, the CEO knew they could do a much better job of managing the company’s performance with better access to information. So, he launched a priority project to remedy the situation, holding the VP of Information Services (IS) responsible for making it happen. The CEO called the project “Insight.”

The Goal

The goal of the Insight project was to deliver a comprehensive ERP solution covering head office and the five regional offices within eighteen months. The project was to use the software and vendor services that the CEO’s previous firm had used. The project’s scope would cover customer management, sales, procurement, distribution, inventory, accounting and human resources functions. All senior managers were to have access to the executive dashboards.

The Project

The VP of IS and the vendor’s Sales Director met to review the CEO’s challenge. They agreed to proceed as follows:

• The vendor would appoint an experienced senior project manager to run the overall project.
• The project manager would report jointly to the vendor’s Director of Contract Management and the VP of IS.
• The project would include the functionality specified by the CEO.
• The VP of IS would ensure that sufficient subject matter expertise was available from the affected head office and regional office business and IT groups.

When the vendor’s project manager was on board, he contacted the VP of IS and the regional managers requesting subject matter experts from the affected business units and IT to participate in the project. He proceeded to build his own team with analysts, programmers, database resource, and training staff. He also started to build a high-level plan based on his experience in two previous ERP implementations with the vendor. He knew the eighteen-month target would be a challenge, so he developed a strategy to accelerate delivery as much as possible:

• Use the vendor functionality as delivered out of the box to reduce the need for revisions and custom code.
• Any deviation from the standard functionality would need to be approved jointly by the VP of IS and the vendor to minimize scope creep.
• Deliver the change as one major implementation to avoid the incremental time and costs that could be incurred to phase delivery by function and/or location.

The PM proposed that he could deliver to the stated goals in the targeted eighteen months at the cost of $2.5 million. He received approval from the VP of IS and the vendor on his overall strategy and plan and so proceeded accordingly. He immediately ran into challenges:

• The subject matter experts were not available or late in arriving.
• Many of the so-called subject matter experts assigned weren’t experts.
• Each of the locations had its own unique processes, applications, and technologies. That meant six conversions instead on the one he had planned.

The PM filed bi-weekly status reports for the vendor and the VP of IS using the vendor’s standard reporting format. His first report, two weeks after his assignment to the project showed green for schedule, cost and scope. His second report, in one month then showed red for schedule, cost, and scope. Every subsequent report showed red across the board. He couldn’t get the staff he needed, with the skills he needed, when he needed them. As each of the locations began to understand the functionality available in the standard offering, the change requests escalated into the hundreds and eventually thousands. The vendor management and VP of IS were slow to rule on the requests. They rejected the initial onslaught out of hand to preserve the CEO’s eighteen-month target. That resulted in local escalations to head office and regional office business executives who vehemently descended on the VP of IS and the CEO.

The first project manager was replaced after six months with two PM’s, one from the vendor and one from the Information Services organization. Still, everything the project did was focused on meeting the eighteen-month target. When it became obvious that was not achievable the emphasis was still on the delivery date above all else, still marching to the original PM’s strategy.

The Results

The Insight project took more than five years to complete, at the cost of almost $7 million. A disastrous attempt at a one time, big bang implementation two and a half years into the project contributed to a 27% corporate revenue decline. The initiating CEO and VP of IS were fired. The first two and a half years of the project up to and including the failed implementation and subsequent recovery burned through $5 million.

After the failed big bang implementation, the new CEO and VP of IS brought in a consulting firm to take on overall control of the project. The consulting firm’s approach was to treat the initiative as a program, with six separate and discrete projects covering head office and the five regions, all moving to a consistent, common business, application, data and technology infrastructure. The CEO was the executive sponsor. The five regional general managers were sustaining sponsors. Each project was run in parallel, in accordance with the capabilities and priorities of the target organization. Each project was phased in on a function be function basis to reduce risk and build a continuous delivery culture. This part of the project was completed successfully in two and a half years, at the cost of $2 million.

How a Great Leader Could Have Succeeded

There are more than a few failed ERP project examples. You’ll probably get over half a million or so items if you do an internet search. There may be some duplication in there, but it’s still a sufficiently large number to suggest the need for caution and some thorough research on how to avoid the pitfalls.

To help you on that quest, here are the critical lessons learned from this case. And, they’re relevant to any project, not just ERP endeavors.

1. This was not an IT project – Yes, the project involved technology change. These days, most do. But more importantly, it required significant changes in business processes and practices throughout the organization. To give responsibility for the project to the vendor and VP of IS sealed the project’s downfall from the beginning.
2. Build and manage the guiding coalition – The consulting organization that ran the second part of the project had the players right. The CEO was the overall sponsor. Sponsorship can’t be delegated. The company had a long history of local control and local solutions. The regional GM’s had an enormous part to play to help transition disparate operating environments to one common platform. In the first fateful stage of the project, they were reduced to human resource providers. Culture eats change for breakfast.
3. If you don’t know where you’re going, you’ll end up someplace else – So said, Yogi Berra. The simplistic dictate from the CEO emphasizing time to delivery was lunacy. The fact that nobody challenged it was evidence that the right players weren’t sitting at the table. The regional GM’s would have objected strenuously. They would have insisted on factors like sustaining and improving customer service, minimizing operational disruptions, affordability of the target solution, return on investment, and other relevant and essential targets.
4. Decision making is an ongoing exercise – A project starts out as a shady gray blob with little in the way of the necessary details. As it progresses, the gray blob gradually gives way to light and insight. Each bit of light added requires a decision to move the understanding, and the project, forward. Therefore, clarity on the decision-making roles, responsibilities and accountabilities is paramount. The first PM attempted to circumvent the need for progressive decision-making with his strategy to use the functionality out of the box. Consequently, in the early stages of this project, that clarity and some key decision makers were missing in action. It just got worse from there.
5. Small is beautiful – Frequent implementations are a must, to provide learning opportunities, to build a culture of success, to manage risks, to deliver value incrementally. We also know that small implementations have a much greater track record of success.
6. Skills, skills, skills – One of the early warning signs identified by the first PM was the lack of human resources with the necessary knowledge and skills. Having a lovely software suit may be necessary, but it’s not sufficient to deliver a lasting solution. Enough people with the right skills at the right time is the force multiplier. That issue was only resolved when the regional GM’s were brought on board, and they had a stake in the game.
7. The medium is the message – The first PM prepared and distributed his status reports for the vendor and the VP of IS every two weeks. Using the same status reporting process repeatedly might be efficient, but, in this case, it didn’t drive the necessary reactions and remedies. Status reporting needs to adapt the timing, content, and delivery to the circumstances to gain the attention of diverse audiences and the reactions needed to fix the challenges identified.

You’ve heard these points before. They’re not new. They’re not magic. But they do work. So, be a Great Leader and put these points on your checklist of things to consider on your next project so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.