Adoption of Project Management Software
This blog is about the need to support software adoption by creating a system “tipping point”, to use a term Malcolm Gladwell made well known.
This approach accompanies our other emphasis on supporting software adoption by creating a business case that addresses the two questions of “Why?” and “What’s in this for me?”
Let’s understand first a series of brief assumptions about system tipping points:
- Every organization, and every person, has a set of systems for doing things.
- When you introduce new performance management and project management software, you are introducing a new system.
- New systems are intended to replace old systems for all current employees.
- Replacing old systems with new systems to improve performance, typically generates negative reactions along the way, based on the learning curve and general resistance to change.
- The point of tension between maintaining old systems that support key processes, versus adopting new ones, represents a tipping point.
- Creating a system tipping point is a much more effective software adoption strategy, than adding more training, browbeating, 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 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 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 need to do, to miss a tipping point is continue usage of 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 management software, navigating them successfully requires replacing the old with the new one.
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), miss the tipping point, and ultimately secure 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 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, 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.
Putting it in a simpler way, any introduction of project management software will have an 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
- In meetings, you don’t use this system for tracking tasks; it’s all done verbally, by memory, and by memorandum
- 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:
- How do you manage information around the processes that are key to generating business value and
- 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 winning, in one or both two areas.
And you must win it (e.g. consistently enforce a cut-over) to win the battle for improved results. To your success in winning the battle.
