Don’t Underestimate the Scope of Scope in Project Management

The former element is the product, while the latter is the work required to achieve that. And both – in my opinion – constitute the project’s scope.

Scope management is the heart of project management and, when teaching people about it, I stress it includes both the “what” and the “how” in delivering a product.

There are few cases of projects that are either time or cost driven, but most are scope driven. By focusing on scope all other considerations should flow from it, including budget and schedule.

Despite its importance, I think scope has been underrepresented in discussion about project management compared to – for example – risk, stakeholder engagement and governance. Often, this is because scope is aligned to a specific project or industry (scope in construction projects is much different to software development or organizational change) and there is a reluctance to address it at a general level.

The value of defining scope in projects

Once you define scope – including the product and the work – you can essentially derive all the other aspects.

For example, a product may be a building. Then, the work to deliver this product includes site preparation, excavation, foundation, utilities, finishing and handover.

Figuring out what work must be done is important for the sequencing and scheduling of activity, as well as working out the duration. In many projects today, the labour costs are often the greatest part, so considering the work as well as the product helps you to understand the costs.

When creating a brand-new product, it’s necessary to structure the work to account for not knowing what the final product will look like until the end. Agile, iterative methods have offered a response to this.

Ultimately, the biggest risk within projects is underestimating the scope of scope and getting involved in debates about whether it should be either more product or work-focused when it should consider both.

Take the example of roadworks: the focus of a local community is likely to be more on the work itself (the inconvenience and disruption it brings) rather than the end product: the benefits of a better road. And this affects the way managers need to manage the project.

How can project managers improve their performance with scope?

As we began, project managers should think of projects as a journey: realize that it’s not all about the destination abut also how you get there, facing obstacles along the way such as the risks and challenges the project will face.

While there are arguments in favour of focusing solely on product to eliminate useless work, in the context of a journey every step matters. Understanding the work scope as well as product also highlights stakeholders who will be affected through the lifecycle and may not be invested in the product.

And what about a project’s product owner who has a singular focus on the product? This can create resistance to work such as mock-ups, prototypes and blueprints. However, it’s worth explaining that the reason we do blueprints is to plan more accurately and reliably. Often, interim products are there to reduce the overall risk to the project, calculate more precise costs and create an accurate schedule.

Even gathering requirements for the product is one of the first management products. It’s not bureaucracy but rather a way to identify other issues that may arise along the way.

Today, project managers should acknowledge that both product and work are legitimate elements when describing the project’s scope – but this remains a work in progress.