“To achieve great things, two things are needed: a plan, and not quite enough time.”
– Leonard Bernstein
We laugh at Bernstein’s words. In order to get through a software selection successfully, you’ll need a plan. You’ll also need urgency that prioritizes the plan above all the other competing projects clamoring for resources. If you started at the beginning of this guide, you have identified your business needs, calculated the costs to continue as you are, and lined up some executive sponsorship. Now is a good time to get a plan on how you’ll run this selection process.
A plan should include these five components at a minimum. You might have other considerations to add for your situation. Some of these topics warrant chapters in this guide. We’ll discuss each of them briefly here and refer you to specific chapters as needed.
In a software selection plan, you should identify different types of team members. Change is hard, even when people say they want something new. Knowing who is impacted by this software selection and how they are impacted is critical to the success of the selection, implementation, and long-term use of the software.
a. Users. You’ll want to identify the participants of the business processes in question as they’ll become the users of the software you buy. The user list is not static. As you define requirements and learn more about every team touched by each process, you’ll make changes. Classify users in three categories based on how they would use a solution: power participants, occasional participants, and readers. For the initial plan, you may not identify all users if your company is large but try to identify some users in every category.
b. Stakeholders. Note who owns the business processes the software will support. They have an interest because this project will affect them and their teams directly.
c. Influencers. We’re going to borrow from social media marketing here to identify people who can sway others for or against the project or eventual software selected. Influencers can be any level in the company and are respected for their knowledge and skills.
d. Sponsors. Continue to seek sponsors—executives who can help make the project a priority and/or provide budget and resources. Sponsors ideally take some level of responsibility for this project and will build support with others.
Here’s a helpful template that shows one way you can put the team identification together.
The next chapter in this guide covers requirements capture in detail. For your plan, you want a requirements-gathering phase. You’ll use the active inquiry model we provide to ask each team member. The goal is to pinpoint the actual requirements you have for a solution to your business need.
You have powerful tools today for solution research. Gone are the days when you had to rely solely on what vendors and a few questionably agnostic industry analysts told you about software options. In your plan, you’ll want to include several different research tasks including digital market surveying, digital and direct vendor engagement, and solution verification activities.
With your business needs and rough cost calculations, you’ve started to build an argument to prioritize this project. During the selection process, you’ll build a financial case based on the business needs, costs of not solving the challenges, and the costs of the solution you select.
Here at Arena, we’ve found that 78% of our buyers select software by committee, but one member of the committee often has an outsized impact on the decision. In articulating your business needs and identifying the team impacted, you’ll see how the decision-making is going to happen. Later in this guide, we’ll talk more about managing committees. Right now, you can consider the dynamics of stakeholders, influencers, and sponsors along with how decisions are typically made at your company.
You should have a documented project plan for your software selection process. A documented plan can be shared across the team, keep you on track with tasks, and be used to communicate findings and decisions. You can use any variety of project plan tools—from Excel or Google Sheets to any number of newer project and task tools.
No matter how you manage the project plan, it should:
Once you have the plan, you need to get buy-in from all stakeholders and sponsors. Have everyone review and provide comments. You can do this asynchronously or in a team meeting. It is important to take the time for everyone to agree to the overall plan you will follow.
Free Resource: Use this Trello template to get started. It includes template sheets for teams, requirements, and more for a PLM/QMS software selection project.
A project plan is like a shopping list until you share it—then it becomes a dinner party. You need to have a communication plan. It doesn’t have to be complex, but it does need to be consistent. Your communication plan should include what information you will communicate:
To craft this communication plan, it is good to go back to that team list and consider who needs what level of information. It’s common to provide two levels of communication regularly—a high-level summary for sponsors, influencers, and stakeholders, particularly those in executive management, and a more detailed communication for active selection team members (note that some people may receive both communications).
Finally, consider how to make your communications as easy to read or consume as possible. A good rule is to make each communication as short as possible while still providing the information needed.
✓ Draft a software selection plan outlining the five components, including a first pass at team identification
✓ Get buy-in on the plan from stakeholders and sponsors
✓ Set a communication plan
