Optimize Software Evaluation and Selection Decisions

"​We collectively, to get things done, work together as a team. Because the work really happens horizontally in our company, not vertically. Products are horizontal. It takes hardware plus software plus services to make a killer product."

Tim Cook, CEO of Apple

Vendor Software Investment is More than About Software

Selecting software is more than just about the software and hardware. A vendor's service depth and breadth to support and enhance your needs long-term are just as important. 

While two guys in a garage may be helpful when innovating to create a new industry or product, they are not the right choice when selecting critical software to run your business.

Vendor stability, capabilities, and market positioning are vital when choosing a software solution.

Decide on a vendor solution that includes:

I've engaged in 200+ RFP projects. Two primary observations include:

  • If you don't need to go through an RFP process, don't. For example, if one of your existing vendor partners already offers a solution you're seeking, then work with that vendor to assess whether their solution fits your needs.
  • If you decide to proceed with an RFP, do so with caution and preparation to avoid a time-consuming effort that results in a sub-optimal decision.

Evaluate Vendor Software

A software package, aka Commercial Off-the-Shelf Software or COTS, is a ready-made computer program or collection of related programs developed by a software vendor.

Establish Evaluation Goals

Tens of thousands of high-quality commercial software packages and services are available today.

A sound business process is critical to optimize your vendor partner decision regardless of the selection approach.

Consider buying, rather than custom developing, software for the following reasons:

Differentiating Capabilities

Capabilities that differentiate your organization in the marketplace may require custom software.

  • A vendor's ability to meet and continue to enhance your differentiating needs may not be sufficient and efficient.
  • Those differentiating capabilities likely enable your organization to realize competitive marketplace advantages. Be wary of sharing competitive secrets with external suppliers who may share and develop your differentiating ideas with others. Ensure strong confidentiality terms exist in your agreement.
Miscommunications

Maintain awareness of the communication challenges between your organization and potential software vendors. Your organization doesn't understand how a vendor software system works, and the vendor doesn't understand how your business works. That's a significant gap to overcome.

Communicating via a Request for Proposal (RFP) with your procurement department as the intermediary further impedes communication quality and understanding.

  • Many vendors will respond "Yes" to every requirement you specify in an RFP, knowing they don't completely understand your needs.
  • Many organizations accept vendors' "Yes" responses without further questions or assessments.

During implementation, the realization surfaces that the software vendor selected can't support your essential needs, ultimately dooming or diminishing a successful business outcome.

Overpaying

Sometimes, organizations request too many desirable requirements, buying and paying for more than they need.

Focus your requirements on the vital few that enable your business case.

Comflexity™

No, that isn't a misspelling. It represents when too much flexibility creates complexity.

Commercially available software is architected with powerful configuration capabilities.

  • Those capabilities provide many choices for configuring how the software works.
  • Organizations without well-designed, thought-through business processes and requirements often get stuck trying to decide how best to configure the software, which can be time-consuming and expensive.
  • Tightly integrated enterprise software, such as Enterprise Resource Planning (ERP), together with weak business process discipline, results in configuration decisions unexpectedly impacting other parts of the organization.
Lack of Business Process Awareness

Buying application software is essentially buying a business process. Don't buy if you're not willing to commit to the business process and associated integration you're buying.

  • Far too many organizations buy software and then heavily customize it to meet their current business process needs.
  • Many of those needs fall into the category of "this is how we've always done it" thinking.
  • Those organizations incur high costs to customize the software to fit their existing business process. They substantially diminish their ability to stay current with vendors' new software versions and releases based on the extent of their customizations.
Transactional Thinking

Buying, implementing, and sustaining software is a significant and strategic organizational investment. Establish a strong partnership with your software vendor.

Adopt partnerial thinking to:

  • Improve the frequency and quality of communication.
  • Focus the relationship on strategic matters of importance to both parties.
  • Accelerate outcomes by decreasing relationship friction.
Venturing Too Far from a Vendor Solution's Standard Use Cases

A vendor may promote using its software to satisfy a use case for which it wasn't explicitly developed. They will emphasize the "commonalities" and the "minor" changes required to enable the solution to satisfy your needs. Please don't believe it!

  • Moving too far from vendor standard use cases creates unnecessary short and long-term risks.
  • Vendor changes to those use cases may break or constrain your organization's capabilities.
  • Vendors strive to support their customers with standard yet configurable use cases. Customers who have "shoe-horned" a vendor's solution to fit their needs will maintain a customized, expensive solution.
Bias

People bring all sorts of biases to the decision-making table. Prior experiences, favoritism, personalities, etc., can enter a decision process.

Minimize bias by establishing a rigorous and quantitative scoring methodology. Score and quantify vendor proposals and solutions to the extent possible.

Source your core evaluation team with objective and independent-thinking people.

Don't consider vendor software a solution if you're unwilling to entertain changing your business processes.

Viable vendor software solutions are highly configurable to meet most business process needs. However, you must be flexible and open-minded to change your business process to leverage vendor software solutions.

Is Your Organization Ready?

Vendor decisions are about more than selecting a vendor.

Is your organization prepared to extract optimum value from a vendor relationship?

It's more than just about vendor capabilities. Does your organization have the requisite abilities to leverage what the vendor brings to the table?

That question leads to Capability Thinking®. At a minimum, your organization needs requisite skills, methods, and experience in the following areas to leverage the vendor relationship fully:

A vendor I'm familiar with uses the tagline "Complex things can be so easy ...."

That tagline also applies to the RFP process. Organizations make it more complicated by attempting to communicate using only paper and their Procurement team. Simplify the process by directly interacting, talking, and listening to each vendor: document crucial discussions, expectations, conclusions, and decisions.

Think Before Acting

Take inventory of your organization's current solution assets and partner relationships. Many organizations initiate a vendor selection process prematurely before considering other options.

Take stock of existing partner relationships first before considering new partner options in the following sequence:

  1. Leverage a solution that is available through an existing partner.
  2. Seek viable options from new partners.
  3. Co-develop a solution with an existing partner.
  4. If one, two, or three are not feasible, create a custom solution internally.

Software Evaluation Approaches and Related Considerations

Two different approaches for evaluating and selecting application software are:

Enhanced Request for Proposal

The following grid provides an overview of an enhanced RFP approach for evaluating and selecting vendor software.

Enhanced Software Selection Journey

1. Initiate

Engage with all constituents, organize clearly, and establish a rational, fair evaluation process.

Deliverable: Charter, aka Mission

2. Define Requirements

Application requirements are important, but other requirements, such as vendor stability, application management and support, reporting, and analytics, are just as important.

Deliverable: Requirements

3. Create RFP

Create and publish RFP. Include questionnaires for technology standards, vendor profiles, user census, requirements, and costs.

Deliverable: RFP

4. Evaluate RFP

Quantitatively score as much as possible. Proceed to interviews and software demos with the top-scoring vendors.

Deliverable: RFP Evaluation Scores

5. Conduct Interviews

Vendors with the highest RFP solicitation scores can present their solutions and demo their software.

Deliverable: Interview and Demo Scores

6. Conduct References

Contact vendor customer references. Gather their perspectives on vendor performance and solution capabilities.

Deliverable: Reference Call Notes

7. Conduct Visits

Schedule HQ visits with the highest-scoring vendors through the RFP and interview/demo stages. Meet with vendor senior leaders and tour their facilities, including data centers.

Deliverable: Site Visit Scores

8. Select Vendor

Recommend the vendor having the highest cumulative score through all evaluation stages.

Deliverable: Vendor Recommendation

Critical call outs include:

Think Twice Before Creating a Request for Proposal

Avoid creating an RFP when possible. RFPs sap an organization's scarce resources and provide, at best, a marginal return.

Time is the scarcest of organizational resources. It can't be replenished.

Organizations prepare Request for Proposals (RFP) solicitations primarily for three reasons:

  1. As a mechanism to formally communicate their needs to vendors.
  2. To gather information and knowledge on potential vendors and their solutions.
  3. To use the completed solicitations received from vendors as a basis for their acquisition decision.

The RFP Paradox

Here's the paradox.

Organizations with overly bureaucratic procurement policies that restrict discussion, communication, and discovery between business users and vendors during the RFP process further constrain knowledge flow.

So, considering the time and effort most RFPs require, where's the value? It's expensive, time-consuming, and results in less-than-optimal decisions.

Enhanced RFP Approach

Use an enhanced RFP approach to increase the effectiveness of your vendor evaluation and selection process.

Learn more about the enhanced RFP approach.

JITDE™ Approach

Learn more about the JITDE™ approach.

Compare and Contrast Software Evaluation Approaches

Enhanced RFP Modern JITDE™
Critical deliverables include RFP, Demos, Site Visits, Score Sheets, and Recommendation Business Outcomes, Vital Needs, Partner Experience Checklist, Recommendation, and Contract
Many vendors Up to three vendors
Share equally with all vendors throughout the RFP response to maintain a level playing field Share equally at the beginning and allow vendors to differentiate themselves
Linear process to completion Nonlinear: Concurrent and interactive process
Eight-month+ plus duration, including contract negotiation Three-month duration
Paper-based process Interactive dialogue, experience-based
Emphasis on scoring Emphasis on partner dialogue experience and scoring
Sales-focused Business outcome-focused
Software-oriented Capability-oriented
Many trivial needs Vital few and differentiating needs
Rigid change culture Flexible and adaptive culture
Inside-out thinking Outside-in; Inside-out thinking
Procurement-driven Business-driven
Enables obfuscation Enables clarity
Back-end loaded dialogue Front-end loaded dialogue

Comparative Software Evaluation Map

The map below highlights the critical steps in each approach.

Legend: Blue denotes common steps in both approaches; Gray denotes RFP-specific steps; Teal denotes JITDE™-specific steps.