Project Management

Manage accountability in outsourced projects

Dr. Andrew Maker shares his advice about accountability for project managers seeking to apply PM processes to outsourced suppliers.

While participating in a LinkedIn project management forum, I read about a project management challenge that commonly occurs in IT organizations managing outsourced projects and balancing delivery with accountability. The PMO consultant was working with a client to develop project management processes for projects that heavily relied on outsourcing. Each project involved initiating the project, defining the problem, and following a request for quote process to evaluate, procure, and implement a solution. With each implementation, the performing supplier would provide project management staff to deliver the project in addition to the technical resources. The client also staffed project managers to implement this project. As you can imagine, understanding the specific roles, responsibilities, and overall accountability quickly became a source of confusion across the portfolio.

This situation raises a number of questions for the organization and the supporting PMO. Here are some of the questions you might have if you find yourself in a similar situation, along with my suggestions for handling these complicated issues.

How do the project scope statement and statement of work (SOW) deliverables differ for insourced and outsourced projects? Who is responsible for completing these deliverables?

In a purely insourced project, the project manager develops the project charter, scope statement, and supporting work breakdown structure (WBS). In outsourced projects, an SOW is typically developed to deliver a portion of the WBS or the entire project. When outsourcing, the SOW contains specific deliverables the performing supplier will produce, including assumptions, constraints, and expected service level agreements.

Performing suppliers will negotiate the SOW, but ultimately the company's project manager needs to own these deliverables. In some cases, the project charter, scope statement, WBS, and other project deliverables may be part of the SOW for the performing supplier to provide. In this situation, the company's project manager still needs to collaborate and provide overall approval of these project deliverables.

Who owns, develops, and manages the project schedule?

I've heard a lot of debate about this question. I worked on outsourced projects where I managed an integrated project schedule, and I've been on projects where the outsourced vendor managed the entire project schedule. Some project teams, both internal and external, refuse to provide a detail schedule and rely on milestones. Other project teams want a completely integrated schedule across a common resource pool.

My preference is to jointly develop an integrated project schedule with the vendor so the key milestones, checkpoints, core deliverables, and corporate project management processes are supported. The supplier can detail their specific project tasks to deliver the contracted work. Each week, we conduct a comprehensive schedule review so everyone has the transparency and open communication across the project.

If I outsource a project, I rely on the supplier's project management staff to deliver and manage the project mechanics. As the client project manager, I am still responsible for integrating the outsourced deliverables back into the company. It is important to develop trust and transparency and demonstrate flexibility with the supplier. These are best fostered by working together rather than "throwing the project over the wall" and expecting the supplier to deliver all the work.

A payroll vendor may agree to process payroll for a company and even provide new interfaces to legacy systems; however, it is the client project manager's job to ensure the legacy systems can support new changes, communicate with downstream systems, and provide proper organizational change management. The supplier can still help with these mechanics, but you can't outsource leadership.

Who is responsible for the project -- the company or the performing supplier?

The supplier is responsible for the deliverables identified in the SOW. When there is a good working relationship with the supplier, both parties will be flexible on scope and responsibilities. When contract disputes occur, each party will follow the letter of the contract. The supplier may be responsible for specific deliverables, but ultimately the client project manager is responsible and accountable for delivering the project.

Projects generate from a business need. Corporate business customers are depending on the project manager to deliver the project. If the project manager chooses to outsource the delivery, the project manager is still accountable to the business customers and the sizeable investment. When projects get tough, it is easy to say "It is the supplier's problem," but as effective project managers, we need to help the supplier be successful.

How do the project management artifacts and deliverables change to adopt an outsourcing methodology?

The core project documents still need to exist, including the project scope statement, WBS, detailed project schedule, risk log, issue log, change log, etc. Companies leveraging an outsourcing strategy also need to develop acceptance criteria for specific project deliverables.

What happens if the supplier only provides a 10 task project schedule? What if the supplier produces poor deliverables such as poor code, poorly written training materials, or useless test cases? By establishing acceptance criteria for each of the major project management and system development life cycle deliverables, the company and the supplier have a shared definition of quality.

Companies can risk defining an abundance of acceptance criteria that produce diminishing returns. Do we really need acceptance criteria on a properly formatted project issue log? Flexibility needs to be applied, as the supplier wants to deliver for the client without incurring additional administrative burden that they may not have planned for during the proposal response phase.

Independent of insourcing or outsourcing, the client project manager still needs to juggle the triple constraint of time, scope and cost. Outsourcing is just one additional tool to successfully deliver a project. The project management methodology, project artifacts, roles, responsibilities, and expectations need to be defined upfront so both parties deliver with mutual trust, transparency, and flexibility.

Do you agree?

For those of you familiar with outsourcing, do you agree with these responses? What other advice do you have for project managers seeking to apply project management processes to outsourced suppliers? Please comment in the discussion.

Additional TechRepublic resources about outsourcing

If your organization uses outsourcing as a delivery strategy, you'll find these additional articles helpful.

About

Dr. Andrew Makar is an IT program manager and is the author of How To Use Microsoft Project and Project Management Interview Questions Made Easy. For more project management advice visit http://www.tacticalprojectmanagement.com.

3 comments
CACASEY
CACASEY

The success of any outsourced relationship depends on the soundness and thoroughness of the contract, especially around the areas of governance and accountability. I find in my practice there is a great deal of wishful thinking and unvoiced expectations by clients that ultimately lead to difficult situations when dealing with outside suppliers. As Tim suggests, the time to decide and articulate accountability is before the project begins, not during.

Tim Slartibartfast
Tim Slartibartfast

My first observation is that this article blurs the boundary of project and contract management, which are two similar but different skill sets. If the work is 100% outsourced, what is left is the contract management, and without any direct control over resources or immediate visibility of in-house issues on the part of the contractor, you cannot hope to be an effective PM for the job. However holding the other PMs to account for their performance is an equally important but different job. The difficulty I have with the debate around the quality of the suppliers’ plans detail is that this would be part of the tender process. The project should not start until what is to be done and how it is to be controlled are documented and agreed. Even an agile project, if being sold or contracted for anything other than an open ended hourly rate, must have some parameters of minimum delivery specification and scheduling, dispute resolution, quality controls, etc. otherwise who will buy? “If I have 6 hours to cut down a tree, I will spend four hours sharpening the axe” - Abraham Lincoln There is no reason to expect that having a clear framework and strong well defined contract are any preclusion to collaborative or transparent working. The time taken agreeing the contract and the specification (including the plan) are part of establishing the project, not project delivery. Ultimately the supplier (or their PM) will either do the job or not , and in the case that things are going badly, the contract needs enough teeth to be able to enforce action, be it a change of staff or terminating the service and selecting a new provider. "Outsourcing" or "subcontracting", it is not a new issue, and there is little to match an open and collaborative planning approach with all the parties to develop the best outcome, and little to incentivise the supplier, or protect the customer than a well thought out set of contract ts and cs.

pjpfowler
pjpfowler

This article is very good, it covers most of the challenges I face on a project in KL, Malaysia which I'm trying to remotely manage from my base in Singapore. I spend 1-3 days a week in KL and rely heavily on the clients resources to manage the vendors to who a growing percentage of the project work is going. My challenge is, most of the clients IT staff are support services and not PM trained staff. The project is a major Data Centre migration with systems consolidation work included and it is, at the very best "High Risk" even with experienced PM's on board. The client is a major player in its industry and provides public services so down time is definite No No. However, their current infrastructure is falling over almost daily so the pressure is on to move their internal DC's to the new hosted DC site which is Tier 3 conformant and professionally managed. We're also now looking at a Live-Live DR solution using a second DC which I'm building the RFP for. As you might imagine, the overall complexity of this program of work is not something that should be undertaken by inexperienced PM staff. We're 10 months into the project and I believe we have another 18 months of work to go. Your article sums up most of my challenges.

Editor's Picks