Not Invented Here – NIH

Those of us who have been working in the professional “change some aspect of the business space” of some enterprise, know that while the saying may be that “resistance is futile” – most of us know that most of the enterprise employees know different. They can and do resist. And they often succeed. And the failure rate of improvement efforts of many stripes suffers. Bringing us all a bad rep – a bad reputation.

Often deservedly so.  Too often. But I digress.

Or maybe not. Perhaps that trail to “we mostly deserve our bad reputation” isn’t a digression. Maybe that’s central to our failure rate in getting change accepted.

Maybe the resistance to change is not inappropriate. Maybe their resistance is appropriate. And our failure is deserved too.

Maybe the NIH Syndrome is valid – because they’ve learned because they’ve been burned – by change programs in their past, in their enterprise experiences – changes that turned out to be failures in either conception, execution and/or in the final results. Missing the impacts sought/ desired.

So they resist the obvious losers, the stupid-on-first–inspection change programs. There have been probably plenty that the longer-term employees have probably seen over their years. And the newbies – well, they will learn soon enough.

Informally. But assuredly.

And so they all resist, our targets of change, holding dear their original process or non-process, really multi-processes – and that would be a major digression to go there – because this “change is so stupid” can be true/valid for so many reasons. So, they just don’t accept and adopt the change. Not always; but often.

Boom: Failure.

Most of us have our tried and maybe true approaches to making our kind of change stick. Be it for new processes. Or learning/training content, or a new recruiting system and a new selection system. or a new IT solution, or a new set of metrics with rewards and recognition tied directly to them, etc. But we have our ways.

Those that are successful in getting things to stick, often realize that most often it requires acceptance by the many people directly affected by the change.

And then there are the others affected, less-directly but not always totally indirectly. They might need to be involved too.

It’s complex.

That list or lists of change arena participants and the “others affected” depends a lot on your mental model for what you are addressing in your approach or related approach to what I sometimes call Performance Improvement.

Other call it change. It could be Lean-Six Sigma. Or Learning. Whatever.

Primarily I am in the “get the key employees to a higher level of performance” business as a consultant, so that means I work with those corporate clients and many others also changing stuff.

So I have met that enemy, the NIH syndrome. And I think I have come to understand it better.

People are skeptical. And rightfully so as they have probably all been victims of promises not kept by the consultants who came before us; none-the-less we solider on, consulting away.

And nowadays, they/everyone wants it quick. Quicker than realistically possible most-of-the-time.

But that’s where we start.

Often.

I am generalizing here. OK?

So I like to engage the right people at the right time in a collaborative process. To get their voices. To reduce their skepticism. To get more of their skin in the game, get their ownership thing going, a partnership, etc., yada yada.

They gotta own it eventually, when I and other consultant types leave.

I/we have to facilitate them there. Guide them there. Lead them there. But let them make all of the decisions. And do that through a structured process that is collaborative and communicative in and of itself/themselves, and in a way that provides predictability in their time and burden – for the participants. So that their own ROI can be more reasonably estimated.

There are more than one solution-set in any major change effort.

Or more than just one process in which to make it happen, initially and/or over the long haul. Probably needing continuous improvement. Which IMO is adaptation.

The ability to adopt what makes sense and to adapt the rest.

Whittle “the peg” for each setting, each context a little bit differently. Whittling the pegs into something between a round peg and a square peg.

For it is never that simple – that binary choice: Round or Square please?

Adaptation – ‘Cause Blind Adoption Won’t Work

Best Practices are best practices in the original context. At the host enterprise.

What works there may not work exactly the same in your shop, your processes,  your enterprise.

How could it?

Your variables, including the upstream and downstream processes – for the targets of your change – would be different – and would need to be “accounted for” in the design of whatever change is intended.

You probably cannot, or should not, simply cut & paste.

How we structure our consultative engagements with our clients, be they internal clients or external as in my case, how we “buy them in” to owning the change and participate in the designing and implementing of the change – is critical IMO.

Critical.

The sooner we – all of the stakeholders – the direct stakeholders and the indirect stakeholders – come to consensus regarding the terminal goals, objectives, products, roles/responsibilities and schedule – the better.

Better, in more likely to succeed. IMO.

Semantics

True this:

I/We will always have variance in our success at communications due to semantics, the meaning of words and phrases that each individual brings to the two-way street of communications.

How much variance your context can tolerate varies too.

Language, communications, is critical, and often done so poorly. Inadvertently of course. But poorly none-the-less.

I learned a lot about this from Neil Rackham, back in 1981.

Communications

Communications. Is there such a thing? Do we ever really communicate? Or do we simply mis-communicate with greater or lesser amounts of error?

I know I’m playing with the semantics of it all, but as a colleague quotes a friend, “it’s not just semantics, it’s always semantics!”

The American Heritage Dictionary defines communications as: “The exchange of thoughts, messages, or information, as by speech, signals, writing, or behavior.”

Communication/communicating connotes that the message intended was the message received.

But how often does that happen with zero defects?

If we started with the premise that there is really no such thing as communications, that we never can achieve zero defects in our communications, we will then be on the road to better communications. Nirvanic communications.

In another post of an article that I originally wrote decades ago, I state in the title that…

You Can Never Really Communicate – You Can Only Mis-Communicate More or Less

Your and my communications can never be 100%.

Can never be six sigma.

In Their Own Words

I don’t use verb-noun patterns of my own choosing. I get the words on what to call everything from the people who use those words in their actual performance. I don’t “corporation” them.

Facilitation

I think, (IMO you know) I believe that Facilitation is most likely your second most leveragable skill-set requirement – as a consultant.

Besides your core (what you are selling/providing) skill-set, this is key in anything that requires change. You could be in the arenas of IT, Engineering, Learning, Lean-Six Sigma, New Product Development launch and ongoing Deployment. Your facilitation skill (or lack thereof) impacts the assessment, doing needs analysis, design, development of systems: processes, infrastructure and the capabilities and capacity of the environmental resources – and also the human capabilities and capacity.

And in your success at addressing HR practice changes – the arena of people.

You could be revamping other processes for legal and/or regulatory compliance and core processes – values chain super processes – for improvements in their effectiveness and efficiency…

And you’d be doing all of that via people.  Through people.

And although they are surely some sub-set of the performance equation, they aren’t it all. They are, at best, half. Doing stuff has a people set-of-requirements besides other-stuff-requirements.

My model for that…

Other models for this vary. Your model for that probably varies too.

Imagine that. :)

Create Your Own Models – by adopting things and adapting things.

Almost always.

As Always – It Depends

Your cookie-cutter solution may not retrofit into my context or contexts well enough. Not always.

But often enough it may be not your change but your approach that does not fit – and you should be figuring out how to make your approach, built in to your products or services, less cookie-cutter-like.

Of course you’d want to do so without throwing all good planning and cost and schedule predictability of your current approach out the window too. You do have that, don’t you? Throwing those aspects out almost always would not always appropriate. Rarely would it ever be.

Design your Best Practice Design & Deployment model to be quite adaptable.

Enable both adoption and adaptation in the way you design it – before you develop and test your prototype. Put it to the test, a pilot test, a full destructive test, an acid test. Prove it or fix it. Then deploy with confidence.

Because many times the Stuff Invented Here doesn’t work either, across the Enterprise landscape. The first time. Or sometimes, ever.

Balance the need for planning capability, financial forecasting and tracking capability, tracking actual to plan deliverables, schedule, capability, resourcing capability, project management capability, tools and other resources capability, knowledge and skills acquisition and/or development capability, etc., etc., etc. with adaptability.

Address the NIH Syndrome by enabling both adoption and adaptation in your final design, your testing, and your initial and on-going deployment stages.

Embrace the complexity.

Look at it as a complex system.

For it probably is.

# # #