<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

How To Replace Random Acts of Management With a Metamodel of Improvement

10-1The simple existence of a problem is not enough reason to invest in fixing it, perhaps not now, perhaps not ever. Organizations need a systemic approach to define what good looks like, assess current performance, and make evidence-based decisions about which performance gaps to close. The Tregear Circles replace random acts of management with a metamodel for continuous process improvement.

I have recently encountered several examples of the idea that higher process performance target scores are obviously better than lower ones, just because they are … well … higher; that setting a target of, say, 95% is, without doubt, better than a target of 88%, and in striving for improvement we should go 'as high as possible'.
I'm not convinced.

In various discussions in training courses and consulting projects, it has been clear that when setting process performance targets, the natural assumption is that setting a higher, more difficult target is a 'good thing'.

I remain in doubt.

Setting process improvement targets of 100% and 0%, i.e., perfection, have also been suggested because, of course, we want to be the best we possibly can be.

All doubt has vanished — this is just plain wrong.

Process performance improvement needs to be evidence-based and related to mindful changes in objective, measurable business benefits. It is not good enough to define performance improvement objectives only as general aspirations such as: "reduce revenue leakage", "reduce negative customer satisfaction impact", "remove excess time and cost", or even "reap rich dividends" — I've recently heard all of these. These are fine aspirations, but the performance effect must be quantified, else how do we know if we have succeeded? How do we know the performance gap was worth closing? We can reduce process execution time from five hours to four hours and fifty-five minutes, but that's probably not what anyone had in mind in seeking "reduce execution time".

Each process exists to deliver value of some form to direct and indirect customers. Depending on the level and position of the process in the process architecture, this might be the actual customer or some other internal or external stakeholder. If we want to know how well a process is performing, we must first understand what value it is meant to deliver, and to whom. Then we can assess the performance gap(s).

We might easily identify a problem — indeed, they often identify themselves or our customers point them out to us — but that must just be the start. Yes, that's right, you are well ahead of me — we must also identify the cause, the root cause, of the problem because we want to be dealing with causes, not just effects. In most methodologies, once we know the problem and its cause, we are on the home straight; all we need to do is remove the cause and that is the finishing post flashing by.

But, it's not as simple as that. Who said we need the fix the problem in the first place?

Life is full of problems, and we can't fix them all; we can't remove all the causes. What's missing in the 'problem and root cause' approach is knowing the impact of the problem. What pain will be experienced if the process is not changed; what will be gained if it is?

The simple existence of a problem is never enough reason to invest in fixing it, perhaps not now, perhaps not ever.

We need a measurable, objective way to define the problem, its root cause, AND the business impact of the problem. Given that we can't fix everything, we need to prioritize. Changing a process will have a cost, and we need to understand that cost in the context of the expected benefits of the change.

Elsewhere, I have written in detail about the Tregear Circles, a metamodel for continuous process improvement.

 

Treager Circles

The PO circle has three nodes: target, assess, respond. Target–assess–respond is the essential cycle of process-based management. Identify a process and set a performance target, assess actual performance, and respond if intervention is warranted, either to improve performance or change the target. This is the main game; all process management and process improvement come down to this.

At the target node of the PO circle we determine which 'critical few' measures would indicate that the process is working well enough for a consensus of key stakeholders. An important parallel requirement is ensuring an effective and sustainable measurement method, that is, a practical way of gathering the performance data.

The assessment node is quite deliberately not called 'Measure'; it is called 'Assess' because more is involved than just the measurement of performance data. Measured performance data will be important, and we also look for other opportunities for improvement — solutions looking for problems, as well as problems looking for solutions.

Without an appropriate response, assessment is waste. The purpose of assessment and measurement is to correct problems and, importantly, to find ways to avoid their reoccurrence.

Generally, there are three types of response.

  1. The process is performing within its target range: there are no changes to consider, and no response is required.
  2. There is a need to change the targets because there is a business case to either measure something new or set a different performance standard.
  3. An intervention is required, i.e., trigger the PI circle because there is something about the process performance that requires deeper analysis and consequent change.


We need this systemic approach for process improvement; not random acts of management, but evidence-based, prioritized, targeted interventions where the business case shows that most benefits can be gained now.

Is 95% better than 88%? I don't know, and neither do you until we know the business impact of (a) not making the change, and (b) making the change. Then we can make an informed decision about what, if any, investment to make in the change.

 

New Call-to-action

Roger Tregear
Roger Tregear
Roger is a Consulting Associate with Leonardo. He delivers consulting and education assignments around the world. This work has involved many industry sectors, diverse cultures, and organization types. Roger briefs executives, coach managers, and support project teams to develop process-based management. Several thousand people have attended Roger's training courses and seminars in many countries - and Roger frequently presents at international business conferences. Roger has been writing a column on BPTrends called Practical Process for over 10 years. This led to the 2013 book of the same name. In 2011, he co-authored Establishing the Office of Business Process Management. He contributed a chapter in The International Handbook on Business Process Management (2010, 2015). With Paul Harmon in 2016, Roger co-edited Questioning BPM?, a book discussing key BPM questions. Roger's own book, Reimagining Management, was published in 2016.

Related Posts

Data-driven insights can transform your business

All businesses have processes, from payroll to patient admissions. Often, the larger the organisation, the more unwieldy its processes can become.

Leonardo at 2019 Gartner Symposium ITXPO Gold Coast

Leonardo will be exhibiting at 2019 Gartner Symposium / ITXPO Gold Coast. We will be talking about how we drive end-to-end process improvement - from business architecture and modelling to process mining and automation, integration and platform- implemented for clients using an agile, scalable delivery model.

10 Common Problems in Container Adoption - And How to Fix It

The Compelling Origins of Containers A number of years ago, it become clear that the rise of container platforms was more than just a passing technology trend.  A genuine technology shift was taking place that would undoubtedly change the IT industry forever. Early indicators were everywhere.  Investment by the largest software industry giants was significant, as was their marketing positioning.  Pivotal and IBM were aggressive with Cloud Foundry and Blue Mix.  Red Hat was progressive with Openshift and receiving industry praise.  Docker Inc stormed onto the scene.  Then Google started the Kubernetes opensource project with immediate impact. Locally, there were also strong indicators.  MeetUp groups were started and quickly became well-attended - especially the Docker meetups based in Australia.  In the early days, the meetings were sold-out, and eager attendees weren't able to secure a spot.   After a humble start, the Kubernetes MeetUp was became very popular and continues to be so to this day. There was something brewing, and everyone wanted to be a part of it.