This is How to Develop a Great Project Scope Statement

What are the five most dreaded words in project delivery? It’s my experience with a myriad of client organizations, they are contained in that blunt, unartful utterance inflicted by every project team onto its unsuspecting client: “That is not in scope.”

Nothing takes the air out of a room faster than the client’s sudden realization that a major (or even minor) requirement will not be included in the system functionality because they forgot to ask for it, or because it had been documented ambiguously, or because it had been completely overlooked. Nothing has the potential to build client mistrust, or develop an “us” vs. “them” attitude, or discourage client participation more than the feeling that somehow they were “duped” out of getting what they were expecting from their new system.

My first experience with this phenomenon was as a young system analyst working on a large, two-year, fixed-price project for a government entity. The project had gone very well for more than a year. We had documented the project scope, defined a detailed set of requirements, and had even mocked up application screens that the end-users would navigate in their new system upon implementation. (For my younger readers, “mocked up” means rudimentary screen drawings photocopied onto overhead transparencies for better viewing in the conference room.)

The time came for the unveiling of the test system to the client team. These were the finest “green screens” ever designed for such an application, completely true to the original (and might I say, signed-off) mock-ups. The entire client project team – all 14 of them, our friends, our partners in immaculate design, people we had shared meals with and invited into our homes – gasped in unison: “that’s not what we asked for!”

I was stunned. My Project Manager was visibly panicked (did I mention this was fixed-price?). Our entire team felt sucker-punched. A year of painstaking analysis and design flashed through my mind. I was positive we had done everything right. What kind of ingrates were we dealing with? Darn Users! Can’t live with them. Can’t throw them off the building.

Scope May Be Defined, but not Understood

You know the drill by now. I’m going to tell you that in almost all such situations the project team does everything well. From a process perspective. In fact, we had done everything well. From a process perspective. Yet we had let our client down. How? Why?

In my opinion, and based on years of experience in project delivery, the team did not think ahead to the people aspects of managing the project scope. We were process experts, but we were virtually illiterate in the people aspects of managing our client participants.

This is the easiest phase of the project in which to manage the process well technically, clinically, and, at the same time, build the trust and enthusiasm of the client team using proven people-focused techniques. As I mentioned in an earlier blog post, “This is Why Project Teams Fail at Requirements Gathering,”  requirements collection is not easy work. Neither is the process of carving out project scope from all those requirements.

The management of the requirements/scoping phase is typically easier than managing upcoming phases. After all, no code has been delivered yet, so at this point in the project everything works! The project team / client team relationship is still in the honeymoon phase.

This is the point in the project to build upon those relationships and to take every opportunity to over-explain to the client participants upcoming project challenges for which they must be prepared. This is the time to turn the people skills into overdrive as that important scope boundary which will govern the remainder of the project is defined.

Prepare the Scope Statement with Full Client Participation and Understanding 

The preparation of a detailed statement of project scope in conjunction with the client participants/end-users is absolutely critical to project success:

• A clear definition of the product scope description is the starting point. The Project Charter is in place. The requirements documentation has been approved. This is the basis for segregating the system into separate functional areas that can be progressively elaborated with more detailed characteristics, rules and definitions. This is the time to cement a common understanding with the client in preparation for ongoing development activities.
• A set of acceptance criteria is established. The project team will work diligently to precisely meet the acceptance criteria, and the client staff will use these as a guide in approving the scoping deliverables. Knowing the acceptance parameters in advance helps avoid surprises at time of the client’s review of the deliverables.
• The scoping deliverables are clear, concise, and unambiguous. The scoping deliverables (which include the detailed requirements definition, as well as any ancillary documents) must fully encompass the agreed upon functionality to be delivered. Complex sections within the documents should be reviewed with the client participants to help ensure that they have been defined clearly, and that the client completely understands the detail.

  The scoping deliverables must include sections on project exclusions. These are items which will specifically not be part of the scope (see my previous blog post, “Why You Should Create a Not-in-Scope Management Plan”).

  For example, if the scope requires an on-line portal for end user access, but specifically excludes chat functionality, then document that chat functionality is excluded. Explain why. Similarly, if the project scope includes the training of 1,000 end-users, but does not include training headquarters staff, then document that exclusion and the reason for it.

  When the deliverable is reviewed, or the project is delivered, or key members of the client team change, the documentation will stand as the agreed upon, clear intent of the full scope.

• Key constraints must be documented. Every project has limiting factors or constraints. Certainly, if the project is governed by a contract or by service level agreements (SLAs), these agreements provide specific guidelines and constraints on what will be delivered. For example, the project may have a hard date by which it must be in beta testing. That is a constraint. These should be documented in the scoping deliverables to make them accessible to the client participants. If client staff have access to these key provisions, they are much more understanding of the constraints on the project and thus the limits on scope.
• Assumptions must be documented. Until the entire project is delivered, there will always be some items that cannot be fully proven or demonstrated. There will be certain assumptions, including project impacts should the assumptions not prove true, that must be documented. For example, if the scope of training is 1,000 end-users for 10 business days each with a limit of 20 staff per training session, and the client organization adds 200 people to be trained, then the assumption of training effort no longer holds true. There is now room for negotiation of the additional training requirement. However, if the assumptions are not documented, this can lead to misunderstanding and/or unbounded scope in later stages of the project.

Client participants on the project must be deeply invested in the active definition of project scope. The project scope should include both the people and process aspects of managing the project. Scope must be documented unambiguously. The project team must then deliver to the statement of project scope. What an incredible difference that will make to the execution of the project and to the end result!

Back to my earlier story of the client team whose initial reaction was “that’s not what we asked for.” Fortunately, all was not lost. We walked the client participants through the requirements deliverable (a complete statement of functional scope), and related each mocked-up screen and its rules to the physical screen they were testing. We had relied (probably a little too much) on the “trust me” factor of our well-developed client relationships to get through the deliverables review. In the end, though, the client team agreed that we had provided what was asked for.

But it could have just as easily gone badly.

The documentation was clearly in our favor. However, we had failed as a project team in not testing our own assumptions that the client participants had understood our “paper” model and narrative description of their system.
We had done things well from a process perspective, but we had failed in using that process to bring the client participants along to a complete understanding. We had failed in the people aspects of Project Management.

There is never an excuse to hide behind “signed-off” scope, even if documented in a technically correct manner. There is never an excuse to let the people issues slide by, and deliver a scoping document that the client has not fully understood.

The scope must be defined clearly in client terms. It must describe clearly what is not in scope. In defining and documenting scope, the project team should and check the client participants’ understanding frequently. The reward will be a delighted client eagerly attesting, “That’s exactly what we asked for!”

Merv Jersak
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.

To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit www.PeopleFirstProjectManagement.com.

EMAIL merv@PeopleFirstProjectManagement.com // LINKEDIN www.linkedin.com/in/mervjersak

52 Project Management Success Tips from Merv Jersak  •  Copyright ©2020. All rights reserved.