Project scope management is always a challenge. Here’s how I effectively manage scope without appearing rigid or inflexible and get the change requestor’s skin in the game.
When I set up a new project for success or stabilize a project in need of rescue, one of the first and most reliable techniques I apply is scope definition and management.
Has your project been active for two to three times as long as estimated and has not yet produced a result, despite the best efforts of your team? Unmanaged scope (or worse yet, undefined scope) is usually at the heart of the matter.
The key to project scope management is to define scope. Ideally, scope is defined when the project is approved. However, there is no such thing as a bad time to define project scope. Arriving in the middle of an active project with a missing scope statement? Make the time to define it right then and there.
Nothing keeps your scope definition from realizing its intended and full potential than not managing it. Make the time to simply define and ensure a shared understanding of the scope change management process: document the change completely, evaluate the impact and value of the change, then approve (or deny) the change before adjusting the plan and its related schedule, budget, and resources.
A factor that complicates the situation is your organization’s budgeting best practices. Are you managing a large project with a large budget? Chances are the ‘while you are in there’ mindset will reveal itself. For example, “As long as you are making changes to the accounting system, can you make just one more change while you are in there?” Are you working in an organization where some, but not all, projects are approved? Expect people to act like the only time to realize their change is to work it into your project.
“How long will it take to make this change?” your stakeholder inquires. In order to ensure everyone considers the implications of changing, I respond with a question: “Do you want to interrupt the team?” I am amazed at how many requests for change do not move beyond this dialogue. It is important to effectively screen change requests because merely asking for an estimate will immediately distract at least one team member from achieving the result of the project and keep them distracted while they determine an answer. This answer can take one to three days to develop if your organization writes all answers in stone, or if your project is cross-functional and complex. Development effort is not the only element of the change’s impact. We all know changes made late in the project require a loop back to an earlier project phase. Adding a feature to a user interface without developing the associated organizational capabilities for that feature can be disastrous.
When the change requestor eyes me with a look that says they have determined I am the only obstacle between them and the change they want, I Invite them to consider the bigger picture. Rarely is this exact moment the only moment to move a change forward. It is about when their change is implemented, not if it is implemented. Shift their perspective. Your project is not the only way to see their change come to life. Or the change may belong with your project’s objective and can wait for a more appropriate time in the project’s life. Even if that time is immediately after your project’s implementation has stabilized.
Defining a change’s priority vividly, can be an extremely effective way to ensure the most critical changes are addressed first, and to ensure not all changes are critical. “Critical” becomes “the organization’s hair is on fire,” and “High” becomes “the organization’s hair is close to a flame.” In my experience, this gives the change requestor pause when they think about convincing a change control board of the value and importance of their “critical” change.
Please do not get me wrong: I welcome changes. I adjust my approach significantly on projects delivering a customer interface, or when the stakeholder profile reveals, “they will know it when they see it.” When your project sponsor has a must-have schedule or budget target, changes are easier to welcome when they are informed, completely considered, and transparently pursued. As a result, your project can enjoy a significantly increased potential for success.
Jan Schiller, PMP, PSM1, FLMI, is a partner with Berkshire Consulting, LLC. She specializes in revealing the path from where an organization is to where they want to be. Over the past 30 years, Jan has been focused on linking strategy to results with project management in the financial services, investment, health, beverage, learning management and life sciences industries. She has helped her clients with the adoption of project management best practices; streamlining business processes; addressing regulations; achieving competitive advantage and much more. In addition to being quoted twice in PMNetwork Magazine, she’s also discussed how to develop a PMO Project’s scope statement on Phoenix Business RadioX (podcast). Jan writes about scope, portfolio management, methodologies, and PMO.