5 Steps to Managing Project Scope

During a particularly tumultuous two-year period in my career, I was dispatched by my organization to troubleshoot three separate projects that were in trouble. Each time I was sent in with the expectation that I would quickly assess the situation, replace some team members, institute new processes, improve communication, and implement reporting and tracking.

All of this sounds like a lot more fun that it really was. I realize that some people make a career as turnaround specialists (thanks, but no thanks). As satisfying as it is to be involved in righting the ship, it requires more time and emotional energy than I want to dedicate for a sustained period of time.

Still, I learned important project management lessons during this time that have stayed with me. Most prominently, I saw that most problems occurring late in a project’s schedule were actually apparent very early on. To that point, one common thread in all of these projects was that they rushed through the scoping process early on, and paid the price downstream.

Based on the important lessons from my experience, here are five steps to managing project scope:

1. Understand the problem

I once had a boss who asked me never to bring him a problem for which I did not already have a solution. This sounds good at first, but I have come to view that as a dangerous approach. The reason is that people are uncomfortable talking about problems or pain. Instead, they like to talk about solutions. The complication is introduced by the fact that many (if not most) analysts jump in to design solutions before the underlying problems are truly understood.

In his book “Let’s Get Real or Let’s Not Play,” Mahan Khalsa makes a strong point by saying: “Unless the problem is fully understood, it will never be solved except by blind luck.”

In each of the projects I was trying to turn around, we had to go back and spend time defining precisely which problem we were attempting to solve. The stakeholders rightfully asked, “Why are we just now getting around to this?” and, “Haven’t we already done this?” We had not, and the project was paying the price.

When you document a problem or a business opportunity, it should be described in terms of the current condition (pre-solution), and its impact on the business. A brief problem statement should accompany each identified need, addressing:

• What the result or outcome should be.

• What obstacles are preventing this?

• How the desired results or outcomes will be measured.

You want to trace problems back to their root cause whenever possible. To do this, I regularly employ the “5 Whys” technique developed by Sakichi Toyoda (bonus points if you can pull this off without being completely annoying).

2. Slow down and dedicate time up front

Note: Agile has its own unique approach to scope and requirements, so this particular lesson would look different on a truly Agile project.

I maintain that traditional projects should allocate between 8% – 16% of their total schedule to understanding the scope. I believe that getting key stakeholders involved at the same time (whether collocated or virtually) is essential to working through competing interests.

But this is not easy! In his book, Code Complete, author Steve McConnell describes the WIMP principle he observed at Microsoft. Whenever managers would see coders in a meeting, they would inevitably ask “Why Isn’t Mark/Mary Programming (WIMP)?”

It’s a natural reaction. People hire developers to develop and engineers to engineer solutions. This means that the project manager might have to sell the idea of blocking off time to a scoping phase when it involves dev resources.

While analysis paralysis can get you into trouble, I have never heard anyone complain that they understood the project scope too well.

3. Start small

Many organizations now embrace delivering a minimal viable product (MVP). I advocate this approach whenever I can. It’s always a good practice to look at how you can get a useful product into the hands of users as quickly as possible.

This strategy will not work well for all projects, but it works very well for many IT projects.

The key to successful MVP is to plot the value of a feature against the risk of successful implementation. Both of these points assume the effort has already been estimated. The items near the top of the curve are the ones you generally want.

4. Embrace conflict around the scope

Some people (you know who you are) will do almost anything to avoid conflict. But on a project, the right amount of conflict can actually be a very good thing. Conflict is often the crucible where scope is refined.

Conflict will often happen when you bring stakeholders together in the same room who have differing points of pain surrounding the problem, or different hopes or desires around the opportunity. The good news is that consensus is often cultivated in that same environment. When a project manager or business analyst encounters conflicting perspectives in the same room, job number one is to listen to and facilitate open, direct and honest communication, and to gently guide the group toward consensus.

Some time ago I was helping to define the scope of a system for a pharmaceutical company. One employee dug in on each and every point and would not budge. To help counter this, we used the Borda method to gather votes for several competing solutions. The results were pretty magical. The contrarian ranked his preferences. Once he saw that his first choice was everyone else’s distant third choice, he threw his support behind the group’s decision—and picked his battles from there. It took time and patience, but eventually, he became a valuable supporter of the project.

Voting methods can help quantify how much someone actually cares about a particular feature. Sometimes people don’t really know how much something matters to them until they see the results.

5. Think like a customer

There is an important principle in the zeitgeist of project management: The customer is the most important stakeholder. It doesn’t mean that the customer is always right. It just means that the customer’s opinion weighs at least a bit more than anyone else’s.

It’s very easy for project teams to develop a type of tunnel vision around their project and only advocate for their interests; however, the customer needs to have a loud voice. It’s best if the team embraces that early on while keeping the focus on project success.

The project manager has more stakeholders to satisfy than just the customer, including the sponsor, the performing organization and the teams doing the work. However, the customer should always be well-represented throughout the project.

Summary

Problems can (and do) develop at any point in the project’s lifecycle, but identifying them earlier is universally better. Investing in a solid understanding of the scope of the project and gaining consensus with the key stakeholders will generally pay great dividends later on.