Why You Should Create a Not-in-Scope Management Plan

Scope Management Includes Not-in-Scope ItemsConsider the Scope Management Plans that you have developed or managed to. Were they definitive in setting boundaries around functionality to be automated, technology, project management processes, and methodology? I would expect a resounding “YES!”

But did these plans also include chapters on what is not in scope? Probably not.

You only need to experience a situation like the one described in my previous article, “Why You Should Plan Scope Management, not Just Do Scope Management”, once. Suddenly creating a Not-in-Scope addendum to the Scope Management Plan becomes an essential part of your project management playbook.

First let’s review:

What Is Project Scope Management and Why Is It Important?

In short, project scope management defines the scope of the project as unambiguously as possible within the goals and objectives established by the prime Stakeholder(s). It also provides tools and techniques to enable the Project Manager to estimate and allocate the necessary resources to successfully complete the project.

The PMBOK® defines project scope as the work that needs to be accomplished to deliver a product, service or result with the specified features and functions. Project Scope Management, therefore, involves planning how the team will manage scope, and how it will monitor adherence to scope as the project progresses. The Scope Management Plan documents the boundaries of the project, the roles and responsibilities of each team member (including those team members loaned to the project by the client organization), and the review and approval of deliverables, perhaps even of interim work products.

Formalizing scope management into a plan, and including it within the overall approved Project Management Plan, raises its importance in the eyes of the Stakeholders and team members. It provides the boundaries within which the project will operate and thus helps ensure that only the work that is contracted for is the work that will be delivered. No more. No less.

Given the above summary:

What Is Not-in-Scope Management and Why Is It Important?

It’s obvious, right? If scope management is delivering solely what is within the approved project boundaries, then not-in-scope management must be monitoring the project such that items outside of the project boundary are not delivered with the final product (yes, change control factors in here, but change control processes are not germane at this point in this discussion).

Project Managers often argue that if they know what is in scope, then by definition they know what is not in scope. If they manage to the approved scope, then by definition they ensure that what is not approved is not included in the final product.

Logically, this seems to make sense. But, practically it’s a risky assumption to make.

My project delivery experience tells me that the Scope Management Plan must also define as unambiguously as possible what is not within the boundaries of the project. Documenting not-in-scope items establishes unequivocally what the team will not be spending (actually, wasting) precious time and effort to deliver.

Consider these project circumstances and my recommendations:

  • Document functionality/sub-functionality that will not be included in the functional scope of the project.

    An argument that I have heard from Project Managers goes something like this: “We’re implementing a payroll system; why do I need to document that we’re not including a word processor or accounts receivable or general ledger in the scope of the project.”

    That is, of course, absurd. That is not the purpose of documenting functionality that is out of scope.

    An example will explain this more clearly. I was serving in the Project Management Office (PMO) of a very large Health and Human Services automation project. As my team prepared the Request for Proposals (RFP) for the project, the primary Stakeholder stated that all 40 of her department’s public assistance programs were to be automated, and therefore part of the overall functional scope for the project.

    We performed an initial analysis to document a more detailed functional scope for the eventual bidders. As we did this, we learned that several of those 40 programs would be sunset before the project was scheduled to be completed. We immediately brought this to the primary Stakeholder’s attention, she agreed to remove those programs from the scope. This was documented in detail in the not-in-scope portion of the RFP, which was later memorialized by the vendor in the Scope Management Plan.

    Deliberately marking these programs obsolete and therefore out of scope undoubtedly saved the project hours, days and weeks of unpleasant scope, contract and change order discussions later in the project. From a people aspects perspective, we were able to save thousands of hours of wasted time, effort, and resources; and the demotivation of project staff that always accompanies massive rework.

  • Document features within project technology that will not be employed.

    Technology is not typically a consideration for scope management, but it’s nevertheless prudent to review its features and benefits to ensure it can be delivered as proposed and function as required. Making a wrong assumption about technology capabilities can create serious issues for a project.

    On one very large project, our firm agreed to use the project scheduling software mandated by the client. However, the client was not aware that its required tool was deficient in certain critical features when handling large projects. We were aware of the deficiency from previous experience, and documented it in the not-in-scope chapter of the Scope Management Plan. We described what the scheduling software didn’t handle well and offered a way to manage the data outside of the tool.

    The client accepted our caution and alternate solution and saved a major disruption to project execution from what would have been an inevitable failure in the software package.

    I’ve served on projects where a critical software tool failed: project management software, testing tools and others. The setbacks are devastating and demoralizing; but they can be handled up front by documenting what features of the tool are in scope and what are not.

  • Document aspects of project management processes that will not be changed.

    IT providers have processes by which they deliver projects. These processes have evolved over time. They may be tweaked for given projects, but they are proven and part of the project management process.

    What does a Project Manager do if the client, or even his boss (yes, I’ve seen this happen!), insists on changes or shortcuts to the process? My advice: Project Managers must not concede anything that is material to their ability to deliver successfully. Besides, if they do concede and things go wrong, no one will remember that they were asked to compromise.

    For example:

    • On one project that I managed, our process required formal monthly status reviews with the primary Stakeholder to keep him abreast of project progress. He attempted to waive this off and asked that we schedule these sporadically on an as-needed basis.

      We did not comply with his request. Not only were monthly meetings part of our in-scope process, we also documented that any variation from this was not in scope.

    • On another project, the client offered its Subject Matter Experts (SMEs) based on availability. Our project management process required that client staff, especially SMEs, were loaned to the project fulltime, and were co-located with our project team. Continuity on large, complex projects is paramount.

      We went one step further. We requested that the client offer up its brightest and best staff to the project for the duration. In that way the client would be guaranteed a much better result. We documented that part-time work on the project by key client team member was out of scope, and that removal or exchange of a key client team member required our approval as well.

I have many such examples. Documenting process-related exceptions such as these as not in scope seems to be overkill. But what is the harm if it cements these in the minds of client and project staff alike?

  • Document aspects of methodology that will not be utilized.

    This one is subtle, and I only mention it here because I witnessed it on a project on which I served on the PMO.

    The IT provider had clearly presented its System Development Lifecycle in its proposal to the client. The provider had proposed a waterfall methodology, and described the processes down to the activity level in its bid.

    Deep into project execution, the client requested a major change order because of a legislative mandate. As the IT provider developed the change order estimates, one of the client-side managers asked that they perform the entire change order using Agile processes to complete it timelier.

    The IT provider declined, and argued against Agile based on the people aspects of managing such a large change. First of all, the staff that were needed to complete the change order were intimately familiar with the functionality, the client and the project goals. They were the logical staff to implement the change. Secondly, none of the staff was an Agile practitioner. Imagine the chaos that would have occurred by introducing a completely new methodology in the midst of a large project delivery.

    This situation is rare enough that it would, in all likelihood, not prompt anyone to include it as a not-in-scope item. Someone would have to consciously include a statement to the effect that no deviations from the proposed development lifecycle methodology would be allowed. Nonetheless, thinking outside of the box for items such as this is worth consideration.

Documenting scope boundaries in all areas of an IT project is essential. However, considering whether every scope item has a corresponding not-in-scope item, and documenting it, is just as essential.


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.