Have you ever had a senior executive dictate a course of action you knew was, at best, risky, at worst, downright irresponsible? Unfortunately, it happens all too often. What measures can you bring to bear to save the day? This post suggests how to deal with a renegade executive – that we counter that out of control passion with discipline, and stakeholders.
In this post, we’ll look at the damage a CEO inflicted on his organization when he failed to fully assess a vendor’s claims and refused to listen to and act on the facts when the purchased solution failed to deliver to expectations.
Thanks to reader P.A. for providing the details on this case.
This mid-sized general insurance company supported its core personal and commercial insurance lines on decades old mainframe applications that had been modified and added to over the years to the point where they were costly to operate, difficult to change and slow to respond to new opportunities.
The CEO of the insurance firm had a friend and former colleague who had recently joined a major software development and outsourcing firm in a senior capacity. The friend started to pitch his company’s new general insurance system. The pitch included the fact that the system was written in the latest, object oriented language and ran on open source software. The friend suggested the new system would reduce the insurance company’s ongoing operating costs, improve their ability to implement changes quickly and correctly and reduce the cost of those changes dramatically.
The CEO was swayed by the arguments and brought in the CIO and the VP’s of the two product lines to hear his friend’s pitch. The CIO saw the proposed solution as a way to get out of the legacy applications’ limitations and be able to offer shiny new technology to retain and attract new staff. The product lines VP’s saw the proposed solution as a way to increase operating profits. They all agreed it sounded great and so collaborated to recommend the project to the company’s Board. The Board approved the project.
The proposal approved by the board positioned the vendor’s system as a turnkey solution. All required functionality would be delivered by the vendor. The insurance company was responsible for building interfaces to other corporate applications including finance, management information, human resources, etc. The proposal included net annual savings of $2 million, an estimated cost of $5 million and a project timeframe of 48 months from inception to full benefit realization for both product lines.
The benefits would be realized from reduced hardware and operating software costs. A number of intangible benefits were identified but not quantified including faster implementation of changes, improved software quality and fewer operating problems resulting in greater productivity for administrative and operations support staff.
The CIO assigned a senior project manager to the project. The assigned PM had years of experience with the existing applications, knew the business and the key players and had reasonable success in the past although not on anything this large. The CIO expected to fill that experience gap by assigning experienced staff from the software company’s pool of PM’s.
The CIO also formed a steering committee that included himself, the two product line VP’s, the Director of Computer Operations and the head of Internal Audit. The steering committee was to meet monthly.
The assigned PM proceeded to line up staff from the two product lines to help define process requirements and test the new functionality as it was delivered. He brought a seasoned programmer analyst on board to work with the business staff and bridge to the vendor’s staff. The PM’s plan was to set up a test bed with the vendor’s software and have the business staff review functionality on a process by process basis. Gaps and differences in functional requirements would be documented and returned to the vendor to be addressed.
To get the test bed up and running, the PM approached the Director, Computer Operations to acquire and install the new hardware and operating system software and services. The PM’s request was met with total surprise. The Director claimed he didn’t have the budget, the staff or the space. It wasn’t on his priority list! A hastily called meeting with the CIO got the Director on side, reluctantly, secured the capital and expense funding, confirmed the priority and resolved the space issue.
Unfortunately, the director had little experience and minimal contacts in the open source technology space. An urgent appeal from the CIO to the application vendor yielded the necessary contacts to get the infrastructure ball rolling. However, it took three months for the necessary equipment and software to be delivered, installed, configured and made operational and to contract with the vendor for the staff with the required skills and experience.
Without the test bed to assess the functionality of the software, the PM turned to the vendor for application documentation. The business staff could use it to start the assessment. It took six weeks from the date of the request for an envelope to arrive. An envelope! The documentation consisted of a twenty-two page marketing brochure covering all the features, functions and capabilities the software would have. Would have! Further pushing and prodding by the PM revealed the startling truth – the system was still early in its development cycle and the core functionality for the personal line wouldn’t be finished for two years. There were no plans in place for the commercial insurance components but the vendor insisted that the plans were being worked on.
It went downhill from there!
Instead of pulling the plug then and there, the CEO insisted that the project continue. He justified the continuation on the basis that they would have complete freedom to customize the application going forward. That was a very costly decision!
- The first leg of the personal lines application – auto coverage – was completed for the first state four years after the project started. The last state was finally implemented four years after that.
- The home insurance coverage component was being worked on eight years later but still not done.
- The commercial lines functionality will probably be dropped altogether.
- The organization is now on its third CIO and fifth project manager. The original CEO is still calling the shots.
- Total costs to date exceed $20 million and operating costs have not only not been reduced as planned, they have grown by roughly $5 million annually to support both the new and old applications and infrastructure.
How Great Stakeholders Would Have Helped
This was a CCoCC (classic case of creeping commitment). The CEO bought a “pig in a poke”! It’s hard to imagine this kind of fiasco happening in this day and age. It was poorly conceived, badly structured and terribly managed. When you’re committing millions of dollars of your organization’s scarce capital to a project, you need more than an old friend’s word that things will be wonderful.
There were three factors that caused this failure:
1. No Stakeholders
The Line VP’s, CIO and Director, Operations had no skin in the game. The CEO called the shots. The other participants had no idea what their roles and responsibilities were. The application vendor wasn’t represented in the steering committee, nor were the hardware and software vendors. And where was the Board oversight?
Had the other participants felt some responsibility for the decisions and outcomes, there would have been push back. The Line VP’s would have seen their anticipated growth in profits turning into a black hole. The CIO and Director, Operations would have recognized the challenges from the new infrastructure and the incremental risks to their organizations. The application vendor would have understood the threat to its market credibility and future profits. Unfortunately, the CEO was left to his own devices, to tilt at windmills.
2. No Measure of Worth
There was absolutely no boundary on expenses, no understanding of how much the organization could afford to spend. There were no formal gates or checkpoints where progress and risks could be assessed and go/no go decisions made. The contract with the vendor was as airtight as Swiss cheese. And there was no mutual buy-in to an upper limit on the contract.
Finally, continuing in spite of the setbacks was the order of the day. “We’ve invested too much to cancel now” was the ongoing mantra. What really mattered was not what had been spent. That was water under the bridge. What counted was whether this was a good investment looking forward. It wasn’t!
3. No Discipline
The normal project disciplines were almost completely absent because of how the venture was positioned – bring in some new application software and move the business over to it.
- There was no due diligence on the offering. There was no RFP/RFQ process to consider alternatives. There was no checking of customer references. Of course, there were no other customers. They were the first.
- There was no allocation for building the new infrastructure and for the staffing and training that would be required. There was no planning or architecture to guide the building and operation of the new hardware, software, services and utilities and to manage the new relationships.
- There was no quality plan. No nonfunctional requirements targets. There was no change control process, no risk plan and no formal issue management mechanism.
In short, this was an outrageous, costly, seat-of-the-pants undertaking that should have been stopped before it even started. Isn’t hindsight wonderful?
So, if you find yourself in a similar situation, and I hope you never do, temper that executive passion with disciplined best practices and the support of committed stakeholders. And, put these points on your checklist of things to do so you can be a Great Leader. 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.
In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks
Drew Davison is the owner and principal consultant at Davison Consulting, a senior consultant at Mapador Inc. and a blogger on Project Times. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at firstname.lastname@example.org.