We launch projects to deliver changes within our organizations. But, sometimes changes occur within those projects that don’t receive the attention they deserve, like movement of key personnel or other influences within or external to our organization. That’s when we need to beware of the change within a change. That’s when we need to do a checkpoint, to reengage the stakeholders, revisit the fundamentals and reset the project’s course.
In this post, we’ll review the damage done when one organization didn’t pay sufficient attention to a change within a change. It’s easy to get distracted when dealing with a major project, like an acquisition. But, as we’ll see, being busy with a big change is no excuse for ignoring other significant changes that are going on concurrently. Appropriate oversight and diligence are always needed.
Thanks to A.T.P. for the details on this story.
This bank purchased an investment organization that ran into difficulties as a result of the 2008 financial crisis. As the bank was dealing with the integration of the acquired company, they discovered that the investment organization had undertaken and were in the midst of a major upgrade to their core administrative system involving the software’s vendor and a sizeable in house team.
The bank inherited the $3 million contract with the vendor negotiated by the investment company. The original plan was to have the software upgrades completed and installed by the time the acquisition was finalized. That hadn’t happened. The price was based on specifications provided by the vendor detailing the changes that would be made to the application. Most of the $3 million had been spent at the time of the acquisition. It was estimated by the previous project leader that another $1 million in vendor charges would be needed to complete the upgrade.
As a result of the acquisition, the bank found it had excess management including the former Director of Operations from the investment organization. So, they assigned him to run the software upgrade as the project director and redeployed the previous project manager to another part of the overall acquisition project.
With so much change going on as a result of the acquisition, the bank decided to let the software upgrade proceed as planned under the guidance of the new project director. The target budget for vendor expenses was $4.2 million. The project was planned for completion in ten months.
As the project progressed and the project director started to get acclimatised to his new role, a number of concerns began to surface:
- Apparently, the software vendor wanted to exit the market for the particular product being used by the investment company. It was doing the project under some duress and with the benefit of a sizable bonus above and beyond the actual project costs.
- The vendor had pulled key resource off the project in the past and continued to do so. That was a major contributing factor to the cost overruns and extended schedule.
- The bank’s quality assurance staff found that the specs didn’t provide the necessary insight to support testing to confirm the software addressed the company’s needs.
- When the director starting chatting with the business executives about their goals for the project and their operational requirements and priorities, he uncovered a quagmire. The executives had different views on why the project was launched, what the benefits were, what organizations were affected and how much.
What seemed like a reasonably safe and routine project was turning out to be anything but. The project director assigned a team of analysts to work with the business units affected to go back to basics, get agreement on the opportunities being targeted, the projects goals, benefits, priorities and flesh out the specifications so the testing could be carried out expeditiously. Now that the business units were being engaged, the business heads started demanding significant changes in the software beyond what had already been delivered.
The project director started negotiations with the vendor to add the additional functionality and ran into road block after road block. Their quotes to include the additional functionality were excessive (an additional $2.5 million), the time frame unacceptable (two additional years). He wanted them to leave current staff on the project and bring back some key resources that had been reassigned. They refused. The vendor made it perfectly clear that they had no interest in expanding the project beyond the original scope.
Fourteen months after the decision was made to continue the project, and four months after the revised completion date, having paid the vendor $4.6 million plus the bonus, the project director recommended pulling the plug on the project. His exit strategy included:
- Negotiating the purchase of the source code from the vendor, including the current production version and the development version with all applied changes to date.
- Completing the project with in house resource only after a rigorous priority setting process to ensure real value from the investment.
- Development of a phasing and staging strategy to accelerate benefit delivery and reduce risks.
The project director was able to negotiate a non-exclusive purchase of the code and related utilities and documentation for $425,000. He was also able to hire three key staff from the vendor who had years of experience with the system. With the help of senior business managers he was able to prioritize and value the remaining work and package it into three distinct releases. The final release was implemented a year after parting ways with the vendor at an internal cost of $900,000.
How a Great Leader Could Have Changed the Outcome
Isn’t hindsight wonderful! We now know that this project was in trouble when the bank took over the investment company. It was still in trouble when the bank made the decision to let the project run its course. This $3 million project that was to be completed prior to the acquisition actually cost over $6 million and finished over two years late.
The steps the project director eventually took to reign in the runaway project were the right ones. Unfortunately, he waited too long to get up to speed. What could he have done differently?
- He sought to get the vendor on side and ultimately realized the vendor had other priorities and wasn’t interested in the market, the software or the project. The vendor had been saying all along that it would not continue to support the software. Why then did the investment company decide to proceed? Why did the project director pursue the purchase of the source code as his only option? Both occasions were perfect opportunities to look at other alternatives that would offer long term value including other vendors and other platform offerings.
- He got the key business decision makers together to make the call on priority, value and packaging. Unfortunately, that should have happened as soon as he took over the project director role. He would have discovered that they had not been actively involved, didn’t have a consensus on what they were trying to achieve, didn’t know how well the revised software would satisfy their needs and hadn’t participated in any implementation planning or priority setting.
There is some key knowledge that is required about every project by all key stakeholders. If it’s not captured up front, invariably it will create difficulties later on. To remedy those problems, the missing knowledge will have to be acquired and revisions will have to be made in light of that knowledge, costing time and money. In this case, that’s exactly what happened. It seems everyone was too preoccupied with the big change, the acquisition, to spend quality time and effort on a smaller but still substantial project.
So, whether you’re starting out on a new project or getting involved at some later point, whether you’re looking after a smaller part of a bigger change, do a checkpoint. Make sure that essential knowledge is available and assimilated by the key decision makers. That includes the following:
The framework above includes a portion of the full Project Pre-Check Decision Framework.
So, if you find yourself in a similar situation, don’t hesitate to do a checkpoint. Check that the essential knowledge is available and agreed to by all the key decision-makers. Finally, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember to use Project Pre-Check’s three building blocks right up front so you don’t overlook those 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 to implement the empowered stakeholder groups critical to project success. Drew can be reached at firstname.lastname@example.org