<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

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.

How to Swap Between Different PAMlets

The following set of instructions are for swapping between the different PIE PAMlet environments. NOTE: These instructions follow the use case of swapping between DEMO-PIE and DEV-PIE, but the scenario is similar if you intend to swap in the other direction. Step 1 - Execute the script and follow the prompts

  • 45 min read
  • Jul 31, 2019 9:22:00 AM

How to Demonstrate the Mortgage Process PAMlet

Scenario : A mortgage application is automatically qualified and becomes ready for final approval In this scenario we will: give you a high-level introduction to using Red Hat's Business Central to view the Mortgage process and to view a Decision Table in the process (see Demo Steps: Business Central) allow a customer to submit an application for a Mortgage using the applicant's UI developed in Entando (see Demo Steps: Applicant UI) allow the mortgage lender to view the status of a mortgage application and then claim the application and move it to Final Approval (see Demo Steps: Lender UI)

  • 12 min read
  • Jul 31, 2019 9:01:00 AM