In my previous post I described how the probability of success increases as we educate ourselves and user-base on products we are implementing early on. The primary benefits we saw are that:

1. Users know what they are doing, and
2. We can implement faster and receive a return on investment sooner.

In this post I want to examine the benefits of implementing tools in phases in similar terms.

Figure 1 represents the ideal timeline for achieving ROI while implementing a tool. You will notice the Intended Value expected from the software is not realized immediately, but in only a few months the Intended Value has been exceeded.

Figure 1

Consider the impact that biting off more than you can chew may have.

1. You waste time “implementing” instead of focusing on problems that can be solved today.
2. You lose any momentum you had coming out of the tool selection process.
3. End-users don’t take the tool seriously.
4. Your organization experiences a delay in the return on its investment. Your implementation timeline may end up looking something like the timeline illustrated in Figure 2.

Figure 2

Getting an Early Win

As you implement a process you can roll out quickly you will:

1. Show stakeholders that progress is being made.
2. Simplify configuration considerations.
3. Allow internal trainers and support staff to work with fewer people at a time.
4. Improve future phases and rollout by incorporating lessons learned.

 Implementation Recommendations

1. Start with a single key process (or a few critical projects)
   • Create a flowchart to diagram the process
   • Provide robust definitions of each step
   • Identify players involved with each step
   • Describe transitions between people and/or teams
   • Include in your implementation planning only resources and groups that are involved in this process (or projects)
2. Define Success Criteria for:
   • Phase 1
   • Phase x
   • And the implementation as a whole
3. Configure your tool to satisfy only the selected process and the success criteria
4. Rinse and Repeat for additional processes.

Figure 3 illustrates the potential implementation timeline and how it correlates to a return on your investment when you implement your tools in phases.

Figure 3

I know it is tempting to implement tools around the end state. While this is always a part of our success criteria, I submit that you will find you have less investment to absorb and can achieve your intended value on a phase by phase basis, which will compound into your total ROI and increase the probability of having a successful implementation.

Over the next few weeks I want to share a couple observations I’ve made while implementing different software packages.

An important part of every software implementation is understanding how to receive value from the system. Nobody begins an implementation expecting or wanting to fail. A failed implementation rarely builds confidence of managers, colleagues, or subordinates in your ability as a worker. However, all too often people implementing software place stumbling blocks in the path to success that don’t need to be there.

Strategies:

1. Providing Early Education
2. Implementing in Phases
3. Customizing Documentation and Job Aids

The final post in this series will be titled, the Cost of Giving Up Too Early.

Moving on to this week’s topic… Providing Early Education.

I’m going to frame the conversation in terms of the return on investment you receive from your software.

Figure 1 represents the ideal timeline for achieving ROI while implementing a tool. You will notice the Intended Value expected from the software is not realized immediately, but in only a few months the Intended Value has been exceeded.

Figure 1

The initial months before the Actual Value passes the Intended Value is considered an investment period. This is the time that the heavy lifting of designing, configuring, and piloting the software takes place. In all likelihood, the tasks of training and rolling out the software will happen before this implementation milestone occurs. The investment period is illustrated in Figure 2.

Figure 2

To reiterate, a successful implementation is realized when the area of the net Actual Value (blue) is greater than the area yielded during the Investment period (red).

Creating an implementation timeline that results in greater net value than yielded investment value becomes more probable when you get educated on using the product early on, and when you make a plan for educating end-users as early as is practical.

Figure 3

Ideally, you will begin to recoup the investment cost early into your software contract. If you don’t achieve ROI prior to your first renewal, stakeholders tend to start shopping for alternatives (both in software solutions and personnel).

Figure 3 above shows the impact a 5-month delay in education can cause to your implementation. The gray box representing the delay is pure waste and drastically decreases the probability of having a “successful” implementation.

My first implementation strategy is to get educated on your new product early and provide education to initial implementation stakeholders and users at appropriate times.

Before leaving for work last Wednesday my wife informed me that I needed to help her move a large filing cabinet we weren’t using into her car. The night before she had gathered a bunch of things we could live without and loaded them into her car to drive them to the local thrift shop.

When we get the filing cabinet out to her car we decide it cannot fit without adjusting the seats and rearranging some of the things already in there. She was tasked to move the car jack, lug wrench, and a few other items into the front passenger seat to make everything fit in the back. While she is completing her task, I go about moving other items around in the back when I hear a scream. My first thought was that she stubbed her toe on something – she is always stubbing her toes. It turns out I was not far off. She dropped a metal cylinder right on her forth toe on the left foot – and yes, she was bare foot; she is always bare foot.

She insisted it was just a scratch, but was too squeamish to actually look, so it was up to me. What I saw was more than just a scratch or even a cut; it was flesh dangling. My first reaction was to not tell her how bad it was. Then I thought through how much more difficult the argument would be to convince her we needed to go to the urgent care facility and how much worse it would be if we didn’t get treatment immediately.

Too often, too many of us work in environments where the bearer of bad news is shot. Other times management may seem to (at least on the surface) want to ignore problems as they come up because they are such an inconvenience. The truth is, the earlier the alerts go off, the less damage an issue can cause.

Executives, project managers, and team members all need to work to create an environment where bad news is good news. When bad news becomes good news, it is a sign of maturity in your organization. When communication becomes more important than the production schedule you will find that this communication facilitates meeting deadlines.

While my wife did not want to hear that she nearly severed her toe, it was an important piece of information to begin the healing process. One lost toenail and four stitches later, I’m happy to say, she is hobbling around chasing after our one year old and keeping up.