Over the years, I’ve helped many teams find success by identifying and removing roadblocks.
One roadblock that seems to be appearing with greater frequency is “project prominence”— an emphasis on the project over the product or solution being delivered. Teams spend so much time and energy debating, controlling, managing and measuring the project process, that they lose sight of the product and the value the project is looking to deliver. The needs of the end-users and the goals of the organization become secondary.
The difference between project and product might seem subtle at first, but it becomes quite obvious in practice. The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” The product is the unique output of a project—the project builds the product. Many teams do not think of their solutions as a product, but the definition of product is quite broad including tangible items that can be sold in stores, as well as new software, bug fixes, process enhancements and really anything made to be used or sold (Merriam-Webster).
Related Article: Feature Thinking vs Value Thinking: What’s the Differernce and Who Cares Anyway?
In practice, teams that emphasize projects:
- focus on team operations
- measure project phases, % complete, documents, timelines, deadlines, budgets, bugs, resources, etc.
- debate how to optimize project operations
- make decisions based on the team’s needs
Whereas teams that emphasize products:
- focus on value
- measure value delivered, end user satisfaction, speed to value, and learning
- debate how to make a solution more valuable to the end users and the organization
- make decisions based on end user needs and/or strategic goals of the organization
One way to reduce the emphasis on projects is to help your team rethink the Iron Triangle (aka the triple constraints of project management). The standard iron triangle usually looks something like this:
This approach assumes quality is achieved by controlling/balancing schedule, cost, and scope. If any of the constraints spiral out of control, the quality of the solution will suffer. If scope gets too big, schedule and resources (cost) must increase or the project quality will suffer. If the schedule gets too tight, the scope needs to be reduced. If the project overruns its deadlines (schedule), the cost will go up. You can’t change one, without impacting the others.
But, what if we modify the Iron Triangle to this:
Is this really different? Is it just semantics? Aren’t quality and value really the same thing? They aren’t the same! Value adds a dimension to quality—emphasizing that the quality of the solution matters only to the extent the user and organization derive value from an increase or decrease in quality. Keeping value at the center shifts everyone’s thinking away from the traditional project management approach to a product approach. Cost, scope, and schedule are only as important as the impact they have on the value delivered. I’ve found that putting value at the center of discussions about schedule, cost, and scope helps teams in 3 ways:
Teams Stay Focused on the End User
When quality defines success, it becomes possible to deliver high-quality solutions (minimal defects, no missed deadlines, no cost overruns) that no one wants or needs. That’s why usability, usefulness and/or value need to be part of the discussion.
Product value provides a strong foundation for every project. Strong teams start each project by exploring context in terms of product value and keep questioning value throughout the project lifecycle.
Teams Make Better Decisions
The value perspective helps you make better decisions throughout the project lifecycle. Teams that make decisions based purely on cost, schedule, and scope, miss out on opportunities to maximize value. It might be ok if the project goes over schedule and over budget when the team discovers additional scope that dramatically boosts value. It might be ok to miss milestones or leave parts of the project incomplete if those components do not provide value, or provide minimum value compared to the required cost and resources.
Strong teams minimize project metrics focused on operations, and create useful data that gauges cost, schedule, and scope in terms of product value to the end user and the organization. When value is already embedded in the data, value becomes the driver of decision instead of process quality. Teams stop making decisions that benefit them and begin to develop empathy for the end-users.
Teams Become More Agile
Putting value at the center of all discussions and decisions is the easiest way to bring agility to your project. The focus on product over project helps teams adapt. They embrace changes with confidence because the “why” makes so much more sense when change is discussed in terms of the end goal (user satisfaction) rather than the process. It brings relevance and context to change.
High performing product teams have a shared understanding of value that makes the need to change obvious. Teams become more adaptable and efficient as they streamline processes to focus only on what needs to be done to deliver a high-value product.
So, how do you bring value into discussions about timeline, budget, resources, documents and deadlines? Frame questions with value:
- How do these metrics measure end user value?
- Why is this deadline important to the end user?
- How does this deadline maximize value?
- Is this deadline early enough to leverage the value the solution provides to the end user?
- How much are we willing to spend to provide this value?
- What do we need to learn to increase the value we can deliver?
- Are we spending more than the value the solution will apply?
- Do these project tasks/documents provide value to the end user?
- Do we have the right resources to deliver value to the end user?
- What is the smallest scope needed to provide value?
- Are there areas of scope that don’t provide value? Is this just enough to provide value and meet end user needs?
’m not saying that project operations, methodologies or frameworks are evil. Instead, I am encouraging you to take a look at your team and determine if you have a project prominence roadblock. Does your team emphasize project operations at the expense of product value? Your outcomes will improve dramatically if you let product value lead and smash through that project roadblock.