Vendor and tool selection is often a complicated process for an enterprise. In the worst cases, the evaluation of tools, vendors and other technology solutions turns into a debate about tools, features and procedures. Why is this a problem? It’s that these debates too often fail to identify and measure against the outcomes that will benefit the business and the activities that will produce those outcomes.

What is an Outcome

An outcome is simply an end state or deliverable.

The end state or deliverable is usually defined by the business and, if achieved, would contribute to achieving the strategic objectives for the company. Outcomes should be tied to specific goals or KPIs. By it’s very nature, an outcome should be agnostic of any tool or procedure. Here are a couple of examples to illustrate.

Poorly Defined Outcome

Imagine the following outcome defined in terms of systems and movement of data. System A has records that capture data B and processes to ensure that data B is replicated to downstream systems C and D.

This does define an outcome, but it focuses on Systems rather than business activities (we’ll talk more about activities below). While it’s true that this is an end state or deliverable, it doesn’t provide any clarity around what the business is actually trying to accomplish. It seems obvious that the outcome above was prompted in some way by a business need related to “Data B”, but as it is written, the outcome is focused on Systems A, C and D, which it is assumed align with current business objectives. Unfortunately, the defined outcome doesn’t give any visibility to what those business objectives are.

Well Defined Outcome

Department A needs data B available for all records related to entity C. Data B may also be useful to other departments and so should be available by request. Data B should be considered internal and confidential.

This outcome clearly focuses on data B and provides information about which department(s) need it and how it relates to other data. It also provides some guidance about data sensitivity and scope.

What is an Activity

An activity is any unit of contribution that leads to achieving an outcome.

When designing systems and formulating outcomes, I prefer to start by thinking of all activities as exclusively executed by humans. In other words, ignoring any technology or tools, how would a human produce the desired outcome. For example, rather than say “an onboarding representative should email, call or fax the client to request specific information“, simply say “an onboarding rep should request/obtain specific information“. Leaving out the medium by which the request is made, “email, call or fax” in this case, invites creativity and focuses on business outcomes. This is similar to why I suggest always designing software on paper first.

Just imagine an activity description that includes email as the channel by which something is communicated. This is more likely to result in an outcome description that includes an email system and potentially obscures the actual purpose of the communication in the first place. Remember, the business doesn’t want an email system, they want to communicate something. The business activity is communication, not email. As new forms of communication become available, the defined activities should easily accommodate those rather than codify the way things were done in the past.

Activities lead to Outcomes

Very few businesses actually deal in systems and find direct benefit from system (or vendor) selection. Conversely, most businesses differentiate based on specialized information, expertise and access to limited resources.

When activities and outcomes amplify and streamline a company’s differentiating factors, a business will generally thrive.

Procedures and Tools are Secondary

Discussion of business activities and outcomes should be motivated by a clear understanding of the differentiating factors unique to a business. On the other hand, discussion of procedures and tools is motivated by business continuity and budget. Business continuity and budget are important considerations, but they are secondary. Procedures and tools only matter if the business is executing the right activities and achieving meaningful outcomes.

Procedures should be measured against Activities

When a procedure is based on activities that lead to outcomes which align with business objectives, businesses win. Often procedures start with a focus on activities, but they take on a life of their own. Processes are often documented in operations manuals and expressed in systems, which over time can obscure the focus on the desired business outcome that motivated them. As processes age, the attention drifts toward pain points within the process and system, such as downtime or security breaches. Scale, speed, access control, maintenance, training, etc. all begin to take attention. These conversations are necessary, and can be helpful, but only in the context of the activities they support. These discussions begin to run counter to the benefit they intend to produce when compared exclusively to past procedures. Comparing new procedures to old procedures may feel like a step forward, but without measuring the new procedure against the activities it is meant to support, there is great risk of drift.

Tools should be selected based on alignment with Outcomes and Activities

In a similar way, tools discussions often focus on vectors such as cost, implementation, maintenance, accommodation of existing procedures, etc. Tool vendors invest a great deal of effort showing how they stack up against competing tools along these same vectors. Who wouldn’t feel great about getting a “superior tool”, with more features and at a lower cost point? The problem is that these vectors alone fail to account for business differentiators. This is why tools selection must measure against well defined activities and outcomes before any of the typical vectors are considered.

A premature focus on tools has the result of shaping business outcomes that are tied to a specific tool. Starting with a clear focus on activities and outcomes actually increases the likelihood of innovation over starting with a tool focus. Referring back to my start on paper article, the predefined capabilities of a tool actually project activities and outcomes on to the business. It should be the business activities and outcomes that project on to the tool in order to qualify it as a fit. Rather than ask “how can our business use this?” we want to say “how can the tool accommodate this specific, business aligned activity?”

Inspiration and SaaS

Some might argue that exploration of the features and structure of tools, vendors, etc. can inspire new visions of activities and outcomes in a business. I don’t disagree, and there may be some industries or business functions where that is more true than others. In cases where a business function has been normalized by convention or outside regulation, there may not exist much flexibility to define activities or outcomes in any way other than that convention or regulation. In those cases, the typical vectors for tool selection and procedural discussions about business continuity and budget may be sufficient. That is one of the reasons that off the shelf software, and SaaS, have been so successful.

When it comes to specialized systems, such as market differentiating proprietary software, Machine Learning models for market insight, management of expertise and limited resources, etc., it’s best to start from a human perspective and get a clear picture of the activities and outcomes that will maximize the potential for business success.