How to Buy the
Right Software

Chapter 7: Preparing for Deployment Success

Deployment Approach

1. All at once
   For less expansive tools that touch only one team or process, you might implement all/most of the solution at one time. If you are implementing an enterprise system like Arena for PLM/QMS processes, you may not want to take this approach—even if you are a younger company—particularly if you are growing rapidly or tackling important milestones such as new product launches, market expansions, or regulatory approvals, you should be sensitive to trying to do too much too soon.
2. Phases—the how-to-run-a-marathon-successfully plan
   For enterprise platforms that many teams will use for multiple processes, you will most likely use a phased approach to implementation.

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.

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.