Today I was in a meeting where I realised some of us were working with one mental model of the project team’s role while others were working with a different one.
The divide seemed to lay in the idea of the whether performing team is a service provider to, or a change agent within the client organisation.
What do I mean by this? Let me run through some working definitions of the key terms here. These definitions are nothing too formal.
The performing team is a concept of the performing organisation. It’s lifted out of the PMBOK. The performing organisation is the organisation that is going to carry out the actual work of the project.
In some projects the performing organisation is a team wholly within the client organisation. It may also be several cross-functional teams coming together in a tightly or loosely linked association under the banner of one project or programme.
In some projects the performing organisation is wholly external to the client organisation. A fully outsourced solution is an example of this. In projects like this the client has put the project fully in the hands of their provider. This is unusual for large enterprise projects as there are so many inter-related parts, however it is not so unusual in small discreet system or facilities projects.
A third scenario is where the performing organisation is a mix of members from external partners and people native to the client organisation. In this instance you may have some or all of the IT build outsourced, but much of the project, requirements and change management work is based within the client organisation.
A service provider is someone or an organisation that is external to the client organisation and provides a service – such as building software, managing projects or whatever other needs you are unable or don’t want to provide internally.
Service providers are usually hired on a contract that specifies the services they are to provide. As most project’s don’t know all the work to be done up-front service providers use a balance of doing a bit extra for goodwill and being disciplined about change controls to manage variations from the contract and most importantly: what they get paid.
So a service provider is hired for a specific purpose. At the end of the delivery period you should e able to look back and say “Did we get what we paid for?” And service providers should be able to look back and say “Did we do what we said we would?”
Missing from this conversation is “Did the client get what they wanted?” as that issue is mostly left for the client to manage internally.
Change agents are people who work with the client. They can be internal staff or external people, and are often consultants. Their goal is on enabling the client to transform from their current state to their target state.
Their measure of success is around the achievement of the goals.
The client organisation is the organisation the project is being run for. In the case of enterprise projects it is the enterprise itself, and any times can be defined a business unit within a larger enterprise.
The client organisation is the one paying the bills, and (usually) collecting the benefits.
So where is the confusion coming from?
When you are an external performing organisation you deliver what is required in the contract, including planning documents, milestone deliverables and so on.
If you hand over a technical design document to the client and they have no-one available to read through the techno-speak that’s the client’s problem. They can either pay you to explain it to them , or go find someone else to do the same thing.
However, when you are part of the client organisation you are committed to overall project success, not just delivery per the contract.
In this case it’s up to you to help manage the client and key stakeholders through a process. Hard to read technical documentation is now your problem, not theirs alone.
And so we come to the need for a different mindset when you are working within the client compared to when you work as a services vendor.
In this instance your documentation focus needs to change from technical specifications and contractual terms to one of clear and effective communication and enabling change.
In this world it is much more important to produce project documentation that includes things like
- Problem/Opportunity statements
- Project vision
- Guiding principles
- Change strategy
- Success and Failure criteria
The more traditional approach of “Scope > Requirements > Solution Design“ becomes a secondary in importance. If you put them first you run the likely risk of leaving your stakeholders behind.