When you think about outsourcing one or more project elements, what are you most concerned about? Missed deadlines? Low quality delivery? Inaccurate or incomplete scope? Increased risk? All of the above?
Chances are that you said ‘all of the above’, but guess what – the remote team is concerned about exactly the same things. When you are dealing with a team of people who are separated from you, everyone worries that the physical separation is going to lead to problems. While there are no guaranteed ways to succeed, by working together during project planning, and recognizing that you both share the same concerns, the chances of success can be greatly improved. That’s what I want to address in this article which is part of a series on outsourcing. The previous articles in the series can be found here:
The first thing that both the vendor and the project manager need to recognize is that you are both on the same side. Too many remote relationships are built on a foundation of mistrust – especially if we are dealing with a buyer / vendor relationship rather than different departments within the same organization. At the most fundamental level, everyone needs the project to be successful and a collaborative approach to the project will make it much easier to work together and deliver that success.
Collaboration needs to begin with the planning of the project. At the most basic level, a project plan is fairly straightforward – the work is broken down into individual tasks that are sequenced with relationships between them identified, are measured, and assigned to resources. However, when work is outsourced, there are a number of considerations that can add considerable complexity to the plan:
- Is the work that is being outsourced fully understood? If work is being given to an outside group (whether internal or external to the organization) then there will inevitably be a learning curve where the remote team needs to understand what the project is about, what is expected of them, etc. And the project manager and his or her core team (the key team members that represent all of the project functions) need to understand exactly where the responsibility of the remote team starts and stops. This may be even more complex if the work is being outsourced because of a lack of expertise within the core team – there may not be a good understanding of what is and isn’t possible.
- How easy is it to track progress? If the project is being executed using Agile methods, or if the work naturally lends itself to interim deliverables, then there will be less risk than if the work consists of just a single deliverable at the end of the outsourced tasks. If there are no obvious interim milestones then it will be harder for everyone involved to confirm that the work is on track.
- How easy is it to integrate the outsourced work with the rest of the project deliverables? If the outsourced element is a standalone component, then there is less concern. But if it has to be integrated with other project elements, then not only must time be included in the plan for that work, but also time has to be allow for learning curves, adjustments, etc. as two different elements are brought together.
Let’s look at each of these items in more detail and consider how they may impact project planning, and what you can do to ensure that these elements are appropriately managed when working with remote teams.
Understanding the Work
This is by far the biggest challenge facing projects that have elements of remote or outsourced work. Often, it is difficult to even recognize that there is a lack of understanding or misunderstanding in the first place. I have seen many situations where the vendor and the buyer both felt that there was a common understanding, only to find that what was delivered was very different from what was expected. There are many reasons why this might occur. But in this chapter, we are focusing on how we need to plan for these situations, so let’s look at that.
Step 1 - Plan time for mutual understanding of the work
The plan to have a mutual understanding of the work has to begin right up front, even before a contract is signed or a team is assigned. The mistake that many organizations make is that they define their requirements as what they think they need in terms of specific deliverables – features, colors, design elements, etc. Instead you need to focus on defining the business need in two distinct ways:
- The overall purpose of the solution to be built - what it is for, how it is used, how it drives benefits, etc.
- How the solution fits into the larger corporate purpose of your organization - your business, revenue model, etc.
That is the area where your project and procuring teams should have expertise, and that will provide the most meaningful information to the vendor. While this information may never make it into the plan as a specific line item, it is critical to building that successful plan.
You should then expand these discussions to cover the model that will be used for outsourcing, the work to be performed by each team, etc. and the relationship starts with a strong understanding of who will do what (at a high level) and how it will be managed. In many cases, your organization will have its own project manager, and will almost certainly own the overall product relationship, even if the vendor is doing most of the delivery work. Of course all of this planning takes time, and that time needs to be reflected in the plan.
With a clearly documented and internally agreed upon business need, the following becomes much easier:
- Work breakdown, vendor vs. customer ownership, estimation, and resource allocation. There is a much clearer demarcation between roles on the project – much of the uncertainty around who owns what is avoided by allowing each of the work teams to develop their own plans to meet the business needs. The project manager retains ultimate accountability for ensuring that the plan reflects all of the required tasks, but the details are provided by the relevant experts. This approach also helps the various team members to get to know one another as they work together on project planning.
- Validation of the work – while the ‘how’ to test and validate the work may still be difficult to determine depending on the unique scenario, the ‘what’ constitutes success is much easier to understand because it is defined up front in terms of business needs. This helps to avoid disagreements about whether a solution is flawed or not – the all too common ‘you don’t get what you need, you get what you ask for’ situation. I have seen many a potential problem avoided by agreement at the planning stage about the performance criteria of the completed solution.
A common outcome of this approach is that the project manager is faced with a delivery schedule which is at odds with the schedule that has been set for the project. Frequently, this results in the vendor being pressurized to deliver in less time than is required to complete the work. While project schedules and deadlines are obviously important, the idea that a party who may lack the understanding of exactly what is required overriding the duration estimates provided by experts in the field, is flawed at best, and disastrous at worst!
Tracking Progress
One of the concerns that organizations often have with outsourced work is the lack of visibility into the work that is being done. This is one of the reasons why customers are often enthusiastic about Agile-based approaches as they force vendors to provide interim deliverables on a regular basis. However, this isn’t always possible, and there will be situations where there are no deliverables until the work is complete, especially with business deliverables instead of technology. As an example, I worked with a sales team that outsourced development of a new sales compensation model and they saw exactly this - because of the interdependencies between different elements, the model was developed before they saw what was being developed. This doesn’t mean that the work can’t be tracked. However, the old Russian adage applies here – ‘doveryai, no proveryai’ which roughly translates into English as ‘trust, but verify’.
Step 2 - Ensure that progress tracking is appropriate and objective
The group that is doing the work, whether it is a remotely located internal department or an external vendor should be trusted. If the relationship between the two parties does not have a foundation of trust then there will be too much focus on the people and the relationship, and not enough focus on the work. However, that trust shouldn’t be blind faith, there should be attempts made to verify that things are going well, and that is what needs to be built into the project plan.
The plan should include regular checkpoints with clear agreement of what is expected - achievement of those checkpoint expectations demonstrates progress on the project. These may not be tangible deliverables, but they can still be ‘real’. In the sales example, we had the vendor demonstrate the different elements that they planned to incorporate in the compensation models, the different roles and levels that were being developed, the variables that affected commissions, etc. In isolation, these are meaningless but they demonstrate continued progress towards the goal, and importantly they are objective measures rather than judgmental ones.
There is a tendency to assume that verification is easier when the work is being carried out by a remote team within the same organization than when an external vendor is involved, but this isn’t necessarily the case. In the internal department scenario, the people involved may be more aware of how to ‘get away with things’ if they were so inclined; so I always treat verification in the same way regardless of whether the remote team is made up of internal or external resources.
In addition to providing regular status updates at weekly meetings, shared through collaboration tools and ‘as needed’ conversations between the project leads, I always ensure that the project manager schedules more formal gateway reviews on work items that he or she has less visibility into. This will be in the form of a structured discussion at key points in the project where all stakeholders review the ‘checklist’ of items required to pass through the gate and achieve the interim milestone. That may include the handover of interim deliverables, but it may simply be showing completed data models, confirming designs, etc. These checkpoints should be viewed as confirmation that the vendor’s work is on schedule, and where possible should be tied to payment schedules. They also provide an opportunity for corrective actions to be identified and approved, if necessary. This is where the trust part of ‘trust, but verify’ comes in – if there is no trust between the parties then there will be a tendency to hide problems (or to assume that problems are being hidden) and there will be no ability to agree on a realistic corrective plan that will help to ensure that the project is successful.
Even when there is trust between the parties, there may still be a tendency to view the situation differently – a vendor may view a two-day delay as minor, whereas a customer may view it as the start of a major problem. For this reason I always make sure that the criteria for success in these planned reviews is documented and agreed to up front. Examples may include anything from sign-off on a document to completion of certain modules of work. I have even seen measures around hiring people to perform the work and delivery of documentation. The key is simply to agree at the start of the project what success looks like at these milestones so that there is no subjective negotiation during the reviews. At that point, both parties should also agree on the size of delay, cost overrun, etc. that will trigger corrective actions for each of the milestone reviews. Thereafter, the review itself simply becomes a case of comparing actual values with the plan and acting accordingly.
When scheduling these reviews the project manager needs to ensure that they occur frequently enough to prevent problems from escalating out of control, but also spaced out enough to allow for real progress to be made. Moreover, they need to begin late enough after the work starts to have something solid to review, and early enough before the end to provide time for recovery and correction.
Integrating the Work
In many projects, integration is something that is under-planned. The need to bring multiple project elements together into a cohesive solution necessarily occurs late in the project when time schedules are often under pressure, and project managers frequently seek to ‘save’ time by compressing the amount of time that is allocated for integration. This rarely works well, and when outsourcing is brought into the mix, it is a recipe for disaster. It should be noted that this is not necessarily a technical integration; it may simply be the integration of technology into business operations - the complexity can be just as significant.
Step 3 - Plan for a successful integration
You need to plan for integration right from the outset of the project, with an expectation that it will be difficult and will require adjustments to be made as different components from different sources are brought together. The need for well-executed integration is even more important if there haven’t been interim deliverables, and any problems that are missed during this phase of the project will make it into the final release where end users will find the problems! The sales compensation plan project that I described earlier involved executives and the vendor travelling the country to explain the model to staff and then revisiting them after 3 months to address questions and concerns - an expensive integration, but one that helped ensure that things went smoothly. That may be overkill for your project, but you need to consider all of the implications when the different project elements come together as a complete solution – it is your organization that will be at the frontline of support and issues.
From a planning standpoint, if some of the work is outsourced, I always begin integration activities while the build work is still underway. At a minimum, the teams can build a better understanding of how they will manage the integration and in turn this helps them to identify where potential problems may occur. This approach also moves the learning curves into earlier phases of the project and avoids the need for rapid learning at the start of integration – further reducing the likelihood of mistakes being made.
To further ensure that integration is a natural extension of the build work that is occurring on projects, I also make sure that integration planning is a natural extension of earlier work. The integration plan shouldn’t be built in isolation from all of the other work that is undertaken; rather the documents and artifacts that are developed for requirements, design, etc. should naturally feed the integration planning activities.
Conclusions
So what does all this amount to when we bring it together? In today’s economy where organizations are looking to focus more and more on their core areas of expertise, and where the rate of change in technology continues to accelerate, the need for specialist functions to deliver projects is only going to grow. This means that the number of projects that use remote teams, whether internal or external, will continue to increase as organizations seek out those specialist functions, and if organizations don’t do a better job of recognizing that those projects need to be managed differently, then they will continue to fail.
Organizations need to recognize that using outsourced workers can dramatically increase their chances of success, but only if the project is managed appropriately, recognizing that these projects are different from initiatives where all resources are co-located. There is no magic bullet solution, but taking a little bit of time and effort to structure this simple three-step approach can go a long way in helping you avoid the pitfalls.
About the Author
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada based management consulting firm with a strong emphasis on organizational transformation, portfolio management and PMOs. Andy has a track record of success managing business critical projects, programs and portfolios in Europe and North America in industries as diverse as investment banking, software development, call centers, telecommunications and corporate education.
Andy is an in demand speaker and moderator who delivers thought provoking content in an engaging and entertaining style, and is also an instructor in project management related disciplines. He always strives to provide thought provoking presentations that drive his audience to challenge accepted norms while providing actionable content that can be applied in the real world. Andy’s first full length book ‘Risk Management for Project Driven Organizations’ is now available.