What makes a great deliverable?

Profile picture for user martijn_linssen By Martijn Linssen May 6, 2014
Summary:
Without a great deliverable, there is no such thing as a great consultant. But what is a great deliverable? Guest author Martijn Linssen explains.

Introduction by Jon Reed: my diginomica piece on What makes a great enterprise consultant got in Martijn Linssen's craw. Martijn agreed to share his rejoinder with diginomica readers in this special two part guest post. Martijn's beef? Without a great deliverable, there is no such thing as a great consultant.

For those who haven't run into Martijn before or read his prior missives (I'm partial to his Klout deconstructions), Martijn is a Netherlands-based independent consultant, with hardcore expertise in enterprise integration. In part one of his diginomica exclusive, Martijn calls out enterprise IT for failing business users, and explains why exceptions continue to flummox valiant (or sometimes not so valiant) attempts at great consulting outcomes.

What makes a great deliverable?

That’s a good question, yet one you can’t answer unless you provide an answer to the real question: what is a great deliverable?

The word deliverable inclines towards delivering something, so there are two aspects here: the one of delivery, and the one of the delivered: the product itself. In enterprise IT, the focus has indeed shifted from the actual product towards delivering it.

Over the past decades, improvements have been tried and tested towards 'better IT': software development methodologies such as DSDM, XP, Agile and so on, project delivery methodologies such as Prince II - those all focus on either building the product or delivering it, not on the product itself.

And therein lies the problem. Project over product is bad – no one gives a rat’s ass about a project, because people buy products. Same for software development: no matter how great it may be that you can do it so fast, there’s not a customer in the world who cares.

Customers care about products. They value product over project, and solution over workaround. Customers want a flawless, intuitive product and great after sales whence it breaks down, either during the purchase or after.

Users over customers

There’s a great shift going on in enterprise IT. Since the year 2000 or so, colleagues (from the Business) got falsely labelled customers (by IT). There’s now a ridiculous back-bending struggle going on to find a new name for the real customers – called 'end customers'.

The divorce between Business and IT (thank you not, McKinsey) has resulted in a decade+ long delay on making better products, and has bred an entire generation of users who have far too much patience, forced upon them by crappy products that error out and crash on a daily basis. The real customer? He or she leaves after maybe the first, but certainly the second time their product behaves as not expected.

What makes a great enterprise consultant? Consulting has almost become a dirty word in the enterprise. Companies have grown wary of consulting…In truth, enterprise IT has always dictated what their users (ought to) wish and now struggles hard to even try to find out what customers want. Bred fat over decades, they missed the starting gun, and having missed the chance to grow along the changing market(s), have no other fate than forced change – and that hurts.

And the question 'what makes a great deliverable' is so very much indicative of the corrupted client-focus persistent in enterprise IT these days. And yet, we’re going to address that question right here.

Product over project

Everything has a beginning, a now, and an end. A product is preceded by pre-sales (marketing, advertising), and succeeded by after-sales (support, follow-up, cross-sales). A project usually only focuses on the product itself, and its goal is delivery.

That delivery is constrained by time, money and functionality. I myself have always managed to deliver on time, because I sacrificed functionality for the greater good of time and budget, and that’s how it usually is done; ‘incentivation’ just works exactly that way. This makes a bad product – but not in the eyes of the project manager, because he delivered on time within budget, and managed to convince the stakeholders that ‘this’ was the best outcome.

And in the light of enterprise IT and vendor/system integrator lock-in, there’s hardly anything ‘greater’ than managing your follow-up project by delivering a sloppy product that needs enhancements - thus prolonging your T&M life, strengthening your client company network, and in short, building your career.

Why business requirements still fail, even with Agile

The input for a project is business requirements, and those are usually formulated by the Business. That is a good starting point, but usually that same Business department has a great conceptual view of what they want, and can present their views very well, but they lack the depth needed for detailed requirements.

For those, you need key users who live in and dream about that very same product the proverbial 24/7. And I’ve seen even the most senior key users struggle at the crossroads of process steps when exceptions to exceptions arose.

Some processes just turn out to be extremely complex once you study them closely, and that is phrased by me in ‘measuring the coastline’: when you look at The Netherlands from space, you can calculate our coast line at e.g. 450 kilometres.

When you get closer, you’ll see that a coast line is not just a straight line, but meanders like a (co)sinus; that one mile straight line (viewed from outer space) turns out to be a mile-and-a-half because some of the coastline pushes out into the ocean, and some of it pulls back on the land

In plain English: the real task to accomplish usually is 25-50% greater than sugguestimated (although carefully measured) at first. The business requirements so carefully drawn out focused mostly on rules, and much less on exceptions. Now those exceptions appear to be far more numerous than expected, and there goes the time-money-functionality paradigm. And the project again fails to deliver the desired product, which is solved by... a follow-up project. Get it?

In part two, Martijn applies his views to the application lifecyle - and what the heck to do when the transactional process breaks down. No buzzwords will be spared.

Image credits: delivery man © tiero - Fotolia.com. Photos provided by Martijn Linssen.