Managing the Top 2 constraints in an organisation.

If you ask most people what the constraint is in an organisation, they will tell you that it is the budget. You can tell this from the amount of energy that companies put into managing and controlling budgets and funding. Much of the upper management spend all of their time and effort controlling budgets.

However budget is not really the constraint. Try this thought experiment. Imagine you have infinite budget. Imagine you have all the funding that you require. Imagine that your company has been bought by an infinitely rich benefactor who says “money is no object”, and means it. What is the constraint now?

Queues form in front of constraints when demand exceeds capacity. This lack of capacity at constraints results in work items being delayed. Constraints reduce the queues in front of downstream processes, and those downstream processes potentially run out of work to do. These downstream processes hungry for work will generate work to keep them busy. The net result is that increasing budget results in more work in progress. Increasing budget does not necessarily increase output from the system… much to the frustration of those funding everything.

The first constraint is the capacity of each teams to satisfy demand.

It takes time to shift the capacity of an organisation. Small corrections in capacity involving the movement of staff or work and typically take a couple of months. Increasing the capacity of the organisation which involves hiring new staff can take a few months. Capacity is only increased when the person joining a team is competent. A new person occupying a role is initially a drain on capacity.

The second constraint is the capacity of individuals within the team.

The capacity of a team is a function of the constraints within the team. That is, the capacity of the team is limited by the capacity constraints of the individuals in the team. If the demand for a certain skill exceeds the capacity of the individuals in the team with that skill, then a queue will effectively form in front of the skill capacity and those working behind the constraint will be starved of work and take on lower value work. Even in cross functional feature teams, it takes time for a new member of the team to come up to speed.

Managing the Capacity of Teams in an Organisation

Tony Grout and I developed Demand Mapping at Skype with a large group of collaborators including Lisa Long, Ram Rao, Marina Oliveiro and John Horton. At the same time Dan was developing Delivery Mapping with his clients. This became apparent when Dan North bought me in to one of his clients to introduce it there.

Demand Mapping starts with the understanding that the constraint in organisation is the teams (or scare resource such as servers / server space) rather than the budget. The goal is to create a backlog that optimises the value that can be generated from the (currently) fixed capacity of teams. A secondary goal is to identify constrained teams with no capacity and teams with spare capacity.

Consider a team that consists of four cross function scrum teams that all maintain and develop “Component X”. For the next three months, that team would have twenty four team weeks of capacity ( Four teams times twelve weeks times 50%* ) to work on “Component X”.

We have five initiatives that require the capacity of the “Component X” team. We order the initiatives in terms of the value we expect** them to deliver:

• Initiative 1 requires 100% of the capacity
• Initiative 2 requires 50% of the capacity
• Initiative 3 requires 25% of the capacity
• Initiative 4 requires 100% of the capacity
• Initiative 5 requires 25% of the capacity

We can now choose between the scenarios of Initiative 1 only, Initiative 4 only or Initiatives 2, 3, and 5.

We repeat this for all of the teams, creating a portfolio that optimises the delivery of value.

We are left with the portfolio of initiatives for the organisation to deliver, and the capacity utilisation of each team. The teams deliver the first whilst management works to re-balance the second using the tornado map (See Todd Little’s risk presentations) to determine future demand on the teams.

Managing the capacity of individuals within the team.

Rohit Darji and I developed Staff Liquidity and the Skills Matrix a couple of years before I discovered Agile. Dan North took these tools and evolved them into the more elegant and useful Skills Mapping***. He extended the values that individuals self score themselves on to the following.

1. My current skill level.
2. The skill level other members of the team would say I have (Moral Hazard).
3. The skill level I want to have.

Ideally the team then self organises to remove key man dependencies and cross skill to remove constraints within the team. Unfortunately some organisational cultures mean that management need to intervene in order to ensure that skills transfer occurs.

To summarise, manage constraints caused by teams and within teams. Acknowledge that the budget is rarely the constraint. Thats why you need Demand Mapping and Skills Mapping in your tool kit.

My thanks to Joshua Arnold whose post “Resources are the constraint” inspired me to write this.. initially as a comment responding to his post.

* The maximum capacity a team should allow is 50% otherwise queues will naturally build up.

** Expect is probabilistic term. A summary of the range of value based on the probability of them reaching that value. Normally we use a “HIPPO” version of the expectation of value rather than use a formula such as Black Scholes to calculate the value of the option.

*** Check out Dan’s talk at YOW! for a fantastic introduction to Skills Mapping and the rest of Business Mapping… Demand Mapping and Initiative Mapping.