How to guide delivery decisions with the constraints matrix
A couple of weeks ago, I shared my favorite decision making guide – the decision filter. That tool is particularly helpful when you’re trying to decide what to build, and how to build it.
It’s not so helpful when you’re deep in the throes of developing and delivering part of your solution and the crap starts hitting the fan. And let’s face it the crap tends to hit the fan a lot when you’re trying to develop and deliver software products.
Fortunately, despite all the disparagement that project management gets in the product management community, there are some helpful techniques for dealing when plans go awry. These tools are applicable even when you’re not starting with one of those ill conceived plans that project management rightfully gets a bad rap for.
One of my favorite of those tools is the constraints matrix, which is really a way to guide a conversation with key stakeholders about what’s most important to them. Have the conversation early when everyone likes each other, so when things get uncomfortable, you can make adjustments that people may not like in the moment, but they’ll agree to.
What the constraints matrix is
The constraints matrix is a quick way to show the relative importance of a set of constraints facing a product team.
Each row represents a general constraint faced by most teams. The most common set to use are: cost, time, and scope (ie the Iron Triangle).
The columns represent the amount of change that you can accept for each constraint when trying to deal with a change to your delivery plans.
-
Fixed: you don’t want to change the constraint unless you’ve exhausted all other options.
-
Flexible: you can change this constraint only after you’ve exhausted all the options that made changes in the constraints marked accept.
-
Accept: the first constraint you’re will to adjust to account for a change in your delivery plans.
Some additional rules for using the Constraints Matrix:
-
Each constraint can be in only one column Fixed, Flexible, or Accept.
-
There can be only one Fixed constraint
-
There can be only one Flexible constraint.
I first found out about the constraints matrix from Jim Highsmith’s. Agile Project Management: Creating Innovative Products (2nd Edition).(affiliate link) I’ve used it on several internal product efforts to set the ground work for later delivery decisions.
A note about key stakeholders
Throughout this article, you’ll see references to “key stakeholders”. I chose this term to account for a unique aspect of internal products. Namely, the ultimate decision maker for internal products are often not a product person, be it a product manager or product owner, but rather the leader in impacted business units.
When I worked in a project management model, I’d often see this role as a sponsor. In fact in previous posts I’ve written about the constraints matrix, I referred to the sponsor role.
When looking at things from an internal product setting, the ultimate decision maker can fill a lot of roles, so I decided to go with the generic term “key stakeholder.” That doesn’t feel perfect, but it seems like the least bad of all the alternatives.
If you have some perspectives on a better term for internal products, I’d love to hear your thoughts!
An example of using a constraints matrix
When I worked on the pricing app that I referenced repeatedly in my discussion about the product lifecycle for internal products, the key stakeholder was a director in finance who owned the pricing business process.
As we got started on the effort to rebuild the pricing app, I had a conversation with the director of finance to talk through the constraints matrix. I wanted to understand his view of the relative importance of the constraints early on so that if/when we ran into difficulties we’d know where we had room to maneuver.
We ended up with the following:
-
Scope [Flexible] – The new pricing app will enable setting prices for the current growing season
-
Time [Fixed] – The new pricing app goes online April 1, 2020
-
Cost [Accept] – The product team consisted primarily of contractors
It was good that we had that discussion because as we got into development work, we realized we weren’t going to get all of the functionality we originally identified to be ready at day one.
The launch date was fixed because the nature of the business process was such that trying to switch too long after the April 1st date would have cause havoc in setting prices.
We initially looked at expanding the team and then we remembered brooks law so decided that wasn’t a good idea.
Instead, we looked to what we could do with scope. Since we defined scope fairly broad and with an outcome in mind, we had some room to maneuver. Since there were aspects of the business process that started later in the growing season, we were able to delay releasing the corresponding functionality and still have a working solution on the target date.
And yes, we did the cutover on April Fool’s day. During a pandemic.
When to use the constraints matrix
Use the constraints matrix to guide conversations with key stakeholders at the start of an initiative to set an initial understanding of the relative importance of the constraints.
Provide the matrix to the entire product team to help them make decisions as they proceed through delivery and need to determine how to deal with changes in their delivery plans.
Revisit it frequently with your key stakeholders to confirm the current relative importance of constraints.
Why use the constraints matrix
It helps guide key stakeholders to decide which constraint is actually the most important, and prevents product teams from thinking they have to hold more than one constraint absolutely still when changes occur.
It also provides the team with guidance on the relative importance of constraints from the key stakeholder’s perspective.
How to use the constraints matrix
-
Explain the matrix to your key stakeholders including what the columns mean and the rules surrounding it’s use. Explain that you are using this matrix to help describe the relative importance of constraints.
-
Determine if the set of constraints is sufficient. If the list is not sufficient, make changes, but don’t add too many constraints because all but two of them will be marked as accept. You may find additional constraints don’t really add that much useful guidance.
-
Ask the key stakeholders what one constraint is fixed. Resist your key stakeholder’s attempts to call more than one constraint fixed.
-
Ask the key stakeholders what one constraint is flexible.
-
Mark the remaining constraints as accept.
-
Ask the key stakeholders to review the completed matrix and confirm that they agree with this layout. If they would like to make changes, go ahead and do that as long as only one constraint is fixed, and one constraint is flexible.
-
Share the finished matrix with the product team and explain how to use it when dealing with delivery issues.
-
When you discuss issues with key stakeholders and they try to hold more than one constraint constant, remind them of the matrix and ask them to revise their decisions accordingly.
Caveats and Considerations
Define time constraints in terms of externally imposed deadlines. In other words, time is a real constraint only when there is a compelling business reason for you to deliver something at a specific point. Your key stakeholder pulling a date out of the air and committing to it before confirm that with the team usually does not constitute a compelling business reason.
For internal products, define cost constraints in terms of the the capacity of the team needed to do the work. This will give you an additional mechanism to determine prioritization and accurately represents how cost is accounted for in most IT projects (availability of a certain team or teams for a certain time period.)
Define your scope in terms of an outcome. This provides your team with the flexibility to adjust their plans as they start working on the project, learn more about the problem, and figure out the best way to solve it.
Quality shouldn’t be a constraint. In earlier posts about the constraints matrix, I included quality as a constraint. However after repeated comments from my friend Joe McCloud that quality shouldn’t be considered a constraint and realizing that Jim Highsmith’s original version (affiliate link) didn’t include quality, I revised the matrix to remove it.
To be honest, I’m not sure how quality snuck it’s way on to the matrix. I think I may have put it on there to force a discussion around the reality that teams often end up sacrificing quality in order to fit into the other three constraints. I figured by having it explicitly as a choice more teams might actively discuss whether they want to consider it an option.
Joe’s right, it shouldn’t be considered an option, and it shouldn’t be negotiable. I’ve found a better way to address tight constraints is to always strive for high quality (through good engineering practices) and fit within the constraints through how you define and agree to scope, time, and cost.
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent
