How to Successfully Deploy Productivity Software Across Teams

Part 1 of 4: Software, Change and Missionaries

In 25 words or less, what would you define as the critical success factors for rolling out project and performance management software across a workgroup or team?

If you were to start today, what would be on your list for doing what works, and avoiding what doesn't? If you aren't sure, but interested, maybe even slightly uncomfortable at the prospect, you are not alone. Rolling out a project management or groupware solution is enough to make all of us in the position of management at some time or another cringe. It starts the voices in the back of the head. They are quite persistent in their warning that there is trouble ahead. The voices say that to launch on such a venture is to:

* Enlist direct reports and peers in learning "one more" software package amidst their protests that they are already swamped, and frankly don't need or want another tool,
* Incur high frustration, something akin to "herding cats" or "pushing a wet noodle up a hill,"
* Expose oneself to being publicly challenged, defied, and/or defeated,
* Fail to generate the outcomes expected, promised, or hoped for,
* Engage in risks such as spending money, taking on resistance and for what exactly?

In fact introducing new software to be applied across a team or group looks a lot like engaging in a change management effort amidst numerous risks. It is. Employing new software tools, especially as part of a step forward in performance and productivity, requires a change in the way people work. Let me say it again more directly, it changes the way people work. For many people in management, the software rollout (change) process means embarking with the expectation that "things are going to be different." And as we will see, often without having clearly defined and worked through with the group receiving the software what exactly is going to be different and why.

This article is a four-part review of our findings and recommendations in this area. But before we continue, let's be clear about what to avoid in implementing software, or as we like to describe it...

The course of the hapless missionary.

The typical process of implementation often starts with a technology adopter or visionary who becomes a "missionary" (for use of a software tool). By that we mean someone who decides that a software package is a valuable solution for others. Sometimes they arrive at this decision point out of personal experience; sometimes they arrive at this conclusion based upon what they think someone else on their team needs, e.g. "You really need to be more organized."

Having uncovered value in the software, they determine that it would be beneficial to have others, if not everyone, share in their discovery, and experience the benefits of using this software tool. They begin the process of attempting to convert others. They may or may not encounter interest, but they always encounter some form of opposition, passively if not actively. Everyone is not convinced they should convert to the new "betterment" tool.

Part of the missionary approach to tools, is the belief that others would share in their appreciation or value or benefit from this tool...if they would "just try it." However sharing their perspective and tools, even if done enthusiastically, is usually not enough to convert the team or group to a new tool. Typical results yield only a couple of converts within a workgroup of six to twelve, with regular usage by others limited to a cursory review and/or try it approach (drive it around the block and then back to the lot). This is further anchored or underscored by the belief position of other team members that:

1. "I'm too busy to learn a new tool," and
2. "I'm doing basically OK with the (preferred) tools I presently know how to use," e.g. so why do I need to change.

Encountering this type of reaction, an effort that started out with such zeal easily becomes thwarted. Our findings indicate that "missionaries" are eaten by the "cannibals" (give up on the software conversion due to resistant staff) within six months, if not supported by insistence from a person or position of power. What do we mean by that? Despite the lofty commitment to values of increased performance, productivity or simply reduced work effort, the average implementation across a group drifts into what might be called an aspiration. As aspiration to improve that is not realized, and is only moderately enhanced by a command from above. From inspiration to aspiration... without a successful deliverable turns out to be bad business. It's not just an unsuccessful attempt that generates little return on investment; it can leave individuals frustrated and the workgroup less collaborative.

Purchasing and installing productivity software from this purview parallels what one might expect to be the life cycle of the average piece of home workout equipment. The average consumer starts out with gusto in the inspired phase. Shifts to an aspiration as usage declines, and then concludes in storage or a garage sale. From inspiration to aspiration to storage on the sidelines as one more goal unachieved, due to the requirements of more work, more effort, more discipline... more of something than was unavailable to resource the change in behavior.

The good news is that we have also identified not only the painful average life cycle of (marginally successful) groupware implementation; we have also identified the patterns of what works in successful software introduction. Patterns that emerge in the three best practice areas mentioned above. We'll start with the first practice, "Shed illusions about performance improvement and replace with four key reality concepts" in part two.