Regenerative braking - maybe change isn't always so hard

A few months back I had a piece over on Fistful of Talent called 'Range and Change Anxiety: Electric Cars are More Like Your Company Than You Think , that tried to make a connection between range anxiety, one of the primary psychological barriers that drivers have toward more widespread adoption of Electric Vehicles, (EVs), and change efforts that so often prove tremendously difficult in organizations. The take - that leaders and systems implementors need to take into account both real barriers to change, (cost, technical complexity), and perceived or even imaginary barriers (range anxiety, the fear that the driver will be stranded somewhere even though almost all trips are far too short to actually drain the EV battery).

The less than ground breaking conclusion - that change is really hard, and we make it harder by creating issues, problems, barriers, reasons to say no that sometimes exceed the often practical barriers that most projects also face. Seems kind of depressing, no? I mean if change efforts inside organizations are going to be stymied by any amount of imagined barriers then why bother? Focus on making small, incremental, and low-cost, low-risk changes to systems, processes, technologies and at least you'll have a reasonable chance for success. Then when it comes to have that annual performance review with the boss you'll at least be able to point to something tangible.

Well maybe not all is lost. As a kind of follow-up to the Electric Vehicle adoption story this week Fast Company ran a piece called 'It Turns Out Electric Vehicles Are So Fun To Drive, You Won't Want To Go Back', that reported on the results of a study that provided test EVs to 450 drivers in the United States. After becoming accustomed to the unique and different traits of EVs (like 'regenerative braking', the way some EVs can harness and re-purpose the heat energy from the vehicle's brakes), almost all the driver's had managed to put aside their resistance to EVs.  From the Fast Company article:

But by the end of the trial, the drivers, a mix of high-performance junkies, environmental enthusiasts, and technology pioneers, were hooked: 100% of the survey respondents agreed "electric vehicles are suitable for daily use," and two-thirds were more interested in buying an electric car. Only 9% said they were less interested. "Most households," even those with several other cars, reported the study, "preferred to drive the Mini E," admiring its clean, fun, and efficient attributes.

So once the drivers had the opportunity to actually use the EVs and see first hand how the new technology could not only be more cost and energy efficient, but also improve the driving experience, then at least according to this study, almost all of them were hooked.

Some simple takeaways for organiational leaders and change projects?

Don't discount people's imaginary barriers to change, but the best way to combat them might be to allow more full participation in early phases of change programs, whether it is in planning, early testing, or simply forming communication plans.  The best way for someone to truly believe that their fears are unfounded is to put them to the test, in a hands-on manner if possible.

And finally, if you are 'selling' your change based on some attribute or feature that your community does not care about, or is not directly applicable to making their live's better, the old what's in it for me gimmick, then you'd better hope as in the case of the EV tests, the community finds some other benefits you didn't even think were important.

I'll close wikth the last line from the study write-up:

"The general public thinks that electric cars are all golf carts: slow and boring," she said. "It's not until they drive one, they hear one, that they open their minds that these cars be fun to drive." 

 Substiute 'electric cars' for whatever change project you are stuggling with and see what happens.

Have a great weekend!

Optimistic Memory

This morning on a radio talk show I heard a phrase for the first time - 'Optimistic Memory'.  The person was (I think) referring to having a more favorable recollection of past events than perhaps was warranted, and failing to accurately recall said events with the proper scrutiny and measurement.

This is not unique, or particularly interesting I suppose, who hasn't fallen victim to having a kind of selective remembrance of prior events or circumstances, be they jobs, athletic 'achievements', or past romantic interests.  Heck, I even know a guy in the HR blogosphere that describes some of his past girlfriends as 'South Beach models'.  But I digress.

But the actual phrase, 'Optimistic Memory', sounded really distinctive, as I had never heard the dull old concept described in such a manner.  Consequently, minutes of diligent research ensued (one Google search), that led me to a National Institute for Computational Sciences (I never heard of them either), page containing the following definition for 'Optimistic Memory (allocation)':

Optimistic Memory Allocation means that Linux is willing to allocate more virtual memory than there is physical memory, based on the assumption that a program may not need to use all the memory it asks for.

So in layman's terms, the concept of Optimistic Memory in a Linux computer system has less to do with looking backward than with looking forward. It is a kind of design that attempts to release computing resources using an 'optimistic' assessment of the need for said resources.  It says - 'Ok process ABC, you are asking for X amount of resources, and I only have 50% of what you are asking for readily available, but I will go ahead and let the process start, because I am pretty sure you really don't need all the memory you are requesting. 

It is in a way the exact opposite of what systems folks are trained to do, and what often experience suggests when planning projects, estimating costs, and assessing risk. I am sure we have all heard the old standards of 'Take the initial estimate and double the time/resources/costs' mantra when in project scoping or solution design phases.  

But why is that the case?  Are we (the collective we, surely I don't mean you personally), really so bad at truly understanding new technology, estimating our own skills and capability to utilize new tools, or assessing the organization's capacity to adapt and change?  Are we simply tying to cover our own flanks by making the dire error of actually underestimating the level of effort to do anything? 

I don't know, but sometimes I think that our inability to see things positively, to actually employ some 'Optimistic Memory' in the face of change or innovation or new technologies is a handy anchor to keep us safely in port instead of actually venturing out to the open water. Better to keep the staus quo than try and fail perhaps.

Horrible post, I know.  But it did start out optimistically, and that has to count for something.

Planning versus Adoption

Recently, a Twitter conversation regarding the success or likelihood of success of so-called 'Enterprise 2.0' projects made me consider some of the fundamental differences between Enterprise 2.0 and more traditional corporate software project implementations, like ERP.

Traditional

The planning, testing, and prototyping steps are typically quite lengthy, frequently involving many months to even years, but once the 'go-live' date is reached, you have almost 100% adoption rates right away.

If you were to chart traditional ERP project timelines and user adoption levels it would look something like this:

Think of major system implementations for Core HRIS or Accounting. The 'adoption' of these systems is not 'optional' for the vast majority of end users, it is normally an 'all-or-nothing' proposition. The old systems are turned-off, and all users almost simultaneously 'adopt' the new system on Day 1.

Enterprise 2.0

Contrast that timeline to a typical Enterprise 2.0 deployment, where the software tools themselves are dramatically simpler, the time spent planning prior to deployment is usually significantly less, but achieving higher levels of user adoption can be much more difficult and take much longer.

These projects may be internal social networks, blogs, micro-sharing, wikis or idea markets, but commonly they are presented as 'alternatives' to traditional ways of communication and collaboration. Companies, at least initially, rarely 'force' adoption, rather they try to 'build' adoption through training, word of mouth, a visible internal champion, or small pilot programs.

Companies don't get rid of the e-mail or voice mail systems just because a new wiki is available.

Consequently, the length of time required to achieve full or the desired levels of user adoption could actually be longer for these on the surface 'simple' applications.  Of course 'time' is not the only important factor to consider in any kind of enterprise implementation, but it is certainly an important component.

These large E2.0 projects are probably not going to be any simpler, faster, and less problematic than traditional projects.  But, they will present a whole different set of problems for the organization, the kind of problems that many 'traditional' project managers and organizational leaders may not be prepared to address.

What two or three things can E2.0 project leaders do to try and mitigate these issues?