Project Managers, Focus on Outcomes — Not Deliverables

Organizations typically spend hundreds of hours defining scope for projects and initiatives. This is essential for determining resource allocation, budgets, and timelines. But “scope” is a dangerous word. It can be used to mean either specific deliverables or broader outcomes and teams usually default to zeroing in on the deliverables — checking them off generates a sense of fast progress. But this hyper focus on tactics versus end goals also creates an endless expansion of activities that disrupt both schedules and investments. I’ve seen this occur in almost every client engagement at my company, which designs strategies to help organizations differentiate across competitive landscapes. The executive leaders and their teams spend inordinate amounts of time and energy debating various project tactics, while consistently disregarding, undermining, or even failing to consider the larger outcomes they want to achieve. How can such a habitual problem be effectively addressed?

As a leader, you want to keep your team focused on critical outcomes and problems. To do this, you first need to identify where scope creep usually happens and cut it off quickly. In practice, this means shifting your entire team’s mindset from “what” you’re building to “why” you’re building it, ensuring a project’s outcomes are clearly defined. This will keep the team’s narrative focused on the problem being solved. In this article, I’ll share two key strategies for making this shift in your organization.

First, understand where scope creep occurs.

When we think of a project having “scope creep,” we may think of its requirements and features changing from what was originally set. However, this doesn’t occur because the scope of deliverables isn’t clearly defined. It occurs because there’s often little attention paid to defining outcomes — the unique and distinct customer problem being solved and associated measures of success. Without a clear understanding of outcomes, it’s natural that the scope of a project is much more likely to mutate and balloon on its own.

For example, say a team is tasked with designing and launching a new coffee maker product. While the basic functions of the coffee maker are obvious, the breadth of possible features are virtually limitless. Should it have an alarm? A stainless-steel body? A self-cleaning mode? These options are almost impossible to weigh and effectively debate without a clear understanding of the primary problem being solved.

A scope typically encompasses all the tangible deliverables produced from a project, such as documents, software, designs, or tests. It’s quite easy to define these deliverables — they typically have clear, fixed boundaries. For example, if creating a new coffee maker, the scope may include deliverables such as product specifications, material sourcing plans, and Underwriters Laboratories approval.

A project’s outcomes, on the other hand, are much more abstract and open to interpretation. For instance, with our coffee maker, the obvious end deliverable is the machine itself, but the ideal outcomes for the consumer are much harder to define. This is because the definition of “ideal” varies from person to person. These different perspectives will cause teams to continually debate on what features to include and the only stop to this cycle ends up being budgets or timelines. This is because a scope often fails to convey the “why” behind what’s being built or the intended result.

Focusing solely on deliverables can make product development seem like a feature factory, leaving the team disconnected from actual outcomes. Those teams will continue to doggedly deliver on the scope, even though the features may not be achieving the bigger goal. Here are a few key actions that you, as a leader, can take to ensure your team delivers on outcomes:

Strategy 1: Clearly define problem-based outcomes.

Driving projects by outcomes means defining success based on problem resolution, and measuring progress by how effectively you solve the problem. Therefore, an outcome is a problem that an audience has that isn’t addressed or is insufficiently addressed — not the individual project deliverables or features. Defining outcomes means setting aside assumptions on audience wants and desires, and shifting attention to what pain points exist and what is required to eliminate them.

For instance, instead of starting with scope deliverables such as “a stainless-steel body,” examine the audience’s primary problem they need to solve. If their main frustration is cleaning the device, stainless steel would be prone to water spots and only add to the problem. A problem-based outcome in this scenario could be framed as “eliminate the need for device cleaning.” This provides the space for a team to explore how that problem might be better solved. In this case, a solution could include a “self-cleaning mode” and an alternative material for the product housing that is more resistant to stains.

Emphasizing outcomes also helps you to align your team around a common purpose and shared goals. By providing clarity on what needs to be achieved, you’re motivating your team and empowering them to work together to apply creative approaches to problem solving. Without knowing the outcomes, it is presumptive to say whether any specific tactic or deliverable is needed or necessary. In short, only when problem-based outcomes are determined can a useful scope of features and deliverables be defined.

When defining outcomes, ensure they aren’t too broad or vague. If you define one outcome as “maximize product profit margins,” it is unclear what the actual profit margin target is. To address this, focus on creating outcomes with flexible boundaries. For example, a profit margin range would provide more room for creative interpretation.

Strategy 2: Shift the focus from delivering things to delivering outcomes.

As a leader, you’re held responsible for the work of your team and you’re incentivized to deliver results. As a result, you may find yourself diving down into the details, getting overly engaged with the scope of work, and sometimes even specifying individual deliverables. However, by doing this you are mistakenly falling into the trap of believing that delivering things means delivering outcomes.

You can circumvent this trap by steering your own focus back to the problem(s) being solved. This ensures the lion’s share of your time is spent with your team discussing and defining problem-based outcomes, and less on the minutiae. Just because a leader has a new idea, or the organization has the capability to create something doesn’t mean it addresses a specific need of a particular audience. And relying on the idea that “if you build it, they will come” is incredibly risky when competition is fierce, and customers are fickle and discerning.

Finally, to ensure your team stays focused, be sure to address outcomes that are incongruous with others. It may help to create a hierarchy for outcomes, to avoid what might appear to be conflicting priorities. For example, a team may struggle to know whether “maximize product profit margins” takes precedence or a back seat to “eliminating the need for device cleaning.” Therefore, select a single problem-based outcome to serve as the project guidepost, and establish an agreement with your team that it cannot be compromised in any way. The remaining outcomes should then be ranked by the team in order of importance for the target audience and the organization.

• • •

Focusing on problem-based outcomes instead of scoping individual deliverables ensures your team’s efforts are aligned with the genuine needs of your audience. It will also encourage your team to think beyond simply completing tasks, and to consider how their efforts create tangible value to the end consumer. When scope is defined in terms of desired solutions (outcomes) rather than specific tasks (deliverables), it ensures multiple paths to success.

Copyright 2024 Harvard Business School Publishing Corporation. Distributed by The New York Times Syndicate.

Explore AAPL Membership benefits.