One of the most challenging aspects of a project manager’s job is the protection of the project scope – from the team members to the clients/sponsors the project manager needs to ensure the integrity of the scope is maintained so as to keep the approved budget and schedule intact. One thing that comes up in virtually every project is the discussion about whether or not something is in scope or not. This can lead to some challenging situations, especially if the client relationship is not solid. But regardless of where the relationship is at, it is the job of the project manager to maintain scope integrity and follow proper change management. So how do you win the argument on whether or not something is in scope? Well you can start with these three tips.
Have Your Signed Approvals
Your project will have some sort of a signed document from the customer that you can go back to reference – be it a statement of work or a contract or better yet an approved requirements document. Whatever it is that you have that is approved by the client that is irrefutable (i.e. verbal approvals are challenging to prove) is the first step in proving your point on scope exclusion. You should make a point of storing all written approvals from the client in an accessible space where they can be easily recalled and shared with said client to support these discussions.
Having signed approvals is a great first step (there’s no dance without this step) however the content in these approvals needs to support your case. Let’s take the example of a client wishing for a piece of functionality to be included in scope (for T&M projects this is less of a difficult conversation since you’re being paid for every hour you work – on a fixed price project this is a much more detailed conversation).
The challenge that you may often face with these types of conversations is vague language around what is truly in our out of scope. Not unlike building a court case, you and your client will evaluate the evidence (i.e. the signed approvals) and prepare your arguments for/against the scope inclusion. The clearer the language is in these signed approvals, the easier it will be to have a decisive consensus on whether or not this should be included in scope. If the wording is fuzzy it can lead to lengthy conversations and sometimes even damaged relationships when both sides cannot come to agreement on whether or not something should be included in scope or not. So the short answer is – the clearer the language is, the easier it is to argue your point.
Build a Traceability Matrix
In addition to whatever signed approvals you have, assuming you have a signed requirements document from the client, a good practice is to build out a requirements traceability matrix that outlines the identified requirements from the client and marry those requirements up to delivered (or designed) solution functionality. When you can successfully prove that the requirements are satisfied with your delivered solution, your argument about additional scope inclusion practically writes itself.
Scope discussions are never an easy subject to broach with a client, and sometimes can lead to more challenging situations however as a project manager it is your job to ensure that your project scope remains intact. Any deviation without proper change management will have negative impacts in other areas of your project (budget, schedule, quality to name a few). You need to protect scope just as vigorously as you would any other aspect of your project, even if that means protecting the client from themselves.