Why Planning Scope Management is Essential – A Case Study
The project was not going well – and we were only in the requirements gathering phase. Gut feel told the project team that there was serious scope creep, but for several reasons (don’t get me started) the team was not escalating the issues. My boss asked me to perform the quarterly QA (Quality Assurance) review for the project.
So many project issues. So little time.
Here’s a glimpse into just one seemingly small issue that I serendipitously uncovered during my QA review. The project team was so buried in the daily details of the project that they didn’t even recognize the issue. I saw it as symptomatic of a much larger problem, one that threatened the success of the entire project.
The project was in its fourth month of detailed requirements JADs (Joint Application Design sessions). Our team had done everything well – technically. Several JADs, each focused on a specific functional area, were being conducted in parallel. Each JAD was facilitated by one of our team leads and faithfully attended by client SMEs (Subject Matter Experts). JAD notes were taken and published quickly. Cross-JAD meetings were held to ensure that decisions made in one functional area would work seamlessly with requirements defined in another. All was running well according to best practices.
Except, as I discovered, the JADs were often attended by – more accurately, interrupted by and usurped by – the client’s Project Manager. My antennae went straight up. A Project Manager directly participating in low-level requirements JADs?
As part of my QA review I decided to attend one of the JADs which he was attending. I knew our team lead who was facilitating the JAD to be very competent. Was the client’s project manager there because he felt that our staff was not performing?
I introduced myself and took a seat at the table. As luck would have it, I was very familiar with the functional area being analyzed. The conversation went something like this:
Team lead: “Yes, I understand that we bid on the entire scope in the RFP. We’re just trying to understand this functional area. We’re not familiar with it and are wondering if it’s specific to your organization.”
Client PM: “No, and as I’ve told you before, this is federal regulation. And moreover, it’s in the contract.”
Lead: “Could you please explain the regulation? The one-line description in the RFP doesn’t provide much detail.”
Client PM (note, the client’s SMEs who are in attendance are not speaking at all): “It’s in the policy manual. You should have read that before you scheduled this JAD.”
Me (to myself): “Uh oh. First, a call back to the contract. Now, a reference to policy. This is not the spirit of collaboration that makes for good JAD process.”
Lead: “We read the policy manual, and we didn’t completely understand it. We’re conducting this JAD so that we can fully understand the requirements to be included in the system. Do you mind explaining the policy in lay terms?”
With a long sigh, the client’s project manager explained the intent of the policy in great deal. Again, his SMEs, who were in attendance because of their knowledge of the policy, remained silent.
Something stirred in the deep recesses of my mind.
Me: “Ah, that sounds like the “XYZ” legislation that the Reagan administration passed several years ago. It addresses very rare situations that could potentially slip through the cracks in current federal policy.”
Client PM (icy stare in my direction): “Yes, and your point?” He fully understood my point.
Me (undeterred): “How many such situations has your organization encountered in the last 10 years since the legislation was enacted?”
Client PM: “One.”
Me (sensing an opening): “One. Well, I know of one other nationwide – the one that initiated the legislation. I didn’t realize that your organization had also encountered one.”
Client PM: “Well, as it turns out, we really didn’t. Turns out it was a worker error which we have since corrected. So, no, we haven’t encountered any.”
Me: “I understand. In that case, let me recommend a solution for this particular requirement. There is a function in the system that is designed to handle very rare situations exactly like this one, and falls completely within the jurisdiction of policy specialists. Why doesn’t <Team Lead> describe that function to you and your team to ensure that it will meet this requirement?”
Client PM (not smiling): “As I’ve told you before, this is federal regulation. And moreover, it’s in the contract. We are going to sit here until we completely design the requirements for this function.”
Me (picking my jaw off the floor): “No, sir, we will not use precious resources, your or our, to design, build, and test functionality for a situation that may never happen. I’m asking my team to reschedule this JAD for another day. Now, may I meet with you in your office for a few minutes?”
You know my basic premise by now, that most projects fail because the people aspects of project management are often overlooked. The technical aspects of project management are mostly done well, because the basic premise of many organizations is that if the schedules, timelines, resource loading and reporting templates are in place, then all is well with the project.
Scope Management is Often a Process-Oriented Task
While it seems that the very real situation described above may be a failure of the team to handle the JAD process well, I assure you that the detailed technical aspects of the requirements process were in place. However, the team missed the people aspects, and it missed them early in the project, well before the requirements JADs. It missed them when the initial project management Plan was developed.
For large complex projects which this one was, I always include two subsidiary plans in the project management Plan: 1) a Scope Management Plan and 2) a Requirements Management Plan. The project team had not.
Note the terms, “scope management” and “requirements management.” The team was good at defining requirements. It was adequate at maintaining scope. But it was poor at managing both scope and requirements. In the absence of the Scope Management Plan and the Requirements Management Plan, the project team was at the mercy of this confrontational, self-appointed policy guardian, the client Project Manager.
But how is that? How is this a project management people aspects issue?
Think about it this way. Every project is comprised of as many personality types as there are family members at “My Big Fat <your nationality here> Wedding.” People are people, and they’re varied in their personalities, work ethic, views of the world, views of how things ought to be.
In this situation, the client Project Manager was a unique personality – anal to the core when interpreting the contract, zealous about getting everything that his organization was “entitled” to get, authoritative in his position as Project Manager, and overbearing in his grasp of functional and policy rules. At the same time, he was completely unskilled in his role as the client’s Project Manager, and should never have assigned that position.
Any seasoned project management professional reading this will understand that such circumstances are not atypical. We must learn to deal with these sorts of situations in managing projects.
Scope Management Must Consider the People Aspects of project management
So how could the Scope Management and Requirements Management Plans help?
First, let’s look at the process-oriented content of the Scope Management Plan, which include:
- a process for preparing a detailed project scope statement: this is an opportunity at the beginning of the project to anticipate that there will be issues with defining the project or product scope. Preparing a detailed project scope statement allows the team to put parameters around the prioritization of scope, to be flexible in adding or removing scope items as details are fleshed out in subsequent phases, and to define escalation procedures for handling ambiguous scope items. These process aspects of project management are invaluable when the inevitable people aspects of project management threaten to derail the scope definition process.
- a formal acceptance process for completed project deliverables: pertains to all project deliverables, and applies equally to the Scope Management Plan.
Had our team developed the Scope Management Plan as part of the initial project management Plan, it would have included a process for dealing with low priority items such as the one described. The client Project Manager would have had less latitude to derail the JAD process, knowing that he was part of the acceptance process for the Scope Management Plan, and knowing that he had agreed to a process for dealing with rare and low priority items.
Second, consider the process-oriented content of the Requirements Management Plan:
- a process for planning, tracking, and reporting requirements activities: this is another opportunity at the beginning of the project to anticipate what can happen during requirements activities. Seemingly minute details, such as the composition of JAD participants, should be described in detail. Does anyone believe that the presence of the client Project Manager in the JAD allowed for our team lead to provide an even exchange of ideas, or encouraged his SMEs to disagree with him? Early decisions of how requirements activities will be conducted, while appearing to be process-oriented in nature, are in fact anticipatory of human behavior that will inevitably occur.
- requirements prioritization process: not every high-level functional requirement has the same level of importance as every other requirement. Again, defining the prioritization of individual requirements, describing high-level processes for adding or removing requirements, and developing initial escalation procedures for ambiguous requirements, are all technical aspects of project management that can nip bad behavior in the bud before it negatively affects project progress.
- product metrics: by including product metrics and how they will be used, the project team can agree on parameters that will help define the full requirements scope for the end product. Had this been in place in a Requirements Management Plan, the client Project Manager would have had to let go of his single-minded insistence to build in functionality for a non-existent event, and much time and frustration would have been avoided.
Don’t miss this. Project Managers are very good at applying the technical aspects of project management; yet they often overlook why they are applying them. In the planning of project scope management, the big “why” (in my opinion) is to anticipate and deal with the people aspects of project management before they even occur. So often deliverables such as the Scope Management Plan and the Requirements Management Plan are ignored or given lip service only. What is not understood is the value that these up-front agreements have later in the project, when the going gets tough.
Maybe I’m jaundiced because I’ve seen so much bad behavior on projects – client and project teams alike. So use those process-oriented tools to your advantage in managing the people aspects of project management. There is never an excuse to let the people issues slide by.
Plan for the management of project scope, and plan early.
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.
52 Project Management Success Tips from Merv Jersak • Copyright ©2020. All rights reserved.