Today: April 21, 2021 3:00 pm
A collection of Software and Cloud patterns with a focus on the Enterprise

Focus on Activities and Outcomes, not Procedures and Tools

An unfortunate digression in many technology selection efforts amounts to philosophical debates around tools and procedures. These debates revolve around tool selection, access controls, SLAs, ownership, responsibility, etc. What’s so bad about this? 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 any state or deliverable.

Presumably the state or deliverable is defined by the business and, if achieved, would contribute to achieving the strategic objectives for the company. Outcomes should often be tied to specific goals. 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

System A should have records that capture data B and processes to ensure that data B is replicated to downstream systems C and D.

As an outcome, this places focus on Systems rather than business activities (we’ll define activities better later). While it’s true that this is a state or deliverable, it doesn’t provide any clarity around what the business is actually trying to do. It should be obvious that the outcome above was prompted in some way by a business need for data B, but as it is written, the outcome is focused on Systems A, C and D, which may or may not satisfy business objectives.

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 think 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 specific information“. Leaving out the medium by which the request is made invites creativity and clarifies 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.

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

The unfortunate digression I mentioned earlier has to do with what motivates discussion of activities and outcomes when compared to what motivates discussion of procedures and tools. Proper discussion of activities and outcomes is motivated by a clear understanding of the differentiating factors unique to a business. Discussion of procedures and tools is motivated by business continuity and budget. Business continuity and budget are important considerations, but they are secondary.

Procedures should be measured against Activities

Imagine a really solid, well implemented procedure that ensures business continuity and even promotes efficiency and transparency. That sounds great doesn’t it? It is good, when the procedure is based on activities that lead to outcomes which align with business objectives. Othwerwise it doesn’t matter how great the procedures are.

Discussions about procedures often focus on pain points within the business, such as events that prevented a desired outcome or tarnished the brand image of a company. Procedural discussions also occur when coordinating access to resources, scheduling, and so on. 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 expend 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 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 social 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 later SaaS, has been so successful.

When it comes to specialized systems, such as market differentiating proprietary software, machine learning neural networks for market insight, management of expertise and limited resources, it’s best to start from a human perspective and get a clear picture of the activities and outcomes that will optimize business success.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.