In Part One, I wrote about the kind of challenges we all face when trying to define the human, material, information and financial resources available to us. In small groups, we can estimate what is reasonable and possible simply by talking to people and seeing what they have on their plate. But as our projects get larger and more complex, if we can’t properly quantify our resources, we end up flying blind.

This is Part 2 of a series. Read the other parts here:

Part 1: On being resourceful: the problem

Part 2: A quantum leap in resourcefulness

[Listen to audio version, read by David Hodes]

How can we match the workload demanded by the schedule to the supply pool articulated by some system of capacity management? The Theory of Constraints (TOC), by its very name, is a theory about how we come to understand what stops us getting more of what we want. It points to how we can more productively use what we have—and know when and where to invest for a step-change in performance. 

In the first instance we need to quantify our capabilities in a way that a computer can store, enabling us to calculate load and capacity. Since TOC was invented by a physicist, let’s call each task a quantum of work, a quantum being the minimum amount we need to articulate in our schedule. Just as any electrician knows exactly what a volt is, so must we come to know the conceptual categories we need to consider to carry out each quantum of work. Thus, we have:

Capability: The ability to perform or achieve certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes or services. 

Resource: An asset capable of creating value through work, generally under the broad classification of human, material, financial and information.

Resource type: The classification of a resource using structured data as defined by the organisation’s taxonomy of resource types. 

Position: A role within an organisation that belongs to a node in its hierarchy that has, as a minimum, a manager, a start date, end date, capability and, often but not necessarily, associated cost and revenue.

Position assignment: The assigning of a resource to any given position with matching capability and the requisite authority, for no longer than the duration of the position. The assignment should either cost less than or deliver more revenue than the budget for that position.

Roster: The days and times a given individual, team or other resource will be available to do useful work.

Schedule: A sequence of tasks that includes, as a minimum, each task’s description, predecessor(s), successor(s), resource type(s), effort by resource type and duration.

Schedule assignment: The assigning of a resource, resources or a team to a task in a schedule.

 In the diagram below, many of these concepts come together:

So what does a quantum of work look like? In this example, the position is a role on a project which has a budget approved, with an expectation of a start and an end date. The burn rate multiplied by the duration of the position gives the total burn. Assignments are created when an assignee is recruited into a vacant position. In most cases, when someone joins a project, there is an induction period, before useful work can be done. This so-called useful work is articulated in blue and we call it the scheduled load. It is the load that comes from the systems and tools used for work management.

You can see that this example doesn’t ever quite reach the normal capacity of an eight-hour day, and it certainly doesn’t require any sprint capacity such as overtime or weekend work to satisfy the demand. Incidentally, running at sprint capacity the whole time is a recipe for burnout. What, then, is the optimum number when we look at load versus capacity, or put another way, demand versus supply?

“Running at sprint capacity the whole time is a recipe for burnout”

Before we can answer that question, we need to define how we will structure the data in order to define our resource taxonomy.

In the table below you’ll see an example of an engineering environment that defines the following: the domain; the discipline within that domain; a specific skill within that discipline; a speciality, if there is one; their level in the organisational hierarchy (front line, supervisor, manager and executive being the most common); and the organisation (or perhaps P&L) they belong to.

In many ways, this definition is no different from creating a code for an item of stock in a warehouse. Understand the code and you know what the item is, where it belongs, how many of them are in stock, what we need to do to get more of them, and so on. Defining capability in this way can be seen as defining a stock code for knowledge workers. There’s no reason, then, why it couldn’t equally be used to define a piece of equipment, such as a crane, or materials such as electrical cable.

Once we have this idea nailed, we can assign these codes to roles within a project or the organisation, as well as to tasks in a schedule. If the same coding is used to define the capability of any given individual—who will likely have more than one capability—then we have satisfied the necessary and sufficient conditions of being able to establish a match between demand from our scheduling system and supply from our system of capability management. The implications are enormous. We can know, reliably, what can be done, by when and for how much—at any level of the enterprise. Now you’ve done the difficult task of planning out the quanta of work and their sequence, you have a way of assigning resources to achieve your aims.

Back to the earlier question. Your information system should be designed in such a way that you can instantly report on all resource types where load versus capacity is greater than 80% over the next planning horizon. Why 80%? As a rule of thumb, if demand is greater than 80% of supply, you increase the risk of turbulence. Demand doesn’t come in a neat line at 80% of capacity—there will be peaks and troughs. Running at 80% of aggregate capacity allows for a degree of smoothing. Thus, if the load is shown as less than 80%, it means you have resource capacity available to do useful work. If not, you need to get more supply.

Once you have a good handle on the data, one way of tapping into existing capacity to solve the problem of resource bottlenecks is to query that data for anyone in the resource pool who has ever held a similar position, and establish where they are now. If they are still in the resource pool, establish their current assignment and test if their position can be backfilled. In other words, can someone else, a non-constraint, be assigned to the constraint’s existing role and thus free them to do only that which only they can do? (We call this the ‘double-only’ question.) After all, constraints are simply resources whose demand outstrips their supply. Finding ready supply within your existing resource pool is a fine way of maintaining the rate at which value is created.

If adding resources in the above manner is either not possible or not enough to close the capacity gap, you need to initiate your recruitment process. It’s worth noting that backfilling is a lot easier than one thinks. The principle about constraints applies here. Where there is a constraint, by definition, non-constraints have capacity available. The productivity magic happens when non-constraints collaborate to support a focus on getting the constraint’s priorities done at any given point in time.

“Constraints are simply resources whose demand outstrips their supply”

The flipside of looking for the bottleneck is to identify unconstrained positions—for argument’s sake, all resource types where load versus capacity is less than 50% over the planning horizon. List the names of all those people on the project whose assignment relates to the unconstrained positions. Ask if the unconstrained people have ever held a position or have a capability that could alleviate a current or future constrained position. If the answer is yes, then reassign that person to the constrained position. If no, the choice is either reskilling (training the person to do another job) or off-boarding (take the person off the project team).

A quantum of solace

Quantum work management probably sounds quite technical and thinking through the details is not everyone’s cup of tea. But this is a big issue within the domain of resource management and optimisation. You can’t avoid the criteria for each quantum of work outlined above; they are implicit in your system. But if you deliberately name and tag them in your resource database, and do it consistently, you’ll be ahead of the game.

There’s simply no substitute for the discipline of applying your standards for planning, scheduling and capabilities in a rigorous and proactive way. Applying TOC in this way is guaranteed to give you the quantum leap I promised in the title and sustainably deliver continuous improvement in business performance.

At all levels of work, your people will know what they have to do, and know that sufficient resource has been provided to get the work done on time and to quality. That goes a long way to fulfilling the criteria for ‘just work’ ensuring people are fairly treated while achieving the ambitious and worthy goals of the organisation.

This is Part 2 of a series. Read the other parts here:

Part 1: On being resourceful: the problem

Part 2: A quantum leap in resourcefulness

If you want to learn more about how TOC can help you focus where it really counts, why not schedule a video call.

____________________________

What’s next? The change from standard thinking to Theory of Constraints (TOC) is both profound and exhilarating. To make it both fun and memorable, we use a business simulation we call The Right Stuff Workshop. We’d love to run it with you. To learn more:

• download the brochure (no email required)
• schedule a call

____________________________

[Background photo: ‘The score’ by Dayne Topkin on Unsplash]

“Start where you are, use what
 you have, do what you can.” —Arthur Ashe