Major systems implementations can have significant impacts on the success of an organization and its employees, vendors and customers. If done well, the project can improve transaction speed and accuracy, can elevate customer service, strengthen controls and add value. In part one of the series, we discussed the early phase of an implementation project up to initial Board approval to proceed with the project. Now, in Part 2, we will explore the critical procurement process for the system. Let me stress here that the good procurement practices detailed below will help you to make a conscious, educated decision on the system to acquire and if done well, will provide you with all the information needed to gain final approval to proceed with the project. We will review sourcing vendors, identifying requirements and building the RFP.
If you missed part 1, see the following link; Surviving a Major System Implementation, Part 1
General Points About Procurement
- NFP organizations seem to struggle with procurement, favoring business relationships and advice of peers to make purchasing decisions. This is a dangerous practice that can lead to high costs and low quality decisions. Invest the effort and you will see the value.
- Good procurement practices create a level playing field for vendors to present their solutions to your needs. These practices may seem a little strange at first, but this method will help you avoid issues later and get the best possible solution for your needs.
- You should endeavor to find the solution that best fits your needs, but avoid trying to alter your needs to fit the solution. You will find that no solution is a perfect fit, so prioritize your needs and make conscious decisions accordingly.
- The process provides information for decision making that is based on the facts collected. However, it is rarely easy to reach consensus, so prepare for decision making by having clear requirements and scoring processes.
- Do not rush through the process.
Initiating the Procurement Process
There are two ways to approach a procurement. One is where you have a solid general understanding of the system requirements. This generally occurs when you have a legacy system that performs tasks well, but is reach the limits of its capacity. The other is where you are looking for something considerably different, such as, when your current system is not working adequately or compliantly. In either case, the following processes will apply. Use the size of the project and its expected impact to determine how deeply you wish to follow the best practices presented.
Back in Part 1 of this series, we discussed establishing the initial justification for the system. An important step in that process was doing some research on what systems were available and the size, scope and rough order magnitude price. With that initial research, you can start step one of the procurement, which is finding sources and capabilities.
Step 1: Identifying Sources
In this step, you need to complete additional research on the vendors that provide systems that might meet your requirements. There are several ways to do this. You can try an internet search or you can read trade journals for your industry. Perhaps best of all, you can reach out to your network and find professionals in your profession or industry who can discuss the systems they use. Once you have a list of potential sources, you will need to determine if they generally meet your needs.
Do not only engage your current vendor or someone you know from a conference. Building a good pool of sources will ensure you have creative solutions and a strong competition.
As this is still very early in the process, you have not yet gathered your needs document, so you are searching for information. Reach out to the organizations on your list, Ask if they will come in and have preliminary discussions or if they have some online demonstrations that can provide some idea of their systems’ capabilities.
Industry Day
If your organization is larger, you can invite the potential vendors into what is known as an “industry day.” This is when a group of firms come to your organization to discuss the general capabilities of their service offerings. Good vendors in your space want to get in on the ground floor of the procurement because it provides them with the best data available about your needs. Early on, tell them the general size and scope of the project, your goals and a timeframe.
As you go through the process of identifying sources, you are trying to build a list of between eight and ten reputable sources to move through the rest of the procurement process with. It is very useful to manage vendor expectations, by discussing your procurement process with prospective vendors early on. This will help avoid calls from vendors at the end of the quarter with “special discount pricing,” as they attempt to meet their sales quotas. Who am I kidding, they will call anyway. So, use the call as an opportunity to get some pricing information from the vendor.
Some questions to be asking in the Identifying Sources Step
- Is my organization in one of the vendor’s primary target sales segments?
- Does the vendor have customers I recognize that are similar in size/scope to my organization?
- Are the vendor’s customers much larger or much smaller than my organization?
- Does the vendor speak my industry’s language?
- Any unpleasant news about the Company or its products or services online?
- Are there any employees within my organization who have experience with the vendor?
Step 2: Defining Requirements
Once you have a pool of potential vendors, the really hard part begins and that is defining requirements. This is one of the most complicated and crucial steps in a major systems project. Identify the expected scope of the project and detail all the specific requirements (what the system must do) for each component of the project and prioritize the requirements. Do this not only within each component of the project, but across all the components. Remember, you are not going to find a perfect match for all your requirements. You will select the system that best fits the project’s highest priority needs.
This step requires focus and precision. While missing a major requirement is almost assured, don’t miss too many, else you will decrease the quality of the procurement. You will need to assemble a team including leaders and staff from all organizations impacted by the proposed system, including IT, if they are not leading the project. The team will be responsible for compiling and prioritizing the requirements.
There are two types of requirements, first defines what the system is to do and the second deals with how the system does it. For example, a requirement may be that the system need to be able to capture employee benefit information which is what the system is to do. However, there is a desire that the employees can enter the data themselves, which is how the system does it. These are two different requirements, so capture them either separately or as a consolidated requirement.
Defining the Requirements Suggestions
- Identify major business systems processes, such as; billing, payroll, AP, HR, revenue recognition, recruiting, program management, etc.
- Detail the major sub-processes. For example, How many different types of invoices are needed? What are the components in the company’s benefits program and how are they administered?
- Note any associated regulatory requirements (these are baseline, if a vendor’s solution cannot comply with these requirements, it will be a tough sell to pick that solution)
- Identify all interfaces of data between parts of the current legacy system
- Identify all interfaces with systems outside of the scope of the planned system
- Don’t forget to include requirements associated with data security, backups, disaster recovery
- Include a request that the vendor propose estimated implementation costs and timeframe
Step 3: Preparing the Request for Proposal (RFP), the Procurement Product
Consolidate all of the requirements into a master document. This will become the Request for Proposal or RFP. As you can imagine, this is going to be a significant document with numerous requirements across all the components of the system.
Building the RFP is straightforward as you have already done the hard work in defining the requirements. The RFP may have several parts, but most include the following;
- Introduction – I high level explanation of the project including objectives, scope, expected timeframe. Also, a high-level overview of the organization, its mission, trajectory, culture, etc.
- Project success factors – these are the highest priority requirements at a summary level. This helps the vendors focus their efforts to areas that are most important to the organization
- Detailed requirements – compiled requirements discussed previously. Prioritize the list within each function or component and position items with higher priority first. Include detailed narratives if there are any organization or industry-specific requirements that may be unclear
- Demographic data – you need to provide information that the vendor will need to assess the expected transaction volume. Vendors often have products or service levels at multiple capacities. In this section include items, such as; headcount, # of customers, # of vendors, # of transactions for each business process, # of GL accounts, # of companies or entities and any other information that will help the vendor fit their proposal to your needs
- Reference account form – identify the information you would like to receive on the accounts they are providing as references. This can include size of the organization, how long they have been a customer, a brief description of their implementation scope.
- System information – any system requirements associated with the solution. In this section, discuss the capacity and general configuration of the organization’s network and any requirements, such as single-sign-on capabilities or distributed access/processing. Include any items that the vendor needs to address in their proposal
- Financial information request – define any information the organization needs to access the vendor, such as audited financial statements or if a service provider, system/process/controls audits
- Request for implementation proposal with timeline – this is a rough order of magnitude project plan for the implementation, including resources provided by the vendor or needed to be procured by the organization, as well as, an expected range of implementation timelines
- Proposal instructions – the method of submission, style (checklists for requirements with narratives are common), due dates, page limits (yes this is rough but necessary)
- Question submission process and due dates – this is important. Best practice is to share all questions received with all vendors. Tell vendors that you intend to do this as some vendors will balk. However, it is the very best way to ensure a fair and open competition. Typically, questions are due one to two weeks after the proposal is released. Questions need to be answered quickly, within one week. Proposals should be due one to two weeks after all questions are answered.
Compile the RFP and review it with the project lead and/or steering committee for clarity and consistency.
The RFP is provided to the vendors identified during the vendor sourcing process.
Wrap Up and What’s Next
Finding vendors, identifying requirements and building the RFP are the foundations for a successful procurement. If this article suggests that it’s a lot of work, then I have been successful in communicating reality. This work will pay off in several ways. It should provide you with a solid case for gaining final approval of the project. In addition, clear requirements and prioritization will make the implementation planning and execution easier, since all parties should be on the same page.
Part 3 in this series will cover the selection process, including; assembling a selection committee, more on RFP and proposal questions, scoring the proposals, vendor presentations, the selection and communication. Still to come in future parts; implementation planning, execution, follow-through, communications and change management.
Make learning a shared experience. Please share your thoughts on this topic in the comments section.
If this article has been valuable for you, please check out the rest of my blog, Not for Profit Beyond the Numbers – click the following link. NFPBeyondtheNumbers
Thanks! –mike
