When you are targeting a software deployment, as decribed in the previous blog, you are essentially defining an introduction of technology to support a change in operating behaviors, which in turn support reaching a goal or objective.? The question is, “Where do you start?”  What behaviors, what process do you change first, second, third?   And are there any ramifications to choosing one starting point over another?  There definitely are ramifications to where you choose to start in work behavior change as you deploy software, but first let’s define three options that will guide you in the process of what change to emphasize.? 3 Options for Starting Points in the Behavioral Change Coupled with Software Deployment Process

1. The Risk vs. Value- Add matrix model.  Using this model, you begin by essentially rating the universe of behavioral changes required across a matrix of low to high risk (difficulty to achieve) and low to high Value- Add, and then typically start on the low risk, high Value-Add behaviors.

2.   The Incremental, keep it simple model.  Using this model, you begin by starting where the user group’s skill levels currently are, and focus upon simple behavioral changes.  You build sequentially to complex outcomes, keeping new behavior adoption to a minimum of 3 new tasks and duration under 15-30 minutes.  Unlike the first model, in this one you are not searching for the biggest “bang for the buck”, but are looking to secure “easy wins” and develop user comfort and security in the process.

3.   The Tipping point model.  Essentially any system of behaviors has a homeostatis and supporting agents that resist change.  The most efficient way to approach the change of new behaviors is to identify the tipping point, e.g. that constellation of behaviors and beliefs that anchors the current system, and target that for change first.  The tipping point represents the biggest vulnerability in the supporting structure, and usually rewards the existing structure, but is typically guarded by some power base.  This is a high risk approach, but absolutely an essential starting point when introduction of the change is likely to be thwarted by existing staff.  Strategically, which is the best model to use?  I think that depends on the environment you are operating in, and any deployment can have mixed elements from all three. That being said, here’s some suggestions:

• If introducing software into an organization that functions very early in the systems maturity cycle, the Incremental model is often best to use.
• If introducing software into an environment that is requiring rapid change, the risk vs. value-add can be an excellent guide.
• If introducing software into a highly politically charged environment, where the software adoption may well be targeted or used as a pawn in power wars, you will likely be forced to adopt the Tipping Point model into your deployment strategy.

Bottom Line: Deploying software, is essentially a launch of a change process into the work arena in pursuit of business goals or objectives.  Knowing where to start the change process, focusing on what first, is critical to the early success of a software deployment.  The Risk vs Value-Add, the Incremental and the Tipping Point models provide three different options based upon the operating environment into which the software is being launched.

• Software Adoption; New Wine in Old Wine Bags and a Failure of Nerve
• Tipping Points in Project and Performance Management Improvement
• System Tipping Points and Adoption of Performance Management Software
• Software Adoption, meet Personal Preference for Managing Information
• ManagePro and MProLite Implementation Guidelines

There is a Correct Sequence for Software Roll-out or Deployment… Ignore at your own risk.

Sequence is important in lots of areas of life, and each time it tends to bring order and efficiency to potential chaos.  The Ready, Aim, Fire sequence is a familiar one, which if followed out of sequence, tends to produce misguided effort and induce more chaos, expense and frustration.  Any kid on a baseball diamond this summer can immediately tell if you should choose to run the bases out of sequence, and if near-by will either yell at you or think you’re weird if you do so. 

Just like baseball, there’s an important sequence to rolling out software, especially when it is software that will extend across multiple people and impact existing processes (Project management, performance management, balance scorecard and collaboration software are all good examples).  Here’s the correct sequence with examples, then let’s explore it briefly.

Software Rollout Sequence:

1.  Establish the Goal or targeted Outcome – specifically those goals or standards for which an organization is willing to hold people accountable to reach on a regular basis.

Example – We’re going to coordinate our work effort better and as a consequence reduce out project over-runs by 15% and improve the % of Due Dates we achieve by 35%, all while spending 50% less time in meetings). 

2. Identify what changes need to occur in behaviors to reach the targeted outcome, both the new behaviors required, and the old ones that have to be abandoned.  

Example – We’re going to manage all projects and tasks that effect multiple people from a central collaborative workspace with clear planning and assignments, and up-to-date information to enable us to achieve our coordination, budget and timeline goals.  We’re going to communcate project related information in a timeline specific and brief manner.  We’re going to use progress updates and todos or task requests, not email narratives when managing projects.  We are no longer going to use whatever we personally prefer as a project management tool  (ex. Note pads, email folders, spreadsheets, because yes we all have different preferences) when managing group projects, we are going to use one common tool, so as to sing off the same song book.  Finally, we are no longer going to substitute attending long meetings for regular write-ups of updates on projects. 

Hint:  You’ll have the most success if you think of the required behavior changes as rungs on a ladder, moving from simple (I can do myself) to complex (I can only do with inputs from other systems).  Make sure you have all the rungs on the ladder before you have people begin the climb.

3.  Roll-out and establish competency and comfort with the new technology – Apply the technology and training in its use to a succession of steps that need to take place to move users from current processes and practices to the new practices that will ensure target or goal outcome in such a way that users build competency and comfort.         

Example – The first step might simply mean adopting a common naming convention for projects, a common way of defining the structure and location of projects, how to navigate to the project and view what assignments are due for each user.  You would want to start the technology training at that behavior run, not at showing them how to compute estimated versus actual due dates and the relative extension of duration as a % of the entire duration.   

Hint:  Most people only climb ladders one step at a time, and in a similar fashion, most people learn new technology by building on one new skill at another, not by aborbing lots of new concepts, key strokes and capabilities at once. 

Bottom Line:  First of all, at the 30,000 foot level, there is a correct 1-2-3 step sequence to rolling out software.  In any role out, the new technology needs to support the change in behavior or process, not vice versa.  And the change in behavior or process, being clearly defined as needing to support goals for which the organization is willing to hold people accountable to reach on a regular basis.  The correct sequence again is:
1.  Establish the specific goal or target (addresses one or more pain points)
2.  Establish what new behaviors and practices have to be adopted, which ones have to be abandoned
3.  Then introduce the software technology to support the new process and ultimately the goal.You can imagine, and have probably lived through, software roll-outs that were conducted out of sequence.   They don’t do so well.  Obviously, starting with a search for the “right” software is not the first step, even though it’s one that’s commonly adopted, e.g. doing the sequence in reverse order has no positive benefits that we’ve been able to determine.  By-the-way, there is some benefit to strategizing about what you decide to target in the behavior and process change sequence.  I’ll address that in the next blog. 

Links:

First of Two Key Questions that Predict Success at Deploying Software

Software Adoption; New Wine in Old Wine Bags

Finding the Pain before you Implement a Software Solution

People adopt software for different, but not dissimilar reasons.  Geoffrey Moore, in his book Crossing the Chasm, suggests that there are 4 groups that represent the most common differences in motivation and behavior as applied to technology adoption.

1. Early adopters represent a small segment of any organization and they adopt the software if they like the technology, if it combines power with innovation.
2. A 2^nd larger group adopt based upon pragmatisn and power – adoption occurs if it represents a state of the art solution and other leading organizations are also using it… don’t want to get left out.
3.  A 3^rd large group adopts technology because it’s required to complete a function.  Adopting technology isn’t actually very accurate, because they are intent on completing a task, and the technology, is just part of the process, no more or less than the technology of creating round pencil leads is noteworthy for people who use pencils with lead replacements.  They adopt technology when it’s mostly invisible.
4. The final group doesn’t adopt technology, they fight it, get someone else to do it for them or just ignore the requirement to use it until confronted and/or forced to use it or leave.

Yes, people have different reasons for what drives the adoption process, but underneath it there’s a required fundamental shift from old to new, from familiar to unfamiliar that Moore doesn’t talk about.

No one adopts new technology effectively when or as long as they are attached to old processes or old technology if you will.  Jesus commented on the process in a famous parable in the Gospel of Luke, where he stated, “And no one pours new wine into old wineskins. If he does, the new wine will burst the skins (the older they are, the more rigid and inflexible they get), the wine will run out and the wineskins will be ruined. No, new wine must be poured into new wineskins”… he goes on to add “”And no one after drinking old wine wants the new, for he says, ‘The old is better’ “.

When faced with new technology, it is easier to justify staying with the familiar.  It’s comfortable even if it isn’t the best solution.  The longer you’re satisfied with what you’ve been using, the more likely you are to frame it as a better option than anything new coming down the pike.  Inflexibility seems to accompany a history of some successes.  You might even be willing to get in a fight over it.

Here’s the thing.  New software solutions, and I’m not talking about an upgrade to an existing tool, represent fundamantal shifts.  Users don’t make shifts forward while still hanging on to the past.  E.g. before someone can adopt a new software solution, they have to change their mind.  They have to make a decision to let go of the past solution to make room for the new one.  You have to open your hand to have a hand shake.

It’s easy to spot users who haven’t changed their mind before being enrolled in an adoption process.  They make the old cowboy statement, “You can lead a horse to water but you can’t make him drink” come to life.  They show up for training, but they don’t use what they learn.  They show up and are not engaged… and sometimes they don’t even show up.

There’s a leadership challenge that occurs at this type of adoption crisis that Friedman addresses in his book, A Failure of Nerve.  What do you do as a leader, with employees who haven’t changed their mind to allow them to adopt and successfully use new technology?  It’s a tipping point, a point of impasse.

It’s a big mistake to ignore the impasse.  To dance around it, to cover it up with more training… thinking maybe they’ll get it this time.  That doesn’t work.  On the other hand, if the staff resisting making the shift are important to the company, it can sure make the feet feel like dancing!

The lack of mind shift actually represents a fundamental break in engagement and alignment.  Something which many leaders, not just technology oriented ones, are discomforted in addressing.  But let’s write that up in the next blog, because it’s something that is very valuable to address. 

To summarize:  People approach software adoption in 1 of 4 patterns.  Underscoring all four patterns is the requirement of a change of mind, a shift from the old to the new.  If no shift takes place, predictably poor adoption success will occur.  Shifts are fundamentally tied to a deeper issue, alignment and engagement.  You want to address it all when you’re leading software adoption.

In the previous blog on tipping points, we covered the idea that when introducing any new system you reach an adoption tipping point.  That is, a point of question or controversy, that if navigated correctly looks like a clear cut-over from one system to another.  If there is not a clear cut-over from old system to new system, no tipping point is reached and in fact the adoption of the new software or system is compromised.  Navigating successfully requires replacing the old with the new.  There is no such thing as “peaceful co-existence.”

Let me summarize with some recurring observations:

·         The tipping point is predictable, it happens every time you’re introducing a new software system to replace an existing or legacy process,

·         Given the inherent conflict between new and old systems, there’s inevitable tension and affiliation controversy around the tipping point,

·         Many people in management are discomforted by the conflict and seek to avoid it (placate, not address, make allowances, go around the issue), and miss the tipping point, and ultimately securing the value of a successful adoption of a new system.

Having outlined that, let me move on to something that you need to know when introducing project (task) or performance management software.   You could say it this way, “There are tipping points and then there are tipping points.”  Yes you could have a tipping point over moving everyone in the organization from one phone system to another; or reports done in a wide array of formats, to one specific template in Excel.  I would consider those small tipping points.  They represent changes, but may not generate dramatic, much less measurable, improvement.  They probably represent processes you don’t measure currently anyway, e.g. if moving to a new phone system, it’s probably for improved convenience and new features, but there’s often not a pre and post measurement of dropped calls or some other metric that’s driving the change.

Let me put this more simply.  Any introduction of project or performance management system will have impact on two core business systems: specifically how email is managed and how meetings are conducted.  Those are major tipping points in every organization.  If in fact the introduction of those systems does not directly impact email and meetings as they touch those areas, you’ve missed the tipping point and have compromised the value of the new system.

Let me give you an example.  Let’s say you introduce a new project and task management system.  Everyone’s supposed to enter and update their tasks in the new software for improved organization and visibility… but

a) In meetings you don’t use this system for tracking tasks; it’s all done verbally, by memory and memorandum

 b) People still assign tasks through email correspondence, of which only a fraction get into your project and task management system.

Guess what happens to the value of the new system?  It’s reduced, it’s compromised… it’s not good.  Some information is in the new system, some is managed in the legacy systems.  The potential for details slipping through the cracks, duplication of effort, lack of coordinated work effort is all heightened.

Fundamentally, if you really intend to drive performance, you need to address the systems and tipping points that are core to two areas:

1. How you manage information around the processes that are key to generating business value and

2. How you manage information in the process of managing the business.

If you introduce new software to manage projects, tasks or performance, there will be a tipping point, or stated another way, there will be a conflict that is essential to win, in one or both of these two areas.  And you must win it (e.g. consistently enforce a cut-over) to win the battle of improved results. To your success in winning the battle.

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.

Understanding the interaction bewteen software adotion and personal habits can be a “game changer”. Software adoption relies, in part, upon structuring information in a manner that is consistent and can be leveraged within the software.Personal preference for managing information represents a very strong habit. For some, it does not translate into a style that meshes with a purchased software program, and results in a software adoption obstacle.In fact, most people operate at one of four styles or levels of personal organization as they manage information:
          Level 1 – Organizes by responding to next… by email, walking around, opportunity, next idea,
                         conversation… (what’s next?)
          Level 2 – Organizes by lists, by calendar schedule (what needs to be done today?)
          Level 3 – Organizes by projects and getting all the details covered (What are all the things
                          that need to be done?)
          Level 4 – Organizes by goals and outcomes, (where are we going and how do
                          we get there?)

User’s preferred organization style directly effects what they naturally put into a program like ManagePro (vs. how you might need them to use it). You want to be clear on this is launching software. Clear on what the software requires in terms of information managmeent, and clear on what your user base and organizational cultural habits currently dictate.What do you do if there’s a mis-match… if the introduction of software adoption and personal preference doesn’t go well?

In short, you lead the change effort to install new habits, not new personal organization preferences (those tend to remain fixed, like hand dominance… e.g. your dominant hand remains dominant, even if you learn to use your non-dominant hand), and using a combination of push and pull techniques, raise the bar. I’ll write about those details in another blog.

That phrase, “Do you, do you want to dance” rings in my head when looking at customers struggling with the transition from software purchase to software working for them in their business.  Bette Midler sang it, the Mamas and the Papas, sang it, so did the Beach Boys. 

It speaks to a dilemma.  To me, the dilemma is over whether or not to engage in the dance of transition.  I’m thinking of Bill Bridges’ work on Transitions and the 3 phases he identified:

1. Aspirations, excitement, hopefulness. 
2. Let down, its more work than planned, requires more discipline than is fun, not as easy as it look or not as easy for some as it is for others, other’s aren’t motivated to embrace the new solution.
3. Advancement, Integrating new behaviors into new patterns with dramatically different results.

As a software buyer, I get into a “do you want to dance” dilemma when facing the reality of needing to go through some time of transition.  That means going through the transition from the deciding and either demo or purchase process to the work and integration process. 

Purchasing software (really any new solution) doesn’t get me to step 3.  I sure wish it did.  Apparently so do a lot of other people.  I’ve got to go through step 2 first, the no gain without pain step.   

Purchasing and installing software has sort of a magical thinking component to it… the magical, hoped for, solution is that by buying it, there will be no or little work to putting it into play.  This gets voiced as the part realistic and part fantasy request for it to be “easy-to-use.”

At the end of the day, you’ve got to dance if you want to get the prize.

Click here to view Video Introduction

Some percentage of every group targeted to start using a new software package, don’t get it.  Don’t get why they should use it, and why it’s necessary to change to a new software tool.  If it impacts managing information, as do performance managment, project management and strategic planning tools do, they don’t see the value of letting go of their current methods and learning something new.  Ignoring this section of any group, and it can be the majority, is a big mistake. 

Paying attention to this group either thwarts the effort to implement a new tool or system (the tendency is to accommodate this group and appease them by not requiring total adoption of the new software), or requires a thoughtful and resourceful approach to work with them. My suggestion is a very simple one. 

For the group that doesn’t get it, you have to expose the pain, before you can make a case for the solution.  Let me say that another way, you have to make the pain of current practices bigger than the pain of having to learn a new tool.  The group will gravitate towards the option of less pain.

How do you expose, highlight, and make palpable the pain embodied in current practices, using current software or non-software tools?  Simply asking people about it doesn’t seem to work.  Lack of awareness, lack of safety to admit or disclose this type of information or simply denial and defensiveness all act to suppress a dialogue and release of information you can work with.

What I’ve found that works, is to ask very pointed questions, and if possible go in with your research already done, so you know the answers and the costs, before you start asking about the pain.   Here are four such questions to get at problems:

1. Do you have current, accurate information at your finger tips that:

a) Allows you to speedily do your job, or do you spend some part of each day looking/asking for that information from others – if so how much time/day on an average?
b) That allows you to track key metrics and status updates on your top priority projects, deliverables and dashboards? (Or have you just learned to cope with not having current information)  2) How much time/day do you spend in email, and what % of that time is spent looking at updates, because they aren’t found anywhere else, or being included on updates that wouldn’t be necessary if it was stored somewhere and you knew where to look?  What’s the cost of that time per day? 3) Do you have any current method of tracking the frequency and cost of information mistakes:

a) Missed deadlines?
b) Rework because of miscommunication?
c) Frustration to internal and external customers due to the lack of timely information, response?
d) What would you guess the cost of information mistakes is as based upon your total sales 5, 10, 20%? how about the % of your profit?

4) If you acted on the sudden urge to retire at the end of today:

a) Are the projects you’re working on clearly documented? Is there a plan, progress updates, issues and next steps clearly spelled out?
b) How much trouble would the people who work with you be in, because your work isn’t documented such that they could easily find stuff and keep delivering now that you’re retired?

Bottom Line:  You and the group adopting new software need to be very clear about problem the software is solving.  And to help them get over the inevitable additional work load of learning a new program, they need to have a clear idea of what the cost is of the current problem, e.g. current processes. Without that cost being surfaced and pinpointed, usually to the point of some discomfort, the launch of new software, as we have experienced many time in launching ManagePro, will very easily be dismissed by a large section of your new users as something that is not needed and just extra work.

Predict Success in Deploying Software with Two Key Questions (continues)

2. WHAT’S IT WORTH TO YOU?  This question and your response is the 2^nd key predictor of your success. Especially when deploying performance management software across your organization to deliver… well what, exactly, are you delivering?  

• will keep you on track,
• will help you avoid under-spending on resources to deploy the solution and
• will keep you out of the 2/3’s group that doesn’t succeed at deploying software.

          —————————————– 

The author of this series, Rodney Brim, is CEO of Performance Solutions Technology (PST).  PST develops and assists organizations in deploying performance management software solutions, and presents these guidelines based upon our work with 1,000’s of companies to help ensure your success in the pursuit of performance management.  Performance Solutions Technology is found on the web at http://www.PerformanceSolutionsTech.com

Two Key Predictors for your Success at Deploying Performance Management Software                                      

 There are lots of variables and issues to address when deploying a performance management system across a small or large business.  But I’ve found that there are two questions that are critical to your success, regardless of the size or nature of your business.  I’m writing this to not only expose those questions, but help you get very clear on your answers.  Ready to proceed? 

The truth is, utilizing performance technology, like ManagePro software, is a statement that you want/need/require things to change. If that’s the case, you might as well say it point blank.  Change and performance improvement is not something to dance around… or perhaps it might be better said that if change is a dance – you want to take the lead.

Continued to article ”Two Questions that are Key to Your Deployment Success (2 of 2)“