Visualize Your Constraints

As I work with people to use agile approaches, I see many organizational constraints.

Organizational constraints: Culture, Product/Portfolio, Project

I’ve been trying to find a visualization for what I see. I don’t know if I’ve got it yet, but here is my sum-of-the-parts image.

The organization’s culture drives decisions (or not!)  about the strategy.

Strategy, with any luck, creates clarity about which products when (the project portfolio). Those decisions (and the ability of a team to release) helps the organization acquire and retain customers, which leads to revenue. The more change in the market or what the customers want, the more often the senior leaders need to re-examine the strategy and purpose.

Inside the product/portfolio decisions, every project has constraints:

In projects, the organization often wants to constrain the project cost (funding). Too often, the organization constrains the people (who have both technical and non-technical expertise). And, the organization will define the approach, and too often, the tools the people can use.

Inside those constraints, the people can deliver features (the what), in some time (when), and with some defect levels (good).

Push a team to deliver more features too fast, and the defect levels will increase. Decrease the funding, don’t train or decrease the staff, and the team can only deliver what they can, when, and how good.

Project constraints live within the next set of constraints: how the people in the organization manage the strategy: defining the products and the project portfolio, so the organization can acquire/retain customers and receive revenue for their work:

  • The more the organization understands and clarifies its strategy product strategy, the more clear the project portfolio decisions are.
  • When the organization has clarity, we can expect some form of customer acquisition/retention.
  • That customer acquisition/retention, along with the product strategy allows us to predict and recognize some form of revenue.
  • Depending on the rate of change in your market and with your customers, you may have more or less predictability.

I’ve shown this as a bounding box because the projects live within these constraints. I’m not sure that’s the right image.

However, culture is really the organizational constraint:

When we understand what people can discuss, how people treat each other, and what the organization rewards, we can understand how the constraints interplay.

I’ve worked with organizations where the culture said, “We’re a happy family. We can discuss what a family discusses. We work here for the fun of it.”

That meant that we couldn’t discuss the irrationality of the project portfolio, the lack of product strategy, the fact that they rewarded people for heroics, and more. We were just like a family—a dysfunctional family.

If we realize that the organizational culture constrains how we manage the product strategy and the project portfolio, we can see the effects on customer acquisition/retention, and revenue. If we don’t understand how fast or slow our markets or customers want us to change, we can’t refine our strategy/purpose. I guess this should be a circle, but to me, it feels like a bounding box on all the projects.

I’m experimenting with these images. I would love feedback from you so I can improve them. If they make sense to you, or if they don’t, please do let me know.

I find that when I understand the organizational constraints, I’m more likely to be able to live within them—or challenge them successfully. Understanding your organizational constraints might be part of what could make your agile transformation succeed.

6 Replies to “Visualize Your Constraints”

  1. The inner triangle is the classic scope/schedule/quality, but the way you’ve attached it to the next triangle suggests connections that I don’t think are there. For instance, if I want to increase quality is that telling me something about approach or funding? Or if I change the approach, it looks like that would affect scope and quality but not schedule.

    In the outer triangle, is funding really at the same level as approach/tools and expertise? I think funding is a parent to both approach and expertise. You can trade payroll for tools, but increased funding can mean more of both. I’m picturing this in 3D, where funding is the base, on which rest expertise and tools, the combination of which yields an approach. On top of that approach is the scope/schedule/quality triangle.

    That way, if you’ve pulled on scope/schedule/quality as much as you can and you’re still not happy with the outcome, you need to change the approach. In order to do that, you likely have to boost expertise or tools, which requires funding.

    This feels like it’s contradicting the agile way of self-managed teams developing their own approach, but at the funding level you’re deciding who’s going to be on the teams. To do that you have to already have an idea of the approach you want. eg: Do you need a dedicated DBA or a developer who writes his own SQL?

    1. Drew, thanks so much for your comment. Hmm, maybe I didn’t explain this properly. The pyramid contains the organizational constraints on the outside which defines what the project could do on the inside. My experience—which might not match yours—is that if I do want to increase quality, I do need to think about the project approach or the funding. If I increase the funding, I might be able to play with other aspects of the project.

      My experience is that managers often decide who is on the team. Managers decide on the payroll. Too often, managers impose an approach on the team. I work with plenty of teams who say they still need to create Gantt charts, even though they use an agile approach. Or, the managers want a commitment to an entire quarter’s worth of work.

      Maybe you see something different?

  2. OK, you intend that to be a plan view of a pyramid, I wasn’t getting that.

    As for what I see differently, I think it’s more about there being two scenarios:

    1) We have budget for either new/better tools, or someone with experience using what we’ve got. Someone decides on the approach first, then acquires either the tools or the people.

    2) We don’t have budget for new tools or people. Management lets the teams develop their own approach.

    The funding authority always comes from management, so they keep the decisions of how it will be spent.

    1. Thanks for telling me the pyramid was not clear to you. I developed the pyramid a while ago, but I think I only started blogging it here: https://www.jrothman.com/mpd/project-management/2011/11/estimating-the-unknown-dates-or-budgets-part-1/

      Okay, I do agree that funding arises from management, except in the most autonomous organizations.

      I see more than two scenarios in my consulting. Sometimes, we need both people with experience and new tools. With any luck, the team decides on the approach as a team, but that doesn’t always occur.

      Please consider these scenarios: the project has a ton of change. The team decides to move from a waterfall/serial approach to an incremental approach or an agile approach. That will change the features they can release and when. That change in approach will change the defect levels, too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.