« Managing versus Measuring: IT's Value to Business Performance | Main | The ROI is dead; Long live the ROI »

July 22, 2005

Needs versus Requirements: the battle of Why versus How

There are many different enablers of higher performance in business, including capital, relationships, knowledge, position, tools and others. Of the more tangible ones amongst those various enablers, the alignment of tools (technologies) to the business still features the most vivid stories of uncertainty here in the post-dotcom period.

For most kinds of businesses, acquisition of technology has only one essentially distinctive purpose: to secure relatively uncontested on-demand access to the functionality of the technology, within the desired timeframe. Business interest in technology acquisition is not hard to understand at all, but the experience of acquisiton too often leads to buyer's remorse. What's worse, the same kind of failures occur year after year, as if we can't learn from the past. How do we get past this problem?

The marketplace offers truly great opportunity for technology access. But each of the key touchpoints in this access -- technologies, vendors, groups of users, and capital -- runs day-to-day on an agenda independent of the others.

Meanwhile, a company targeting technology access is running day-to-day on a mix of divers operations and users that generates many disparate demands, both planned and ad-hoc.

The result: supply and demand do not "self-organize" into well-matched sets. The connections have to be planned.

A technology access plan always navigates a path from the options provided at the access touchpoints to the necessities generated amongst the many company demands.

Normally, the path laid out will try to explain why the ultimate access to the targeted technology will be successful. But this level of concern is not the right place to start. Rather, the starting line is back where the "necessity" for the proposed access is being formulated and accepted.

Failure to clarify that formulation and its terms of acceptance will lead to technology implementations that fail to be adopted by the targeted users. Naturally, this adoption failure eliminates most of the basis on which productivity and ROI was predicated, while also ramping up sunk costs, contingency/recovery costs, and opportunity costs to fearsome levels.

The political fallout of the situation can be summed up as reactions to failed expectations of the implementation. For that reason, understanding the ideas about "necessity" that drove the implementation must involve the psychology of the expectations.

This explanation of "necessity" begins with the problem of identifying goals and assessing opportunities. Their combination is the basis of the behaviors that characterize the approach to the implementation.

These behaviors are mainly directed by beliefs, which are typically set forth as requirements and priorities.

Let's see how behaviors and beliefs interact to generate the perspective on "necessity":

This exposes the bases of how value is being attributed to whatever happens next. A key point to note here is that not all decision makers start at the same question in this matrix, and multiple stakeholders (different participating decision-makers) may not agree on the answer to any given question.

Such variety of perspective must be reconciled if the path to adoption is going to be successfully completed. Furthermore, it is important to not leave any of the matrix's four questions unanswered -- which partly explains why reconciliation will be challenging: no one gets let off the hook. To make the point even clearer, let's look at how this fundamental matrix translates into management-speak such as approval criteria:

Now it starts to emerge how so many business cases and other justifications produced may not logically account for adoption of the implementation even though they support approval to do it. The approval criteria (goals, capabilities, resources and effects) tend to test the current state of acceptance about specified conditions. This current acceptance is based on the interaction of factors that generate the "working versions" of reality and desire. (For example, consultants who provide assessments normally work in these terms, ofering a chance to validate or audit the presumed current state versus the "actual" current state, thus gauging a client's "readiness" and/or a tool's "compatibility".) By logically connecting the issues (clockwise within the matrix) from Goals (top left) to Effects, a comfort level is reached for approval, based on a story of "how this makes sense".

But the remaining problem, which is demonstrated by implementations that fail to be adopted, is the problem of "why" the implementation makes sense.

The key to exposing this is to understand that implementations work when they corespond to the behaviors that the company wants. And we know that behaviors are directed by beliefs, so the expectations of the implementation must correspond to beliefs. To represent this correspondence -- and get to the root of the "necessity" thought to exist -- the company must be willing to understand and agree on the terms of "why", which are more about the company itself and explain what the imlementation is actually supposed to address:

Again moving clockwise, from Motivations on around to Benefits, can the company confirm the logical links all the way around, and in particular, is the last link -- betwen the benefits and the motivation -- revealing something that can be attributed to the impact of the implemented technology?

The vocabulary of our last matrix challenges the specification of the implementation to describe enablement and support in terms of the company, but will reveal whether the company knows itself well enough to successfully adopt an implementation with reason to presume effectiveness. This is particularly critical in cases featuring multiple stakeholders, who hold the adoption cards rather than the approval cards.

Posted by Malcolm Ryder at July 22, 2005 8:13 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/82

Comments

Post a comment