How to produce a great deliverable
- Summary:
- In his last post, guest author Martijn Linssen railed against bad deliverables. So how do you produce a great one?
Introduction by Jon Reed: When we left off in part one, What makes a great deliverable, guest contributor Martijn Linssen was railing against the stagnant approach of modern IT and the obstacles to achieving a good project result. OK - but where do we go from here? In the concluding section, Martijn lays out his field-tested approach to a better deliverable. Then he delivers a final wake up call to enterprise IT.
Application lifecycle
When you focus on the product, you focus on its lifetime: I’ve heard people equate Agile to a one-night stand, delivering projects to prolonging that act until giving birth, whereas you’d want to raise a self-sustaining adult who can think for him- or herself. Yes, that takes time, and money. And planning, and vision. And paying continuous attention. But isn’t that what you ought to do in a meaningful relationship?
Robust product
So you start with designing a robust product. A solid product, that can take a few blows and setbacks and above all is not only able to handle (the then known) exceptions, but also to recuperate from them, and any exception in general: your product should be able to fail, fall and get up again all by itself in any and all circumstances. The self-sustaining adult, adolescent, or kid.
Business requirements don’t work because you’re not delivering a Business. You’re delivering a product, so you need product requirements. Key users can give you those because they know the product. They work with it. Their colleagues do. They get complaints, from customers or colleagues or partners or Lawd knows who. They have to handle the crap the products spits out or sometimes turns into. They live and breathe the product, they know what it needs to be good (enough)
That is the goal of your product, and you should start designing the skeleton around that: What-if? Is the question you should continually ask yourself and your key users at the beginning and end of every single process step of the process you’re solidifying into living code. You must include IT support at the very beginning of that, first heavily and increasingly lightly in later stages, just like you do with key users: what-if the transaction doesn’t obey by the initial rules we designed it for? Will that not harm the profit too much?
Transaction
The process transaction must be the single focus: if it breaks, does the user get a proper warning? Is that properly logged for IT support, easy to find across the enterprise apps it runs on? Is it uniquely identifiable, and does it contain equally easily traceable and unique identifiers for the service, platform, process and thread it was called from?
Do those break-downs fit into the current IT support ‘system’? Are you reusing existing exception handling procedures or are you making up entirely new ones? Guess what the difference in cost is, and how that cost will exponentially grow when the volume increases or the transaction stretches across enterprise apps- inside but most importantly outside your enterprise? Do you realize the obscene difference in cost between automated exception handling and human ones? Do you realize how absurdly high that cost gets when your broken product is exception-handled by the IT support system of your partners, and your partners’ partners?
The transaction needs to be considered across all automated and non-automated links of the chain. If it breaks at point h4, in case 1 it must be restarted after x happens. In case 2, it must be rolled back. In case 3, it must be aborted after y happens. In case 4, representing all other cases then yet unknown, we’ll have to figure out what we’re dealing with and maybe have to treat it as case 1, 2 or 3. Is that possible? Do we have the means? How quickly must that happen in each case? What will it cost? What will it profit?
Who cares?
So far, only a few. When you run your project, you’re driven by the project budget only. IT support cost is considered exactly that: a cost. If it gets too high, you make people work harder by firing a few, or you fire a few and hire back cheaper ones, which is even worse because those new people need to be taught their job by the left-over people, doing twice as much damage. Or, of course, you can outsource it all, doing the most damage you can do because there’s no incumbents left to teach the new IT support organization.
Likewise, you can decide to cut corners while delivering your project, and promise to make up for it later – which never happens because there’s nothing more permanent than a temporary IT solution, and new business requirements always win over fixing bad IT decisions because the budget comes from - exactly- the business. And the business generates profit whereas the IT organisation only costs money. Get it?
Crazy
Enterprises have gone crazy. Over the past decades, they’ve grown fat and lazy, lulled by their users who had no choice but to accept what was forced down their throats. Enterprises failed to recognize changing markets and the PC and mobile market which showed their users –as ordinary people- that things could be done differently.
ERPs and vendors have greatly profited from this opportunity and assisted the Business in building yet more imperfect products over time by delivering either insanely large-scale and long-time projects that automatically created a life-long lock-in, or delivering such fragmented pieces and releases of small projects (focus on the time-to-market folks, Quick Wins yay!) that sustaining and supporting them grew exponentially costly over time, creating the costly IT departments they now have.
Why? Because every single time, when the project stress increased and the golden triangle time-money-functionality rang, functionality got sacrificed either on the way in into the transaction (ease of use, choice of options, versatility, flexibility), or on the way out (catching and handling exceptions, tracing them back in due time, supporting fall-out). Workarounds were chosen over solutions, because there would always be another follow-up project to fix the flaws. And there indeed would be those, but they would bring more new business requirements than old fixes or existing support requirements. Bigger and better projects yes, but better products? Hardly ever.
Blame
And who do they blame? Like careless parents who failed their responsibility, obligations and day-to-day tasks, they blame their own kids for being a failure. Their kids are spoiled, were always trouble when young, hung around with bad friends, never wanted to listen and obey, et cetera: not realizing that acknowledging your kid is a failure is merely admitting that you failed at raising them properly.
First admit that, and then we’ll talk about how to fix it – but don’t deny it because denying your problems is guaranteeing that they are not going to be fixed anytime soon, and are highly likely to just continue increasing over time. Because they continue to be ignored, left unattended, and most importantly: considered to not be part of you. They’re just a problem, right – so what does that make you?
IT has been turned into a cost department – but cost doesn’t exist all by itself. Like Night, you can’t define it unless you define Day too. Like Dark and Light. So what’s the profit – are you? Do you really measure the costs of your project(s), write them all off in due time, and then measure the revenue it generates over time? Do you include all other costs and revenues, and then duly report the profits of your project? Do you even dare ask anyone whether you should?
Or do you just spend your children’s inheritance and then scold them for leaving you with no money and not supporting you in a cost-efficient manner? Let me please not guess...
What makes a great deliverable? For starters, not trying to make one. Think TCO, and stop ramming Business-budgeted projects down your users’ throats. Design and create a robust product, sustained and supported by your IT ecosystem(s), focused on your customers.
Remember:
Product over project.
Solution over workaround.
Product requirements over business requirements.
And every time you say "end customer", a puppy dies...