Software Selections

 

Software selections can be overwhelming. With so many systems in the marketplace and the rapid pace of change in technology, it is sometimes hard to know where to begin. At Linder Consulting, we use a systematic and proven approach to bring objectivity and clarity to the decision making process.  We start with gathering requirements and process mapping to clearly define the organizations needs and priorities. We then guide clients through the entire procurement process, including RFP development, research and discovery of viable vendors, proposal evaluation, vendor demonstration planning and facilitation, scoring and analysis of results, vendor selection and contract negotiation. Each of these services can also be provided on an ad hoc basis.

Benefits of this approach include:

1. Ensures fairness and objectivity.
2. Facilitates a meaningful, apples-to-apples comparison among vendors.
3. Ensures the best product fit based on documented requirements, rather than individual preferences or bells and whistles.
4. Sets expectations early in the process and builds buy-in and ownership among the project team.
5. Provides transparency into the process.
6. Fulfills procurement guidelines and provides documentation for audits and open records requests.
7. Produces an understanding of the selected system’s strengths and weaknesses, as well as trade-offs between systems.
8. Strengthens the organization’s position during contract negotiation.
9. Increases the vendor’s understanding of the requirements and objectives for a successful implementation.
10. Gives the project team a jump-start on the design and implementation phases.

 

Requirements Definition

Linder Consulting uses a structured approach to gathering requirements that consists of the following:

• Conducting a series of interviews with the process owners and end users who execute the processes;
• Performing discovery and interviews with technical managers and staff to document the current hardware and infrastructure and define technical needs to support the new system;
• Population of an online tool with detailed requirements, priorities, requirement owners, complexity, impact, approval status and other data elements required to capture all the necessary information.
• Validation and approval of requirements and priorities with the appropriate stakeholder.

We use the SMART methodology as a guideline for requirements definition, meaning the requirements will be:

• Specific
• Measurable
• Achievable
• Realistic
• Traceable

 

Example of vague requirement: The system must support PEIMS reporting to TEA.

Example of SMART requirement: The system must allow for entry/capture of all data elements required to support PEIMS reporting to TEA. Appropriate data validation should be provided at the point of data entry for all PEIMS data elements (according to acceptable values per the PEIMS Data Standards). Output files needed for each submission should be readily produced without requiring export and manipulation of the data outside the application. Records requiring data from other systems should be produced in the format needed to create the complete record for the submission (example: 090 Records). If state requirements change in the future, the vendor must provide updates at least 3 months in advance of the initial submission (for each submission). The vendor should also be prepared to integrate with an online state system if the method for PEIMS submissions changes in the future.

The requirements development process includes the following:

The consulting team conducts interviews with key staff from each functional area to identify the information and functionality necessary to conduct daily operations. We document current capabilities and limitations; capture desired and required system capabilities; identify internal and external reporting requirements; and define security requirements. We attempt to gain an understanding of the drivers for reporting needs and interfaces to other systems so reports and integration can be streamlined to the extent possible on the new system. Interviews with high-level management focus on management information, reporting requirements, and policies while the interviews with staff will focus more on the actual processes of collecting and entering the data. During the interviews, we will also collect copies of forms, reports, procedures, documented requirements or regulations, and any other data that was not received as part of the data request.

As the interview and discovery process progresses, the consulting team will populate an online Requirements Tool with core requirements and recommendations for requirements. The Requirements Tool contains data points carefully crafted in support of the SMART methodology.  This will prevent the organization from including vague requirements in the RFP which do not facilitate a meaningful response from the vendor and do not allow the organization to hold the vendor accountable.

After each consultant has conducted an independent analysis, our team meets to review our findings and discuss any cross-functional requirements. Selected customer team members may be invited to participate in one or more work sessions at this stage to compare notes and provide input into the final requirements. The result will be a comprehensive set of vendor and system requirements, including operational, integration/interface, internal and external reporting, security and privacy and technical requirements.

 

Process Mapping

A software implementation presents an ideal opportunity for an organization to improve processes and leverage new functionality instead of perpetuating outdated processes with work-arounds and custom solutions. There is a strong tendency to try to replicate legacy systems when implementing a new system because users are often resistant to change and are sometimes unaware of better or different options. We discourage this practice through business process reengineering (BPR) and push clients to be innovative, yet practical, when developing new processes. The basic mechanics of BPR consists of mapping current processes by developing as-is flow charts, then converting the as-is maps into to-be process maps which illustrate how the organization will operate on the new system. By starting with the as-is maps, we ensure all stakeholders understand the current processes and avoid letting any details fall through the cracks when developing to-be processes. The as-is and to-be process maps will show:

• The actors and tasks involved;
• The order in which these tasks occur and any dependencies among tasks;
• Any decision points in the process;
• What systems are used;
• The inputs to and outputs of the process; and
• Any interactions among departments and other stakeholders.

Process mapping sessions typically have two to five participants and are conducted with the use of a laptop and projector so flowcharts can be created and edited using Microsoft Visio during the working session. This method allows the participants to see the results of the discussion immediately and give input in an interactive manner with the consultant and the other participants. At the end of each mapping session, there is a tangible product that can be distributed immediately to the participants for further review, discussion and refinement. Input from the review process is then incorporated into the flowcharts in preparation for a second mapping session called “as-is validation.” This is where the processes will be further refined, verified, and finalized.

Once the as-is maps have been validated and approved, we begin to evaluate opportunities for improvements. For each process that is a candidate for reengineering, we develop a recommended to-be process map then review and refine it with the appropriate client team members. If a to-be process involves new software, the to-be maps are developed in collaboration with the product vendor, then reviewed and approved by the client.

Below is a sample set of as-is and to-be process maps.

(click to enlarge)

(click to enlarge)

(click to enlarge)

(click to enlarge)

 

RFP Development

Based on requirements defined by the client or requirements documented by Linder Consulting on behalf of the client, we will develop a comprehensive RFP that adheres to the purchasing guidelines of the organization, while incorporating the substantive requirements that must be fulfilled. RFPs are structured to encourage vendor participation and to facilitate an effective review and balanced comparison of the proposals. RFPs are written to elicit consistently structured responses that can be easily understood and compared to one another.

RFPs also include requests for information on all aspects of the company, including questions to determine the long-term viability of the vendor, understand support and security models, confirm data ownership, and outline the implementation methodology. This allows the client to evaluate the entire offering, including many important success factors beyond the technical and functional software requirements.

 

Software Evaluation and Selection

Linder Consulting assists clients through the vendor selection stage by ensuring that a structured and thorough evaluation process is conducted and all the key stakeholders are engaged in the process. It is important that evaluation criteria are designed and weighted in a manner that encourages the desired outcome and reflects priorities for the project. It is also important to align the evaluation process with the size, scope and complexity of the project. As with any other decision-making, it is extremely important to establish the participants and ground rules in advance to facilitate a fair and informed selection. During the proposal evaluation process, Linder Consulting offers the following support:

 

• Evaluating vendor proposals and the degree to which they meet the stated requirements;
• Preparation of a comparison matrix to facilitate a meaningful comparison of systems;
• Providing recommendations for a short list of vendors to continue in the evaluation process;
• Performing reference checks for short-listed vendors;
• Development of structured demonstration scripts;
• Coordination of scripted vendor demonstrations; and
• Providing an evaluation report of findings with vendor rankings.

 

Contract Negotiation

Once a product selection has been made, Linder Consulting can provide assistance with contract negotiations with respect to scope, requirements, statement of work and project management/implementation services. We have experience in contract negotiations ranging from small, specialized systems to large-scale ERP and student information systems contracts from both the customer and the vendor perspective.

We start by developing a detailed statement of work in collaboration with the organization’s leadership, legal counsel, and vendor representatives.  The SOW is based on the requirements defined during the procurement process and it is organized by milestones and specific deliverables to allow for maximum clarity and accountability. It will also be structured in such a way that it can be used as the basis for the work breakdown structure and project schedule development.

Based on previous experience with these types of negotiations and software licensing and professional services contracts we will seek the most favorable terms possible for the organization, while balancing the need for realistic and achievable agreements for the vendor. Linder Consulting pursues every possible avenue to protect the client’s interests and strive for a statement of work and contract that clearly spell out the vendor and client responsibilities and obligations, and allows the organization to hold the vendor accountable for outcomes.