In part 1 of this series on a modern approach to system selection, I covered the internally-focused activities associated with selecting a new system. This included:
· Defining business need
· Creating the selection team
· Performing the criticality and risk assessment
· Determining the system selection process and assessment criteria
· Defining the business requirements
Once these internal activities are complete, it’s time to move on to the external activities including:
· Identifying potential vendors/solutions
· Preparing the RPF and facilitating the RFP selection process (if the team decided it was necessary and desirable)
· Conducting tailored demos
· Performing references checks
· Planning the project
· Negotiating and signing the contracts and agreements
Identifying potential vendors and solutions
This is where your team puts on their investigator hats and does some sleuthing. Identify some companies that are in your industry and are either in a similar stage or a few steps ahead. You will want both.
Then reach out to various folks in those companies and ask them what they use, why they chose it, what their experience has been, and whether they would choose it again. I also recommend asking what else was considered in their selection process and why they didn’t choose those solutions.
Also ask what their role was during the selection and implementation and whether they actively use the system. All of these answers will give clues as to how you should take and use the information.
It’s important to talk to a few folks in each of the companies to get multiple perspectives. If the accounting/finance team led the selection, there may have been a bias towards their needs and requirements which makes it critical to understand how that bias impacted the other functional areas and their users.
Do a web search of solutions in the space and add to the list. If the solutions are mentioned during the reference checks, then you already have the info. If they are not, get in touch with an account exec or sales person and ask them for the names of some of their customers that might be similar to yours in size, sector, and organizational stage. This is critical!
Finally, reach out to SMEs in the space (including consultants) to see if they have any thoughts on the solutions.
Take good notes! This is part of the education and selection journey.
Once you have a list, take a look at your requirements and objectives and narrow down to 3–7 possible solutions (ideally no less than 3 and no more than 5).
To RFP or not to RFP…that is one of the questions.
I wrote a whole separate blog post on effectively using an RFP as part of your IT system selection process.
Conducting tailored demos
I see a lot of selection teams with relatively little experience with the types of systems that they are selecting. Conducting tailored demos allows the selection team members to more easily link what they are used to, to what could be in the new system. Once the list has been narrowed down to 3–5 candidates, it’s time to take a look at the possible solutions as a team and compare against the defined requirements and objectives.
I suggest defining an agenda for vendors based on logical processes and workflows and then taking into account who needs to be in attendance for each section. It’s important to make sure that the right people are in the room (or online) for the relevant sections of the demos. Some members (key players and decision makers) should attend all parts but others can be optional.
I then provide the proposed demo agenda with objectives to the vendors offering up certain days (that I have pre-negotiated with the team members) for them to select from. I also let them know that they can suggest an alternative agenda based on the way their system flows as it is important to understand how their system works to be able to best leverage their best practices during the implementation (assuming they cover all topics in the agenda). I talk more about adopting best practices with enterprise systems in another blog post.
I also recommend providing some data for the vendors to work with so that they can help to bridge the gap of the current practices to the future system practices for the team. This also provides the vendor with an opportunity to help to shape the team’s thinking around what could be done with the new system rather than just adopting existing practices. I’ve also seen some systems unable to satisfy basic requirements which became very obvious during the demos.
Note: I generally recommend getting an NDA/CDA in place prior to providing the data. The vendors usually appreciate this since they don’t want their proprietary information getting out either. Some vendors may require an NDA before they provide the RFP response so I often offer that up in the email to the vendors with the RFP.
Provide the team members with scorecards to capture their notes and ratings about the systems against your previously defined objectives. Collect the scorecards immediately following each demo so as to avoid confusion. Also, you may never see them completed scorecards if they aren’t collected immediately.
Performing reference checks
In the RFP, I generally ask for three customer references to confirm that the vendor plays in the space my client is working in and I recommend you do the same. I also assure the vendor that we won’t be contacting the references until this point in the selection process and that we will ask for introductions. Vendors are notoriously (and rightly so) protective of their reference clients.
After the demos, I recommend bringing the team together to narrow down the choices to 2–3 and performing references checks on the top candidate. Keep the other two in your back pocket in the event that the reference checks don’t go well.
I recommend putting together a set of questions for the reference person and provided in advance of the call. At least two team members from different functional areas or perspectives should be on each call as we all focus on and hear different things. And it should be the same two on all of the calls if possible. Take notes.
The extent of the questions will depend on the criticality of the system, what is important to your selection team, and what came out of any of the previous steps that might concern your team. I also use it as an opportunity to learn more about the system, the vendor, and how to best implement it.
Planning the project and negotiating/signing agreements
This is such an important part of system selection that not only did I write a blog post about, it but I recorded an episode about it on my podcast, Piloting Your Life .
The most critical thing to keep in mind is to plan the project before signing any agreement. You lose all leverage with a vendor once you have signed agreements and I guarantee you that your assumptions are very different from the vendor’s assumptions.
Now what?
Now that your system has been selected, the implementation project planned, and agreements signed, it’s time to kick off the project. By going through the steps I’ve outlined for the selection, your company has reduced the risks associated with selecting and implementing a less than ideal solution. These days, you need every competitive advantage. Don’t let a bad system selection or implementation be the factor that causes you to lose your competitive edge.
Need more help?
If your company is budgeting a new system and/or beginning the selection process, feel free to reach out to me and we can discuss the best way to avoid additional costs, mitigate risks and increase the rate of success for your company’s system project. To learn more, visit my website or email me at Terri.Mead@Solutions2Projects.com.