Focus on proofpoints rather than requirements

Requirements are too specific for a software selection process, and often result in a “yes” or “no” answer from the vendor. A proofpoint is rated on how well it delivers on a specific capability.

The objective in selecting software is to make an informed decision and have a shared understanding why certain solutions work for your organization. Every company has its own environment, and software tends to respond differently to each environment. To make this decision we require real proof, not the kind of proof that can be found on vendor’s sales and marketing presentations. Here is the reason to enter the concept “proofpoints”.

Proofpoints

Proofpoints focus on specific organization demands and are granular enough to be scored. They can be described as user stories, drafted by different stakeholders in the organization, in which the software vendors must prove their capabilities. Proofpoints follow a simple structure: Who wants What and Why? For example, the marketing department of an organization is in the market for a new email-marketing tool. A proof point, drafted by someone from the business could be: As a marketeer (Who), I want to be able to look at a preview of the email on multiple devices (What) because I work on-the-go (Why). In this example the vendor should proof which (mobile) device capabilities they have.

Proofpoints are no requirements

If we rewrite the proofpoint to a requirement it would state: The email-marketing tool is able to show a preview of the email on an iPad. In this example the vendor would merely show that their solution shows a preview of an email on an iPad. Requirements are too specific for a selection process, and often result in a “yes” or “no” answer from the vendor. A proofpoint is rated on how well it delivers on a specific capability. It also gives the vendor the room to demonstrate their capabilities and advise the organization on what is possible within those capabilities. Requirements limit this.

In a previous article we discussed the importance of alignment in software adoption. By merely looking at requirements, we make it harder to have a fruitful discussion, especially when scoring the vendors. If stakeholders use proofpoints, they will have to assess the vendor’s capabilities, which is not a simple “yes” or “no” discussion. In proofpoint discussions, possible contradicting needs from stakeholders are revealed and can be addressed, thereby enabling alignment.

In addition to ensuring internal alignment and working with proofpoints, we recommend to work with the vendor to build partially configured prototypes to be assessed, and to ensure it integrates well with the existing IT landscape, but also to use a company-wide standardized approach to the software selection process for clarity and honesty.

Contact us to learn more on how our Software Selection service offering can help you to focus on adopting the software to the organization at an early stage in the process.