Zopim Chat

Rodney Brim Report

The Rodney Brim Blog

System Tipping Points and Adoption of Performance Management Software

January 14, 2008

This blog is about the need to support software adoption by creating a system “tipping point”, to use a term Malcom Gladwell made well known.   This approach accompanies our other emphasis upon supporting software adoption by creating a business case that addresses the two questions of “Why?” and “What’s in this for me?”

System Tipping Point.  Let me see if I can communicate this first in a series of brief assumptions:

1.  Every organization, every person, has a set of systems for doing things.
2.  When you introduce new performance management and project management software, you are introducing a new system.
3.  New systems are intended to supplant old systems for all current employees.
4.  Supplanting old systems with new systems to improve performance, typically generates negative reactions along the way, based upon the learning curve and general resistance to change.
5.  The point of tension between maintaining old systems that support key processes, versus adopting new ones, represents a tipping point.
6.  Creating a system tipping point is a much more effective software adoption strategy, than adding more training, brow beating or whatever.

So what do I mean by a system tipping point?  Here’s my definition, well actually here’s my definition of the point you want to tip first.  Every organization has a handful of key process-system combinations or marriages.  Getting paid is one example.   Getting paid is an important process in every business and it’s married to some type of system.  It can be as informal as turning in your hours on a piece of paper, or a complex task of entering and assigning hours to tasks and/or customer accounts.  The combination of a key process and a supporting system represents a point, and an opportunity for a tipping point.

If you stop accepting input from the legacy system, let’s say turning in a time card, and only accept input from a new system, you create a tipping point that drives the adoption of the new system… after all they may mutter and complain about the new system, but the process is so important, the adoption has to go forward.  You’ve passed a tipping point.

Do you know what it looks like to “miss” a tipping point?  Let me point this out very deliberately, because I’m thinking that missing tipping points when introducing software is more common than passing them. 

All you have to do to miss a tipping point is to continue to use the legacy system that’s married to a key process, while telling users to use a new system you’re introducing.  That’s it!  Pretty simple and very understandable.  In our example above you would still accept hours from some of your people on hand-written time cards, because:

  • They didn’t use the new time card system,

  • We’re too busy to learn it,

  • They’re too important to you to have a confrontation, plus

  • You want them to stay focused on what makes money, etc.   

The list could go on for a long time, but the bottom line is this – If you miss the tipping point (for any number of understandable reasons), the system or software adoption is severely compromised. 

Now we’ve found that there are two critical tipping points to address when introducing new project and performance management software… but that’s for another blog this week.  Stay tuned.

1 Comment. Leave new

julian mendoza
January 15, 2008 10:39 am

That’s a great list in the article worth keeping.

And the article is dead on; but “supplant” may be a mild word – a system-level change is by defnition a major change and therefore guaranteed to run into some resistance. Think of inserting an object into a box: it will have to displace or pierce other objects in the box.

It’s inevitable, and so, it must be anticipated AND surfaced.

Along the same spirit, unfortunately, “what’s in it for me” or “all politics are local” may not work if they are mere sweeteners or prizes as if this is a game. Besides, do you really want to imply this is optional because we are having to offer free snacks or lunches to attend the training – or prizes to comply with what is to be the chief leader’s preferred communication system?

Policy or system level change compliance must be tied, too, to consequences, not just prizes – i.e., the timecard example.

Second: Right from the onset, the chief must ask herself if she can enforce compliance not just from the nonperforming individuals that’s irritating her – that’s pretty easy to see. The toughie question is her star performers – what’s the consequences to them if they play diva? Or do you exempt them from the tool?

Third: Another parallel tipping point might be one’s own use of the tool – people are keen to sense if the boss himself is effective and diligent with the tool – think of how canny even small kids are to spot Dad’s inconsistencies.

Indeed we need to identify the tipping points in the change/adoption process – where the fulcrum points are – for success, or for failure.


Leave a Reply

Your email address will not be published. Required fields are marked *