This U.S based financial services firm acquired content management software a number of years ago to manage the content in their web sites and Web based applications. With the competitive pressures to enhance and expand their Web offerings, the company ignored the vendor’s periodic upgrades to the content management software until they found their version was no longer supported. Not an ideal situation for mission-critical services!
The company immediately launched a project to upgrade the content management software to the current version and migrate all content to the new platform. To keep the focus on the task at hand, accelerate delivery and reduce risk, no application or content changes would be made until after the new version was implemented and operated successfully in production for a six week proving period. The change was expected to cost $600,000 and take six months to complete.
This organization outsourced the maintenance of their desktop devices and servers to two different contractors – one looked after the client side, the other managed the server infrastructure. Because the content management software upgrade involved both client and server components, both contractors were engaged to manage the changes to their respective platforms. An internal team was formed to plan and manage the overall project and migrate the content to the new environment. The project was headed by my colleague, a great PM with a terrific track record of project successes under his belt.
The project was delivered successfully, but five months late and sixty percent over the original estimate. The vast majority of the overrun came from the contractors’ failure to deliver. Some examples:
On the server side:
- The contractor took 4 months to get the statement of work to the point where their PM’s could be assigned to the project.
- The contractor’s Tier 1 support staff was not involved in the initiation phase and were not privy to key discussions and decisions, causing rework, increased costs and schedule delays.
- There were numerous challenges with server configuration and content where the contractor made unilateral decisions that were not discussed with the project team. The remedial effort wasted scarce time and money.
On the client side:
- Much of the effort focused on developing scripts to update the local and remote PC’s. The scripting work was done by an offshore team who were not very proficient. The quality was spotty, the work wasn’t completed on schedule and communication regarding progress was poor. In addition, the PM assigned by the contractor to oversee the work didn’t seem to have much influence over the offshore team.
- As a precaution, the PM asked the contractor to scan the desktops to ensure they found all machines with the software / code requiring upgrading. The results revealed there were far more desktops to upgrade than the business had advised, a significant expansion of the scope.
- There were a number of problems with the rollout that the contractor was slow to respond to, delaying completion and frustrating the business.
How a Great PM Could Have Changed the Outcome
If you’ve read my previous articles and posts, you know I’m fanatical about the importance of the Project Pre-Check building blocks – stakeholders, defined processes and proven best practices in the form of the Decision Framework. If this great PM had applied those building blocks to this project, there is no question in my mind that the results would have been much better and the journey would have been less painful. Here’s how:
- Stakeholders: the project did not have adequate stakeholder representation from the contractors. It needed people who could make binding decisions on behalf of the contractors to achieve the project’s goals and direct activities within the contractors’ teams to deliver accordingly.
- Defined Processes: there was no established Technology Change process within the company or offered by the contractors that the participants could use as a road map for managing the change. That lead to numerous disconnects between the project team and the contractors on key fundaments including roles and responsibilities, progress reporting, content and timing, requirements documentation, managing scope and ongoing issues, the quality expectations and a plan to deliver to those expectations. Spending some time up front with the contractors mapping out the process to be used would have avoided many of the issues that caused delays and increased costs.
- Best Practices: the Project Pre-Check Decision Framework includes 125 Decisions Areas that stakeholders can review in two hours or less to identify the ones most relevant to the project at hand. Had this project’s PM sat down with the other stakeholders and reviewed those Decision Areas, chances are they would have identified the following as highly relevant.
- Stakeholders and their roles and responsibilities
- Burning Platform
- Change Control
- Issue Management
- Risk Management
- Communication Plan
- Quality Plan
- Change Management
Addressing these and other relevant Decision Areas up front would have ensured an engaged stakeholder group and reduced or eliminated the ongoing debates on a variety of fronts as well as the costly rework that ensued. It would have helped constrain scope and focus the contractors’ efforts on the priority requirements to deliver on budget and plan. And, it would have been a much more pleasant experience for all involved.
If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.
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 have a go.
Don't forget to leave your comments below.