Tell Me About The Process
I usually start with THAT – The Process – or turn the conversation to THAT when timely (politically/interpersonally).
Most of the time the complaint/request does not come to you in the form of a “my Process is broken” or “a whole bunch of my Processes are broken.”
It’s usually – for me – I need training.
For others it’s “I need (YOUR SPECIALTY HERE).”
Let the Analysis Begin!
Overtly or Covertly – but done nonetheless
Tell me about THAT – I inquire of my client when we first meet, of my Analysis Team when assembled and oriented to the task at hand within the context of the larger task, and/or of the Master Performers, SMEs and Stakeholders – at all points along the progression of the project.
For I wish to establish THAT as the Context for all other data gathering.
Let’s get The Process Stuff Out of the Way – ASAP
Not only do you want to know if there is one, you also wish to know…
- About Product Requirements of the various Stakeholders and any Variance
- About Process Requirements of the various Stakeholders and any Variance
- About ReWork and Scrap
- About Cycle Time and Touch Time
- About Costs
- About Upstream Processes – internal & external
- About Downstream Processes – internal & external
But sometimes one of the early things you discover – if not glossed over by you or whoever you are talking with – is that there isn’t “a” Process.
If my questionee says something to the effect of: “What day is it?” in response to my question about “What’s the Process?” – then I know to shift gears, and to confirm that there is indeed no one process that everyone subscribes to.
Next, to find out if there is one, that everyone is ignoring, each for their own good reasons – why?
Variance in all of their “good reasons” – to not use the proscribed Process – is my next check. Maybe they all have the same reason or reasons as to why they do not follow the Process – and do something else instead.
Ask Five Times – or not.
Note we are still on the Process.
We may find out that everyone is following it, THE Process – except there are still issues (problems/ opportunities), and so we would next go to “are there examples of people following THE Process?” and having success with meeting all of the Product metrics and all Process metrics?
Because – just because there is a Process, does not mean that it is truly designed to effectively and efficiently meet the Stakeholder Metrics for Products and Process(es). You need to prove that the Process is capable – and this is my quick look into that.
Because if the Process is capable – as proven by someone sometime – means that the cause is probably elsewhere – and is most likely in the Environmental Assets and/or in the Human Assets. So it is then time to finally look at them – THE ENABLERS – of THAT Process.
Here is a graphic of one of my own Processes – the EPPI Stage II Process – where there are multiple workstreams.
Because perhaps it ain’t the Process.
Perhaps the enablers of THAT Process are deficient.
Data Gathering Regarding the Requirements for Enablers of THAT Process
So I gather information and/or insights about Enabler requirements and actuals.
Here is a graphic – Ishikawa Style – of how I look at – frame – all of the enabler variables – as categories:
Suspend Your Disbelief
The Process – in my view here so play along with me – is a Paper Process only – that is actually brought to life by all of the enablers.
If it is designed to, and proven to, produce products that meet all of the various Stakeholder’s Requirements (including the Customer and the Customer’s-Customer’s-Customer’s Requirements from their Stakeholders…) – then it must be those Enablers – Human and Environmental (read: non-human) and the Systems (or Sub-Systems) internal and external to the Enterprise – that are providing The Right Stuff – to THE Process – or not.
Then if one of those upstream entities – provisioning the not-quite-right stuff – I can swim upstream and put that Organization, and its set of Processes – and their own Human and Environmental sets of assets to enable their own sets of Processes – under my macro/microscopes – to see where it’s broken.
Could be upstream from them too.
It’s a System and it takes a Systems View – to see what is really going on.
And to avoid the “Law of Unintended Consequences.”
Yeah, that too.
Focus on the Performance Competence Requirements – and Enable Them!
There are many models and frameworks used in the Pursuit of Performance.
This is how I go about Pursuing Performance – on the front-end. To target all of the rest of my and others’ activities to address the root causes.
# # #