A minority of us are theorists and are more comfortable with abstract models and solving rhetorical problems.
Many of these Improvement Science blog articles debate abstract concepts – because I am a strong iNtuitor by nature. Most realists are Sensors – so by popular request here is a “how-to-do” recipe for a Productivity Improvement Exercise (PIE)
Step 1 – Define Productivity.
There are many definitions we could choose because productivity means the results delivered divided by the resources used. We could use any of the three currencies – quality, time or money – but the easiest is money. And that is because it is easier to measure and we have well established department for doing it – Finance – the guardians of the money. There are two other departments who may need to be involved – Governance (the guardians of the safety) and Operations (the guardians of the delivery).
So the definition we will use is productivity = revenue generated divided cost incurred.
Step 2 – Draw a map of the process we want to make more productive.
This means creating a picture of the parts and their relationships to each other – in particular what the steps in the process are; who does what, where and when; what is done in parallel and what is done in sequence; what feeds into what and what depends on what. The output of this step is a diagram with boxes and arrows and annotations – called a process map. It tells us at a glance how complex our process is – the number of boxes and the number of arrows. The simpler the process the easier it is to demonstrate a productivity improvement quickly and unambiguously.
Step 3 – Decide the objective metrics that will tell us our productivity.
We have chosen a finanical measure of productivity so we need to measure revenue and cost over time – and our Finance department do that already so we do not need to do anything new. We just ask them for the data. It will probably come as a monthly report because that is how Finance processes are designed – the calendar month accounting cycle is not negotiable.
We will also need some internal process metrics (IPMs) that will link to the end of month productivity report values because we need to be observing our process more often than monthly. Weekly, daily or even task-by-task may be necessary – and our monthly finance reports will not meet that time-granularity requirement.
These internal process metrics will be time metrics.
Start with objective metrics and avoid the subjective ones at this stage. They are necessary but they come later.
Step 4 – Measure the process.
There are three essential measures we usually need for each step in the process: A measure of quality, a measure of time and a measure of cost. For the purposes of this example we will simplify by making three assumptions. Quality is 100% (no mistakes) and Predictability is 100% (no variation) and Necessity is 100% (no worthless steps). This means that we are considering a simplified and theoretical situation but we are novices and we need to start with the wood and not get lost in the trees.
The 100% Quality means that we do not need to worry about Governance for the purposes of this basic recipe.
The 100% Predictability means that we can use averages – so long as we are careful.
The 100% Necessity means that we must have all the steps in there or the process will not work.
The best way to measure the process is to observe it and record the events as they happen. There is no place for rhetoric here. Only reality is acceptable. And avoid computers getting in the way of the measurement. The place for computers is to assist the analysis – and only later may they be used to assist the maintenance – after the improvement has been achieved.
Many attempts at productivity improvement fail at this point – because there is a strong belief that the more computers we add the better. Experience shows the opposite is usually the case – adding computers adds complexity, cost and the opportunity for errors – so beware.
Step 5 – Identify the Constraint Step.
The meaning of the term constraint in this context is very specific – it means the step that controls the flow in the whole process. The critical word here is flow. We need to identify the current flow constraint.
A tap or valve on a pipe is a good example of a flow constraint – we adjust the tap to control the flow in the whole pipe. It makes no difference how long or fat the pipe is or where the tap is, begining, middle or end. (So long as the pipe is not too long or too narrow or the fluid too gloopy because if they are then the pipe will become the flow constraint and we do not want that).
The way to identify the constraint in the system is to look at the time measurements. The step that shows the same flow as the output is the constraint step. (And remember we are using the simplified example of no errors and no variation – in real life there is a bit more to identifying the constraint step).
Step 6 – Identify the ideal place for the Constraint Step.
This is the critical-to-success step in the PIE recipe. Get this wrong and it will not work.
This step requires two pieces of measurement data for each step – the time data and the cost data. So the Operational team and the Finance team will need to collaborate here. Tricky I know but if we want improved productivity then there is no alternative.
Lots of productivity improvement initiatives fall at the Sixth Fence – so beware. If our Finance and Operations departments are at war then we should not consider even starting the race. It will only make the bad situation even worse!
If they are able to maintain an adult and respectful face-to-face conversation then we can proceed.
The time measure for each step we need is called the cycle time – which is the time interval from starting one task to being ready to start the next one. Please note this is a precise definition and it should be used exactly as defined.
The money measure for each step we need is the fully absorbed cost of time of providing the resource. Your Finance department will understand that – they are Masters of FACTs!
The magic number we need to identify the Ideal Constraint is the product of the Cycle Time and the FACT – the step with the highest magic number should be the constraint step. It should control the flow in the whole process. (In reality there is a bit more to it than this but I am trying hard to stay out of the trees).
Step 7 – Design the capacity so that the Ideal Constraint is the Actual Constraint.
We are using a precise definition of the term capacity here – the amount of resource-time available – not just the number of resources available. Again this is a precise definition and should be used as defined.
The capacity design sequence means adding and removing capacity to and from steps so that the constraint moves to where we want it.
The sequence is:
7a) Set the capacity of the Ideal Constraint so it is capable of delivering the required activity and revenue.
7b) Increase the capacity of the all the other steps so that the Ideal Constraint actually controls the flow.
7c) Reduce the capacity of each step in turn, a click at a time until it becomes the constraint then back off one click.
Step 8 – Model your whole design to predict the expected productivity improvement.
This is critical because we are not interested in suck-it-and-see incremental improvement. We need to be able to decide if the expected benefit is worth the effort before we authorise and action any changes. And we will be asked for a business case. That necessity is not negotiable either.
Lots of productivity improvement projects try to dodge this particularly thorny fence behind a smoke screen of a plausible looking business case that is more fiction than fact. This happens when any of Steps 2 to 7 are omitted or done incorrectly. What we need here is a model and if we are not prepared to learn how to build one then we should not start. It may only need a simple model – but it will need one. Intuition is too unreliable.
A model is defined as a simplified representation of reality used for making predictions.
All models are approximations of reality. That is OK.
The art of modeling is to define the questions the model needs to be designed to answer (and the precision and accuracy needed) and then design, build and test the model so that it is just simple enough and no simpler. Adding unnecessary complexity is difficult, time consuming, error prone and expensive. Using a computer model when a simple pen-and-paper model would suffice is a good example of over-complicating the recipe!
Many productivity improvement projects that get this far still fall at this fence. There is a belief that modeling can only be done by Marvins with brains the size of planets. This is incorrect. There is also a belief that just using a spreadsheet or modelling software is all that is needed. This is incorrect too. Competent modelling requires tools and training – and experience because it is as much art as science.
Step 9 – Modify your system as per the tested design.
Once you have demonstrated how the proposed design will deliver a valuable increase in productivity then get on with it.
Not by imposing it as a fait accompli – but by sharing the story along with the rationale, real data, explanation and results. Ask for balanced, reasoned and respectful feedback. The question to ask is “Can you think of any reasons why this would not work?” Very often the reply is “It all looks OK in theory but I bet it won’t work in practice but I can’t explain why”. This is an emotional reaction which may have some basis in fact. It may also just be habitual skepticism/cynicism. Further debate is usually worthless – the only way to know for sure is by doing the experiment. As an experiment – as a small-scale and time-limited pilot. Set the date and do it. Waiting and debating will add no value. The proof of the pie is in the eating.
Step 10 – Measure and maintain your system productivity.
Keep measuring the same metrics that you need to calculate productivity and in addition monitor the old constraint step and the new constraint steps like a hawk – capturing their time metrics for every task – and tracking what you see against what the model predicted you should see.
The correct tool to use here is a system behaviour chart for each constraint metric. The before-the-change data is the baseline from which improvement is measured over time; and with a dot plotted for each task in real time and made visible to all the stakeholders. This is the voice of the process (VoP).
A review after three months with a retrospective financial analysis will not be enough. The feedback needs to be immediate. The voice of the process will dictate if and when to celebrate. (There is a bit more to this step too and the trees are clamoring for attention but we must stay out of the wood a bit longer).
And after the charts-on-the-wall have revealed the expected improvement has actually happened; and after the skeptics have deleted their ‘we told you so’ emails; and after the cynics have slunk off to sulk; and after the celebration party is over; and after the fame and glory has been snatched by the non-participants – after all of that expected change management stuff has happened …. there is a bit more work to do.
And that is to establish the new higher productivity design as business-as-usual which means tearing up all the old policies and writing new ones: New Policies that capture the New Reality. Bin the out-of-date rubbish.
This is an essential step because culture changes slowly. If this step is omitted then out-of-date beliefs, attitudes, habits and behaviours will start to diffuse back in, poison the pond, and undo all the good work. The New Policies are the reference – but they alone will not ensure the improvement is maintained. What is also needed is a PFL – a performance feedback loop.
And we have already demonstrated what that needs to be – the tactical system behaviour charts for the Intended Constraint step.
The finanical productivity metric is the strategic output and is reported monthly – as a system behaviour chart! Just comparing this month with last month is meaningless. The tactical SBCs for the constraint step must be maintained continuously by the people who own the constraint step – because they control the productivity of the whole process. They are the guardians of the productivity improvement and their SBCs are the Early Warning System (EWS).
If the tactical SBCs set off an alarm then investigate the root cause immediately – and address it. If they do not then leave it alone and do not meddle.
This is the simplified version of the recipe. The essential framework.
Reality is messier. More complicated. More fun!
Reality throws in lots of rusty spanners so we do also need to understand how to manage the complexity; the unnecessary steps; the errors; the meddlers; and the inevitable variation. It is possible (though not trivial) to design real systems to deliver much higher productivity by using the framework above and by mastering a number of other tools and techniques. And for that to succeed the Governance, Operations and Finance functions need to collaborate closely with the People and the Process – initially with guidance from an experienced and competent Improvement Scientist. But only initially. This is a learnable skill. And it takes practice to master – so start with easy ones and work up.
If any of these bits are missing or are dysfunctional the recipe will not work. So that is the first nettle the Executive must grasp. Get everyone who is necessary on the same bus going in the same direction – and show the cynics the exit. Skeptics are OK – they will counter-balance the Optimists. Cynics add no value and are a liability.
What you may have noticed is that 8 of the 10 steps happen before any change is made. 80% of the effort is in the design – only 20% is in the doing.
If we get the design wrong the the doing will be an ineffective and inefficient waste of effort, time and money.
The best complement to real Improvement PIE is a FISH course.