We often need to engage third party contractors to deliver a project successfully. The complexity of today’s business and technology worlds pretty much guarantees that we won’t have all the necessary skills on hand. Independent contractors can provide those needed skills and capabilities. However, managing IT Services contractors can be a challenge.
In this post, we’ll look at the experiences of a colleague of mine managing two IT Services contractors as part of a major infrastructure upgrade. We’ll also look at the steps you can take to ensure IT Services contractors involved in your project deliver everything you need, when you need it to implement a successful result.
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. Then 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. Their plan was to implement the current version and migrate all content to the new platform. They chose to freeze application and content changes until after the new version was implemented and operated successfully in production for a six week proving period. That would help keep the focus on the task at hand, accelerate delivery and reduce risk. 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 could be assigned to the project.
- The contractor’s Tier 1 support staff were not involved in the initiation phase and were not privy to key discussions and decisions. That caused rework, increased costs and schedule delays.
- There were numerous challenges with server configuration and content. 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 that was 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 fundamentals 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, including the contractors’ key decision-makers, 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.
Managing resources outside of your organization’s span of control and culture can be challenging. Dealing with resources physically removed for your site can add to the challenge. Be prepared. 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.
Finally, thanks to everyone who has willingly shared your 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, we’ll post it so others can learn from your insights. Thanks
Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. 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.