This is the fourth post in the series about Getting Software Implementation Right. We have covered why implementation matters, preparation, and selling. This post picks up after the kick off meeting has occurred, and we are digging into the implementation work.

Kickoff recap

It was mentioned as a Pro Tip in the last post, but I am going bring it up again because it is SO important. If you are going onsite for the project kick off, bring your implementation team along and require the client to commit to having their team available all day for several days following the kick off meeting. Yep…require the team to be available. If the client can’t spare their team for a few days right after the contract is signed, it is a bad sign that they are not committed to a successful implementation.

My preference is to hold the kick off on a Tuesday morning. The team can fly in on Monday, run through one last prep, and get a good night’s rest so they are fresh for the morning. The kickoff runs 2 or 3 hours and ends at lunchtime. The next hour is spent bonding with the client over a casual lunch.

After lunch, the implementation work starts. Implementation team members from the vendor and customer work all day for the next three days.

Here are a few reasons why this approach is so successful:

• The customer is never going to be more excited about doing implementation work than they are now.
• Working relationships and trust are much easier to establish when working face to face.
• Turnaround time on questions is zero when you are working across the table. Eventually, there will be time zone differences, vacation schedules, missed emails and unreturned phone calls, but a solid start will save weeks or month.

Team

The skills you need on the team and the amount of time they need to commit are going to be different from one vendor to the next, but the common denominator is that you need to have:

• Smart people who know the work, not just people that happen to not be busy
• Preferably not managers, you want doers who really know the tasks well
• People who are respected

Pro tips:

• Have a governance team right from the beginning so there is accountability
• Strongly suggest that the customer backfill the implementation team members so they don’t have two jobs during the implementation

Data loading

Loading data is often the critical path item all teams have their eye on. User accounts must be loaded, data migrated from the legacy system(s) and there is validation testing to be done before configuration or training can be finalized.

Pro tips:

• Provide the customer with an accurate data dictionary. This should clarify the fields, format, data type, length, and how it is used – context is everything.
• Validate data. If records must have a last name and email address, programmatically verify the records before attempting a data load. By verifying all the data meets the definition of the data dictionary, you will save a lot of time fixing problems with dirty data found during testing, or in live production.

Training

Training is necessary but can be a gigantic waste of time; so don’t sit everyone down for days of “how to navigate the system” training. Instead, use the information from the Process Impact evaluation to tailor training to individual tasks. Using a before-after approach, bridge them from how they used to do work, to how they will do it now.

Pro tips:

• Design all training around how that role is involved with a specific task
• Deliver all training as short (5 minutes or less) videos
• Provide desk references or work instructions as a backup
• Create a matrix of which tasks each role needs training on
• Load all training in your LMS and assign training from there
• Update training modules as the product and processes change

Process Impact

When you implement a new system the way people work changes, there is just no way around it. Hopefully, there will be a lot of tasks that go away due to automation or streamlined processes, some work will be done differently, and there is the potential for new work. In any event, you are changing people’s jobs and people are not great with change. They are relying on you…don’t break their job.

Pro tips:

• Create a process checklist. Your application does stuff, so make a list of what it does and use that as a starting point to inventory which of the task your system is used for are currently being done by the customer, by who (so you know who to train), and how they do this work.
• Get the experts involved. Your inventory lists out who executes which tasks, so get them involved in defining how the system should be configured, tested, and trained. This will create additional champions for the project, add credibility because the right people were involved…not just the managers, and it will dramatically increase the likelihood that the results will be correct.

Configuration

This is the tricky part, because the vendor does not perfectly understand the customer’s operation, and the customer does not even begin to understand what the software is capable of. The customer doesn’t know enough to make all the right decisions, this is work they will never do again, and the whole organization will have to live with the effects. The stakes are high, and the customer relies on the vendor to help inform and guide configuration decisions.

Pro tips:

• Create configuration decision trees. If you have ever used a program to file your taxes, you know the basics here. A configuration decision tree steps you and the customer through the questions that end up with the best configuration decision. This is also useful when you have new people on your team, and you want to get standard configurations that can be easily understood by the Customer Support team.

Sustainment plan (go live support, ongoing support, new hire training)

Implementation teams think that their job is about getting software implemented. Not so. The job of the implementation team is to implement software in a way that enables the customer to be successful with it, and that means the need to plan for how it is supported at go live, supported long term, how new hires are trained, how updates are rolled out, how users are added and removed, how the customer is communicated with when there is a problem, how the account is managed, etc., etc., etc.

Pro tips:

• Identify adoption champions. Find people within each team that are bright, energetic, and want to be associated with the implementation. Give them a little extra training and designate them to be the first line of defense within their team.
• Think big. In large call center type settings, we give the adoption champions project branded T-shirts to wear on go live week, so people know who to ask. On go live day, everyone has a welcome kit on their desk with a treat, information about where and how to get support, and a helium balloon on a string…if they need help, they send up the balloon so it can be seen by an adoption champion.
• Think long term. Many tasks have a cadence that will need support the first few times they occur. You can support the finance department for the first week, but when it comes to month end close, quarter close, or the fiscal year close you had best be there to see them through.
• Tee up the hand off. When planning for how the vendor and the customer interact after implementation, it is the perfect time to introduce the account manager and customer support teams and processes. The last thing you want are customers that will not let go of the bonds they formed with the implementation team.

Change Management

A quick note about project management. Although this series covers a few project management related topics (kick off meeting, governance, schedule, and change management) there is much more to competent project management that are intentionally not covered in this series.

Changes to what the customer wants done are not uncommon and need to be carefully tracked, evaluated, approved and agreed to. Playing this one fast and loose is a recipe for project friction and potential legal fights.

Keep in mind the difference between configuration/approach changes that can be easily accommodated, and real changes of scope. If the customer decides to implement the east coast before the west coast, maybe not a big deal…document it, communicate it to the team and move on. If the customer decides that instead of web-based training they want live, onsite training, you will want to document that as a change request. Even if you fulfill the change request without charging the customer, each change should be reviewed for impact to the project team, given a cost, and a funding source (customer payment, discounts given, sales incentive, etc.), and approved by the customer.

Without this approach, the implementation looks like changes are simple and free. Anything that is free is a candidate for abuse.

Go live

Nothing can kill a project faster than a botched go live, and how the customer chooses to go live can come in a lot of forms, it is not just big bang or slow roll. Some will go big bang with headquarters and a slowly building rollout to satellite locations, some will go one department at a time, one product at a time, anything you can think of, so plan for failure.

That is right…plan for failure. Think of everything and anything that can go wrong on go-live day and make sure that everything that can be done has been done and all the bases are covered, or the chances are so remote that both the vendor and the customer are willing to risk it.

Pro tips:

• Partner with the local teams. In big implementation projects, it is easy to centralize thinking and not consult the local leadership team. This leaves them feeling like the project is being done to them, rather than done for them. A simple reach out call to local leadership to review the go live plan and revise based on their input will go a long way to build goodwill, and avoid silly mistakes. True story…Through one of these go live prep calls, we learned that more than ½ of the office would be on holiday the week they were scheduled to go live. They happened to have a very high percentage of people belonging to the same religious group, and it was a holiday. A 15 minute phone call and a stupid (and culturally insensitive) mistake was averted.
• Define success. There will always be people that hate the new system, the new vendor, the new workflow, or anything with the word “new”. To prevent them from convincing the customer sponsor this system was a big mistake, define objective criteria for how to measure success at go live and beyond.

Next up

In the next article, we will wrap up the series with the move from Implementation to sustaining. Hopefully, this has been an enjoyable and informative series for you, but please hit the comments to let me know…even if you think it stinks!