The Often Overlooked Scope Item

Missed Scope Items Cause DistressDo you remember the last time you were in that glorious position of your project progressing well – managing to the timeline, staying within budget, enjoying a great client relationship?

And then, WHAM!!!

Out of nowhere you are blindsided by a scope item that no one considered. No one even imagined it, so it seems.

Several years ago, I was providing oversight consulting services to a large government agency. The new system we were building was a complex, mission-critical system that was required to exchange data with a sister agency’s system. In the preliminary scoping and high-level requirements sessions, we had gone beyond just the requirements gathering. We decided to capture known static technical design elements for the interface with the other agency’s systems while we had access to the documentation. We collected items such as record layouts, bi-directional data exchange requirements, and even job scheduling constraints.

Several months later, deep into the build phase of the project, the sister agency informed us that it too was modernizing its system – this same system for which we had built the critical data exchanges. We were already unit testing our code against the existing interface specifications. It was now necessary to recode the data exchange software to meet the other agency’s new system specifications.

The resulting change order was significant. The IT provider was held harmless. But the project suffered a significant delay.

What could we have done better? How did we miss such a huge scope item? We had spent weeks with the other agency’s subject matter experts; so why didn’t we learn about their new system at that time? Why didn’t we ask more and better questions?

In preparing the justification for the change order, we asked these questions. I’m not sure we ever got a good answer.

With the benefit of hindsight, I have since determined what we would do differently on my next project. Now as our teams define the scope and requirements in areas out of their direct control (such as the example with interfacing organization), they ask additional questions beyond the as-is functionality. They dig deeply into the other party’s plans for future maintenance and enhancements to determine if any anticipated changes to their systems or processes could affect our project scope. It’s not foolproof, as the other party might not even be aware of organizational or legislative mandates that might occur in the near future. However, it would certainly catch situations such as the one described.

Simply following process can and does fail us. But adding the people aspects of project management to our process helps us avoid situations such as this one. Scope definition is much tighter and less apt to change when we employ deep probing analysis, sound judgment, past learnings, and a curiosity that doesn’t always follow the “rules” of how we determine requirements and scope.

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


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