Approach for selecting a new business system
Are you tasked with helping your organization select a new business system? Typically, a business department will be the ones approaching IT for such system requests. Many times they will come with software in mind that they learned about at a conference, from a Google web search, or their neighbor. No matter where the idea originates, the following steps work well as a methodical way to work through software selection for your organization:
Discovery - This is really the most important step. How thoroughly this is done determines the ultimate success of the project. It’s an absolute must that you first get a complete, first-hand picture of the business and/or technology problem and issues that need to be addressed from key stakeholders before any software solutions are explored.
Document requirements - Writing these based in the discovery you’ve done is critical to confirming understanding for yourself and among key project stakeholders. It also makes the writing of subsequent documents like the RFP simple and can also eventually serve as the user acceptance test plan for stakeholders when you’re in the implementation stage.
Develop a Request for Proposal (RFP) - If you’re purchasing a complex system, this gives you a consistent way to request and evaluate proposals from multiple software vendors. Even if you’re evaluating simpler SaaS (software as a service) solutions, the creation of a vendor evaluation spreadsheet still helps you organize information gathered from product websites and free trials for your stakeholders to review.
Identify target software vendors - There are so many ways to do this as discussed below, but the important thing is to be able to narrow down the field to 3-5 vendors whose systems will likely match your organization’s requirements and budget.
Vendor evaluation & selection - A multitude of factors will need to be taken into consideration jointly with your stakeholders to get to a final decision. You’ll need a combination of both quantitative and qualitative criteria from the RFP process to help make the selection.
Run a pilot test with the selected vendor before full purchase (Optional) - This is highly recommended if the complexity or cost of the vendor system being considered is very high, the system is mission-critical to your organization, or if the technology application is completely new to your organization.
The length of time needed for each step above is 100% determined by the complexity of the solution being considered and the key project stakeholders’ technology savviness. So now let’s dive into the details of each of these steps.
Discovery
This is the most important step to do so always start with a discovery process with your stakeholders in order to get a full picture of business operations before even thinking about selecting any technology solutions.
Identify key stakeholders to interview. Be sure to include not only the requesting business department but also others that they can identify who are a part of the overall process for the business problem they are trying to solve. This list will likely grow as you begin the discovery interviews below and the current processes and issues are revealed. Also make sure you interview IT departments for their requirements, especially if solution will involve technology that is new to your organization.
Create an initial standard set of interview questions that help define the business problem that the department is trying to solve, taking their focus off any particular technology or software as much as possible. If you’re unfamiliar with the business area or technology space, you should absolutely also do your own homework first by getting smart on the technologies and business systems and features in the landscape (lots of web searches and white papers to read) to help formulate your interview questions. Make sure you’re keeping the questions relatively open-ended so that you’re not leading the interviewee.
Schedule 30 min - 1 hr interviews with the key business managers and potential end users to understand their needs thoroughly. Typically, 1-1 interviews are best since interviewees tend to be more open and forthcoming with their interests and concerns than in a group setting. However, small group (2-5 people) interviews with like users, say Customers Service Representatives, can be a faster method. It’s important to have the standard set of interview questions in hand to start but always be listening during each interview and ask follow-on questions as the interview progresses. You should then incorporate new interview questions for the next person or group you meet with to get a more complete perspective on the issues. Depending on how different the questions are between the first person or group interviewed and the last, you may want to circle back to the first ones to ask additional questions. Recording the interviews is a great way to be able to review them in order to write business requirements, plus it allows you to focus more on what the interviewee is saying and less on feverishly taking notes without missing anything. If you have the budget for it, there are transcription services online where you can upload the recording, and they convert it into text for you like Rev. Note: Also, it’s a good idea to have the interviewee or group actually demonstrate the systems and steps they currently use that may be problematic so that you truly understand the issues they are trying to solve with new technology.
Summarize findings described in the next step as quickly as possible after each interview session (within a day or two) so that stakeholders can review what you’ve gathered and know that you’ve really understand their business processes and pain points.
Document Requirements
From all the discovery interviews, you should be able to draft a requirements document that will feed into the creation of an RFP:
Business objectives and benefits - Try to be as quantitative in your descriptions as possible. Being able to quantify the problem and potential benefits in terms of added revenue can help determine how much money your organization should invest in the project.
Detailed requirements - Synthesize and organize business requirements into functional areas and individual features in an easy to understand document that the business department staff can review for completeness. Examples of functional areas are: Search Capability, New Customer Creation, Export Capabilities, Application Security, etc… Typically, an individual requirement can be in the form of “Ability for <User role> to do <Task X>” or in an Agile user story format of “As a <User role>, I want to do <Task X> so that <Reason>”.
Business process diagrams (Optional) - You might be able to diagram current business process steps based on discovery interviews to help demonstrate where the issues are that a new system will help solve. A picture is more powerful if you can design it in such a way to capture all the details on it.
The process of drafting what you think you’ve heard from users into a document and having them review it for correctness will allow you to accomplish the following:
Solidify your own understanding of the business problem and detailed requirements.
Reconfirm and refine all of it jointly with the stakeholders.
Figure out where there are gaps in the processes described to date and if additional discovery interviews need to happen.
Once you’ve got a final version, the last step is to have the key decision-making stakeholders agree on the relative priority of each feature. A simple scale such as the following can work:
Must Have/Critical (=3)
Important/Helpful (=2)
Nice to Have (=1)
However, it’s very likely that 80% or more of the features will be categorized as Must Have/Critical on the first pass (human nature). If the features list is very long, it’s going to require some discussion and negotiation with your key stakeholders to make the spread more balanced between Must Have/Critical and Important/Helpful. Nice to Haves should be kept to a minimum relative to key features so that vendors don’t waste too much time focusing on these. Key point: your internal organization’s feature priority ratings should NOT be included in the spreadsheet that is sent to potential vendors. Only keep it for internal vendor RFP evaluation.
Develop an RFP
Writing a solid RFP that contains all essential functions for your organization is key and so the requirements documented in the previous step should drive the creation of yours. There are many generic RFPs available on the Internet, whether for sale or for free (mainly from software vendors), for many business system functions, e.g. digital asset management, CRM, financial systems, etc… These are great for reference when creating your own company’s RFP. However, the downside is that these canned RFPs probably contain way more features and functions than your organization truly needs to solve its problems so creating your own from scratch focused internally is best.
Typically, RFPs have the following 2 parts:
Text document (Optional) containing organization and solution background and RFP process information for vendors. Include information about your organization structure and departments involved, business objectives. and problem to solve for the system(s) in the RFP. If you can provide exact numbers of users in each department or role, that can be helpful to the vendor to understand scope and pricing. There should also be a section about the RFP process steps and timeline that your organization will be using to evaluate vendors. Of course, this part is only necessary for complex, large-scale system evaluations requiring direct vendor interaction.
Spreadsheet containing the detailed functions and features to be evaluated across vendors for the solution and for vendor performance criteria like system documentation, support plans, and pricing. Organize it into the same functional areas from the requirements document and list each feature under that. Using a spreadsheet format will allow you to combine multiple vendor responses (or your own research into SaaS solutions) easily into columns for filtering and sorting for evaluation. It will also allow you to attach a point system to the responses below to eventually multiply by the scale of relative importance you attach to each feature from your organization’s perspective. Ask each vendor to answer with one of the following responses feature by feature:
Yes (= 3) - meaning their software does exactly the feature specified in the current production release of the software.
On Roadmap (=1 or 2 depending on the Explanation) - meaning the feature will be included as specified in a future release of the software. For any of these, ask the vendor to provide an Explanation containing which calendar quarter/year it is expected. The Explanation should be in a separate column.
Partial (= 0, 1, or 2 depending on the Explanation) - meaning their software does something similar to the feature specified or that there is an alternate way to use their software to accomplish the same business function. For any of these, ask the vendor to provide an Explanation. The Explanation should be in a separate column.
No (= 0) - meaning their software currently doesn’t do that function and there is no plan to add it in the future.
If you are evaluating SaaS solutions without sending vendors an RFP, you can simplify the above down to Yes, Partial, and No as you and your stakeholders read vendor website information about features and do some free trials to confirm the sales pitch.
Identify Target Vendors
Software review sites like G2 or Capterra or other online publications can help you determine which vendors to consider. Key stakeholders in your organization may also have heard of vendors from conferences they’ve attended or from professional organizations. If budget allows, you may find a technology research services firm like Gartner or Forrester helpful. Try to narrow down the list to 3-5 to contact for an RFP response. If you pick more than 5 vendors, it will be extremely time-consuming to evaluate that many thoroughly. If you’re planning to send any vendors the RFP, you should contact them in advance to find out if they are interested first based on the size and scope of your project.
Vendor Evaluation & Selection
As part of the RFP process, you should definitely arrange for vendor system demos if investing in a complex system. Ask vendors to be prepared to do a demo format that is tailored to your RFP functional categories. Be sure that you and your stakeholders have your RFP features list in front of you during the demo to evaluate completeness yourself and ask the vendor about any features important to you that were not covered in their demo. As we all know, a vendor could very well reply with a “Yes” for a feature on their submitted RFP response but when demonstrated, your stakeholders might consider it a “Partial” instead. If you’re evaluating a SaaS solution, plan to sign up for free trials with your stakeholders, actively testing the software against use cases and features from your requirements spreadsheet to check for completeness.
Another key evaluation factor is how the vendor behaves during the RFP process itself - completeness of their RFP response on submission, their ability to follow instructions, how well they listen to your stakeholders on calls or demos when specific requirements are described, being transparent about gaps in their software against your requirements, etc… The bottom line is that if you’re finding that the vendor is just not listening or responding to questions well at this early RFP stage, it’s not likely they’ll be responsive to your needs going forward if they are chosen for implementation.
As a final task, you may need to write a business case to get approval for the selection and investment from senior management. Whether or not this is even required, the format, and level of detail vary greatly among organizations so you should find out what the expectations are before you even start discovery. The business case may be a simple form to complete from the Finance department, a short memo-style write-up about 1-2 pages long, and/or a full document containing an Executive Summary and sections for all the work done to date along with a meeting/presentation that includes the entire stakeholder team. In any case, all the previous documents created from all the steps above will easily feed into such a document.
Run a Pilot Test (Optional)
After your organization has made a selection, stakeholders may still want to do a demonstration/proof-of-concept to validate the choice, particularly if it’s a new technology for the group. Pilot testing should be at least 30 days but no more than 90 days. Any shorter will not allow enough time for a thorough evaluation. Any longer will make it hard to get business users to remain focused and for vendors to agree to terms up front. Vendors will also typically want to see a solid pilot test plan (use the content of the requirements document produced previously to create this), and pilot project schedule in advance so that criteria for success are defined and timeline is doable for both parties. Expect to pay the vendor for any professional services during this period (e.g. for software configuration, cloud environment setup for testing, etc..) but not for the software until the pilot testing is completed successfully and your organization is happy with the results.
The process above has really just skimmed the surface of the detailed tasks involved, how you work with stakeholders and vendors, and documents to produce but should help you get started. Have any questions or need help? Feel free to contact me.