Sometimes those who need to hear won’t hear. Sometimes they mistakenly believe that there is no problem, or that it will just go away.
Those instances are unfortunate. They are unfortunate in that all Stakeholders end up getting hurt over the long term. Get them to look and listen with both compelling data – and a plan.
I believe that when one finds a Performance or Quality Issue – a problem or opportunity – and a problem is always an opportunity and vice versa – one needs to look first at the Process itself, and then to the enabling systems that provide the non-people and the people things to that process.
What can be done? Deal with the Issue with data, not just opinions. And yes, opinion-based data is OK – not ideal – but better than no data at all. A Problem articulated with no data is just a monkey with no plan. Make sure that the opinion-data is not from an “N of 1.”
Bring your monkey (Problem/Opportunity) to management’s attention with data – and a plan – based on the data – to address the monkey business.
Is the Process designed to meet the Stakeholder requirements in the first place? I mean – actually engineered/architected to do so – time and again – dealing with variation from many sources including dust in the air, the spinning of the earth and the resultant gravity – and other situational variables? If not, start there.
What are those Stakeholder Requirements – and before that – who are all of the Stakeholders? Not just those close in. But all of them. What are their needs and constraints? Which are in agreement and which are in conflict? And for those that are in conflict – who is to win and who is to lose? And can those losses be minimized for the “losers” in any way?
Does the Process have a chance at meeting those requirements? If not – re-engineer it. Make it lean and reduce the variation enough – not every Process needs to be at Six Sigma – and some Processes need to be at Nine Sigma.
Assess the Enabling Systems That Provision to the Process
Do the Enterprise systems – organizations and their processes and enabling systems – provision/provide the Process with the right stuff, at the right time at the right quantity and quality? Or not. Fix that/them then. Using the same approach that you used on the targeted Process – like a series of Russian Dolls – or a chain of Dominoes ready to fall into each other (and not the Pizza Chain).
Approach Management with the Problem Clearly Defined and Data – and a Plan
If the Process needs to be re-engineered – show a plan with the how – and why.
Because of the ROI – and especially because of the R – the Returns in ROI – which are the Risks to be Avoided and the Rewards to be Achieved. And only if they are significant – and not low hanging fruit – so to speak. If those R’s are BIG enough – then chances are the I’s are smaller in comparison. And when calculating the ROI – use numbers from credible sources – from those willing to explain and attest to their “approximate accuracy” – appreciating all the way that they are either SWAGs or WAGs – and not 100% accurate from the git-go.
No one has perfect data when it comes to predictive ROI. And – ROI is used upfront – to compare opportunities to invest constrained resources – not to play gotcha later when the numbers turn out to be different. They will always be different!!!!
Determining the ROI after-the-fact is done for Lessons Learned, for Learning purposes, to sharpen the next attempts at establish a predictive ROI – and not for gotcha games!
Only go for significant ROI – where the Risks and/or Rewards warrant it.
Otherwise – just live with it.
Unless your Enterprise’s culture is to address all problems and fix them without regard to the R for the I.
And if that’s the case – you wouldn’t have read this post to this point anyway. Your management would have been on it – and begun to address it – before you could have scrolled down to this point in a quick scan.
This is all covered in one of my new 6 books: From Training To Performance Improvement Consulting – available both in paperback and Kindle versions – here:
# # #