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 so 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 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 is 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 so poorly conceived, so badly structured and so 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:
- 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 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.
- 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 a leaky ship. 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!
- 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?
If you find yourself in a similar situation, and I hope you never do, put these points on your checklist of things to do so you can be a Great Leader. And remember, look at Project Pre-Check’s three building blocks right up front so you don’t overlook the 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
Don't forget to leave your comments below.