How to Buy the
Right Software

Phased Deployment Approach Options

If you take a phased approach to implementation, you’ll be deciding which tasks to accomplish in each phase. There is no one right way. Much like training for a marathon, you want each phase to have visible wins for your team—both to ease the process pains as well as demonstrate the solution is working. In determining what each phase will include, you want to think about the uniqueness of your company, culture, organizational structure, and other corporate initiatives.

In deciding on phases, consider the following:

• Business needs: the problem or opportunity areas you’ve identified that are driving the purchase
• Data flows: if the software of choice integrates or shares data with other systems, you should include these data flows in your phase planning. Some data flows may be necessary to support business processes while others can be done in later phases for additive value.

Team

• Start with the selection team but re-evaluate/expand. Don’t be afraid to re-assess and ask team leads for the right people once you have planned your deployment.

• Cover all the team roles and responsibilities. You’ll typically need people on the implementation team to cover the following aspects: processes, data, administration. You may also need people for integrations and technical work depending upon your solution (anything on-premises has a much higher technical lift and ongoing maintenance).

  Get the details: For roles you’ll need to cover with Arena, see the project plan template.

Get Educated

Don’t put off deployment team education. While any user training you might need to do can wait, the deployment team needs onboarding as soon as possible to be effective.

• More importantly, remember that you’re reviewing more than a software solution. You’re looking at each vendor’s complete set of services and approach to not only implement software but to help your company fuel adoption, gain optimal benefits, and continue to be successful for years.
• Solution basics: enterprise software solutions, no matter how well-designed, require onboarding, particularly for the business owner and administrators who will be making implementation decisions. Get the team trained up on the platform.
• Advanced solution knowledge: depending on the solution and scope of your implementation, some team members may need advanced training for administration, data activities, or other specialty areas. Team members will perform their roles better when they have the knowledge and tools they need.

Communication Plan—5 Cs

Change is hard. You are deploying a software that will require change. Following these basics of communication will reduce confusion and risks.

1. Consistent: set up a regular method and timing for project communications to help everyone stay informed.
2. Clear (and concise): create a format for project communications and re-use (another win for consistency). The format should encourage quick reading and easy writing. Consider clear sections for progress, next actions, and risks that need to be addressed.
3. Congruent (conform): fit the message to the audience. Remember to include executive sponsors and vendor representatives on communications at the appropriate level.
4. Comment: communication is two-way. Give people easy ways to provide feedback or updates, whether through meetings or asynchronous communication, preferably in a self-documenting project space such as a Trello board.
5. Chronicle the communications: archive all project communications in a central location that is accessible to the team. People can catch up if they miss communications due to absences and you also create a running history of the project. The solution you are implementing may itself be a place to store such information (indeed, Arena runs implementations through the Arena project functionality in the platform).

Risk Mitigation

An often-overlooked deployment planning activity is risk assessment. The purpose of risk assessment is to mitigate risks as much as possible. The team should proactively discuss risks to project success overall as well as to individual tasks or milestones and then consider what steps should be taken to reduce or remove risks. Risk assessment steps should include:

• Risk identification: articulate the risks. Think of the “what ifs” that could derail the project. For software deployments, common risks include a loss of team resources for other projects, lack of adoption, a technical challenge, and unexpected platform limitations.
• Threat level of each risk: once you have each risk identified, determine the threat level to the project. This can be a simple three-level risk system such as low, medium, high. You aren’t going to completely ignore low risks, but you will have a different response to low-level risks vs high-level risks.
• Possible mitigation of risks: for each risk, determine how you may mitigate it—steps to completely remove the risk or reduce its impact. Mitigation might include proactive steps (such as additional communication sessions with the extended team to ensure adoption) for a high risk or simply awareness of a risk and recognition that if the risk occurs, the team will then assess for response.

Once your risk assessment is complete, include risk mitigation in project planning and communication as appropriate. Also be prepared to revisit risks as the project progresses.