As a project manager there are few conversations that require tact and delicateness than a scope conversation with a client. Depending on the existing relationship with the client or the climate of the project, this is a conversation that can balloon into a much larger debate.
The bedrock of any good relationship is trust. Your client needs to feel that you have their best interests at heart when delivering the project while at the same time protecting the scope of the project. The project sponsor needs to have that confidence not only in your ability to deliver, but also your ability to maintain the integrity of the project scope. So where do we begin?
Clear Scope Definition
This is something that I cannot overemphasize enough. Whenever I have seen conflicts arise around what is in or out of scope, the common denominator has always been a poor definition of scope. Whether it be too high-level, ambiguous language or poorly worded scope items, not having a clear definition (and understanding) of the project scope opens your project up for interpretation for what should or should not be included.
Take a COTS implementation project for example – in addition to licensing there are typically professional services delivered as part of the overall project. Things like installation, configuration, integration and training are very common among COTS implementation projects. What the customer expects and what the proponent delivers can be two very different pictures if there is not a super clear definition of scope right up front. And while the wording of scope can be very clear, it is up to the proponent to ensure that the client understands the language and is fully aware of what is to be delivered. If there is a lot of education that needs to happen on understanding of scope, it’s likely a good practice to reword your contract to ensure an easier understanding of what is to be delivered.
Scope Vigilance and Protection
It is the job of the project manager to ensure that the project scope is protected throughout the project and that any decisions around scope changes are made by the project sponsor with a clear understanding of the scope, schedule, budget and risk impacts. As a project manager, part of the change management process is understanding if something deemed as a ‘change’ is truly a scope change or part of the original scope. This goes back to our clear definition of scope that everyone subscribes to and understands.
Nothing can suck the air out of a room quicker than “That’s out of scope for this project”. Any debate on scope needs to be done very tactfully and with a solid understanding of what truly is in scope with justification on why it is or is not included in your original scope statement. While perception of scope may vary from person to person, it’s incumbent on the organization delivering the project to ensure that the client fully understands what it is they are to expect as part of the project delivery.
Want to know how we can help you and your team? Let's talk!