Aiming at the Right Target

The danger with this sort of thing is focussing on that which at first blush appears to be important, but that in the bigger scheme of things isn't important. Some background: we're embarking on a journey of identifying a partner who produces a product on-which we will run our business. The inevitable problem that many non-technology focussed organisations encounter is:

1. Technology is necessary in order to remain competitive;
2. However, getting technology, and especially systems development right is particularly hard;
3. We don't want to be fussed with technology because it's: a) Expensive; b) Complicated; c) Foreign; d) Risky.
4. So ... let's make it somebody else's problem (read: outsource).

I've now observed this pattern arising more than once:

MD of Business Unit:

We provide X financial service, that's our bread and butter, we're not a technology company, so we need to outsource this technology stuff and get on with our core business.

Value Delivery Consultant:

Your job is to deliver value to your customer, quickly and consistently and consistently quickly. When you understand that, you'll understand that what's important is the flow of value to the customer, and not what you perceive your business to be (financial services as opposed to technology).

Whether you think your business is taxi's, accommodation or insurance, ultimately if you want to remain relevant, you're going to need to elevate your thinking to the point where you realise that your business is in actuality: "providing value to an individual or organisation" , and the best way to achieve that end is to shed any preconceptions about how technology should be treated in relation to your perceived "core business". Technology is here to stay and is destined only to become more entrenched in our day-to-day lives; treating it like a red-headed cousin simply because it seems not to be "core business", ironically, no longer makes business sense.

But we Don't do Systems Development!

As a business owner if you've decided to outsource the development and maintenance of your core admin system (hopefully after a commensurate amount of soul-searching) and there is little anybody can do to convince you otherwise, then how do you do the best for yourself and your team in choosing the right partner?

The answer lies in what I believe to be the two-part fundamental tenet of doing business effectively:

1. Consistent, effective delivery of value to the customer;
2. Consistent improvement of 1.

It's important to understand that the "engine" that delivers value to the customer consists of many moving parts, the collective of-which will only ever be as effective as the level of inter-component sympathy. The crux: in order for effective delivery of value or flow of value, all parts of the business must be working in harmony.

So ... to measure how effective we would be as a business working with an administration system partner, we would do ourselves a gross disservice if we didn't recognize that probably the most impactful consideration is the degree of flow of value achievable with such a partnership in place.

What are not Good Indicators of an Effective Partnership?

Sadly, the natural course of events is to determine a winner based on features:

Bob's ice-cream machine has the ability to use sugar-frost cones as well as ordinary ones.

Sally's ice-cream machine can text you when it's getting low on soft-serve.

Looking at features isn't completely without merit, at the very least it'll give us an indication of various quality factors around a potential partner, things like ability to think out of the box or ability to produce and maintain complex solutions. It also provides insight into how good-a-fit they are for us (their choice of features gives us an idea of what they deem valuable and lets us know whether or not their outlook is compatible with ours).

Features have merit, but they're not what is most important when choosing a partner who will have a fundamental impact on our effectiveness to do business.

Another tempting route is to observe how they work, probably because, not unlike features, doing so can be done relatively easily by establishing a baseline of metrics and running a Proof-of-Concept. The fundamental problem with this is that we've neglected to take into consideration what I've tried to highlight further up:

What's important isn't so much how well we think a prospective partner works, but how well we work with our partner.

The "we think" part in the above statement is important because it highlights a common mistake that organisations tend to make when doing assessments of this nature: assuming that a set of metrics established "by committee" accurately describes what's important in the delivery of value. The only way we can know the truth in respect of the latter is by doing as we would be in our day-to-day jobs.

In fairness, the reason why we mostly choose the feature analysis route, or the work-method inspection route is that it's just a whole lot more comfortable than the most effective way of knowing the truth: getting down-and-dirty and conducting a small end-to-end value delivery experiment with our prospective partner.

The Effective Route to Revelation

It's funny how so many things boil down to a fundamental truth:

If you want the best outcome, as uncomfortable as it may be to do, stop kidding yourself.

To find the best option in respect of a partner who will be responsible for the technology undergirding your business, do small collaboration experiments with them, designed to surface the degree to-which you are able to deliver value to the customer.

I'm not advocating doing something so "radical" in lieu of feature or process metrics, but let's not kid ourselves: the latter is subordinate to the former and should be treated as such when doing an assessment such as this.