I have worked on a few projects where a major stakeholder was an outsourcer, with a contracted, defined scope of work. Their stakeholder concerns have an added dimension of a contracted group of services, and a varied face to the customer, including a different culture.
When I first began to engage with this outsourcer, there was no transition process in place, the IT group would complete a project, roll it out and then toss it ‘over the transom’ to the outsourcer. Inevitably the outsourcer would have issues and bring out the unintelligible 424 page outsourcing agreement, and point out this was not in their scope! By this time, the project team had been dispersed and the business stakeholder was left with an ineffective help solution and a bad impression of the project.
Interestingly enough, the problem had never been diagnosed properly, and a lot of time, money and effort had been expended in trying to resolve this issue. There was a ton of finger-pointing on both sides, with a frustrated business in the middle. It is truly amazing how many times people attack the wrong problem!
In the BA toolkit, we have quite a few great tools to identify the problem. Root Cause Analysis was very powerful in this instance. The 5 Whys helped to explore what was the real problem, which had manifested itself in the unhappy customer, and 2 very upset support groups.
It took facilitation skills, objectivity, and plain old patience as the two opposing factions were able to air their grievances, and then able to listen to each other. It was a classic case of removing the ‘Us and Them’ mentality and replacing it with a mentality that understood that their mutual goal was to satisfy their business, and that each team had been trying to do exactly that in their own fashion. We had very well-meaning professionals, but they did not understand what is required for a smooth transition for ALL stakeholders. BA skills were fundamental to the solution:
- Relationship building
Take a look at the transition requirements for your projects. Are there more requirements that an outsourcer will need? Are they a stakeholder on your project? Have you considered the scope requirements they may drive? In our case they were an overlooked stakeholder, which caused the business a big problem.