Do We Really Need Project Scope Management?
In the 2018 Pulse of the Profession report, the authors note (see page 7) that the number two driver of project success is project scope management. They also report a significant increase in scope creep over the past five years. The authors go on to discuss whether we need to develop a more tolerant approach to project scope management. The world is simply moving so fast that it is often prudent to make significant project changes during the project.
But how do we walk the line between managing scope and allowing enough flexibility for teams to capitalize on changing circumstances?
In a recent Forbes article, the author, Sunnie Giles, discussed VUCA — an acronym for volatility, uncertainty, complexity, and ambiguity. The concept may be getting some traction as the world seems to be growing more chaotic. Yet, we can look for more effective ways of dealing with all of those scenarios, instead of simply making excuses.
Nathan Bennett and G. James Lemoine offered their suggestions in a HBR post in 2014. For complex projects, the authors recommend restructuring projects/businesses and ensuring that resources are sufficient for the complexity. For volatility, the authors recommend stockpiling inventory or overbuying on talent, an admittedly expensive approach. To deal with ambiguity, the authors recommend that we experiment, and structure those efforts so we learn quickly. And for uncertainty, the authors recommend that we invest in information, and use it effectively.
While, on the surface, those seem like different recommendations for different scenarios, they come down to some basic project management principles that I’ve been discussing for years. We must remain agile — even in a world that may require us to invest in detailed project plans, and to pay attention to those plans, even as times change.
It starts with understanding your end goal. I’ve written much about how to start smart over the years. In this blog, I will outline an approach to project scope management.
Understand what kind of project you are doing.
Are you working on a generally predictable project? Or not? Most projects fall somewhere on a spectrum from somewhat predictable to completely unpredictable. We can call them predictive, iterative, incremental, and agile. OR not.
I don’t disagree that some projects need more structure than others, but I generally believe that changing times are impacting all of us, in many ways — and thus, even predictable projects are better managed with some agility. That said, I believe we can find that agility in the scheduling process without sacrificing project scope management.
Get scope clarity.
I wrote about how to find scope clarity last week here. As I’ve said many times, get clarity on what you are going to do, what you are not going to do, and why. Don’t worry so much about the how right now.
Use a work breakdown structure.
I’ve written before about how to create an activity breakdown, or work breakdown structure. The question is how much time to spend on this process. In a world of rapid change, spending too much time here just increases waste. Spending too little time makes it hard (perhaps impossible) to create any kind of reliable budget.
Creating a work breakdown structure of any value requires understanding what kind of project you’re working on. If you’re building a house, you should have way more clarity around your project deliverables than might be appropriate if you are building software. That’s okay.
Decompose the project to a point where the known deliverables can be accomplished in one to two sprints. I recommend that you break the project down so that teams can accomplish something valuable in each sprint. If all of your activities will take months to accomplish, there is nothing to celebrate in your meetings. And the client might begin to wonder what he/she is paying for that month.
Work in sprints to accomplish your scope.
I typically recommend two-week sprints, unless the project is deliberately proceeding very slowly, or needs to be fast-tracked. Two weeks is sufficient time to accomplish some level of meaningful work. Depending on your situation, you may choose to invite your client to these meetings. If not, I would encourage you to send some kind of client update at the end of the meeting.
I recommend sprints that are bookended by a Checkpoint Meeting, where you do seven things:
- Review your end game — the what and why.
- Celebrate your accomplishments during the recent sprint.
- Identify and document the lessons that were learned.
- Review what it’s costing the client.
- Solve any new problems or designate someone to do so.
- Identify and analyze the project risks.
- Plan the work for the next sprint.
When you plan the meeting agenda, you may consider whether any changes are warranted. Some believe that a new deliverable of equal or lesser cost can be substituted, provided it aligns with the business value that is desired on the project. I’m inclined to agree, but that’s your call.
Use a change management process.
I’ve written before on how to create a change management process.
Does this seem complicated? You can think of this like that trip planning exercise that I discussed last week. If your goal was to wind up in NYC for New Year’s Eve, and you get there on time at the price you were willing to pay, does it matter if you stopped in Pennsylvania or Ohio? Starting the project by understanding your scope is important. Continuing to focus on your scope inclusions and exclusions and your why throughout the project is important. While you may get to Chicago and decide to skip the next stop, you likely won’t lose sight of your New Year’s Eve celebration in NYC. Keep your eye on the ball!
Need some help? Give me a call or sign up for my newsletter.
