The Business of IT – Customers, Clients, and Fit for Purpose

Over the past few months, I have touched on a variety of what might seem to be disparate topics: the need for architects (or at least architectural design), estimates, organizations as systems/enterprise architecture, customer-centricity, and IT management and governance. I suspect the trend will continue for a while, so it’s time for a post to explicitly tie things together.

The concept of “organizations as systems” is the cornerstone. Software systems do not exist in isolation, but within a fractal set of contexts, each of which are systems themselves. These systems serve as the ecosystem for those they contain and will ultimately end in one or more social systems. Understanding the ecosystem is critical to ensuring that its component systems are fit for purpose, otherwise we risk trying to introduce fish into a desert.

The social system context is, in my opinion, key. Information technology delivery can take place in a wide variety of ways, but a useful high-level differentiation is that between delivery of an off-the-shelf product versus delivery of a service. Is the customer a client?

These two sentences, left alone, could be a source of confusion. Precision isn’t one of the English language’s strong points. Not all products are off-the-shelf, sometimes the service we deliver is the creation of a bespoke product (ultimately, the end user is concerned with the product that they will use, not the project by which we created it). Likewise, in my opinion, clients are customers, just not all customers are clients. In my career, I’ve exclusively dealt with client customers, so I tend to use the two terms interchangeably. That becomes a problem when we have a client that isn’t being treated like a client. Seth Godin’s recent post explained the difference nicely:

The customer buys (or doesn’t buy) what you make.

The client asks you to make something.

The customer has the power to choose, but the client has the power to define, insist and spec.

There is a large number of potential customers, and you make for them before you know precisely who they are.

There are just a relative handful of clients, though, and your work happens after you find them.

If a customer doesn’t like what’s on offer, she can come back tomorrow. If the client doesn’t like what you deliver, she might leave forever.

When a vendor fails to treat its customers as clients, they risk losing the client. When an in-house IT organization treats fails to treat its captive customers as clients, the result is “Shadow IT”. When that result is complained about, it betrays a shocking lack of awareness on the part of the complainer.

A client will have a hierarchy of concerns in relation to IT. The client’s main interest is the job that they’re doing (or will be doing) with a product. Their concern with the product will be shaped by that, as will their concern with the process by which the product is delivered. We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.

Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.

Just as the infrastructure environment can influence design decisions, so can the social environment. While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong. We wouldn’t try to force a square peg in a round hole and we shouldn’t try to force ill-fitting solutions on those who depend on our work. Products generally work best when they’re designed to be used in the way they’re used. The same holds true for services.

[Recursive Matrena 01 image by Vahram_Mekhitarian via Wikimedia Commons]

Updated 4/8/2016 to fix a broken link.