and now, the rather rare occurrence of “Chuck talks a bit about work-y business sorts of things”…

One of the things I find myself doing in my career is writing business case documents and presenting them to various authorities in order to sell them on the idea of taking on (and allocating funding to) various information technology projects.

The business cases we write here are required to adhere to a particular pre-established format. This format, I imagine, was originally conceived by some MBA somewhere with the intent to deftly steer the writer toward an organized way of thinking about the problem they’re trying to solve in terms of process outcomes; coming up with a clear idea of “what problem am I trying to solve?” before moving on to defining the causes of this problem, and only then proposing a solution to the problem.

This is a good and worthy goal – it’s a common problem in these sorts of situations for people, even trained IT people, to skip past these steps, and start proposing solutions before the problem is defined, because in many cases, what’s wrong seems to be obvious to the people asking for it, leading to many misunderstandings once people start trying to actually describe the obvious to someone on the outside:

By forcing the explanation of the problem and it’s causes, it’s connections to organizational goals, and measurable successful outcomes through format, it distills the process down to basics, divorces it from all the sexy computer-ey things people want to do and focus on end-result solutions, which may not even require sexy computer-ey things to do effectively when something mundane and cheap like user guidance or a few minutes of training might do. In theory, a lot of these misunderstandings can be avoided, and the smartest, most optimal solution gets implemented.

Of course, in practice, what this means is that most people writing these case documents still aim for their obvious, desired solutions, and fill in all the various preliminary blocks with meaningless gibberish. If you’re lucky, this gibberish doesn’t get past the approving officials, the project proposal gets sent back to the drawing board, and the next iteration gets closer to the meat of the problem. If you’re not, you end up with stuff like in the illustration above (for which I wish I had attribution – the creator is kind of a genius), or, for example, the big clusterchuck of a system I worked on at my last job.

Now, the nice thing about writing this sort of documentation is that once you figure out how to do it, the knowledge is readily transferrable – you can use it anywhere, regardless of the sort of project you’re working on, with only minor tweaks.

Writing these things is kind of an art, but it’s one of those arts that, at its core, boils down to spilling the right sort of bullshit for your audience Luckily, I’m pretty good at spinning the proper line of bullshit.

It’s one of those lessons that some of us learn in school, but that is never really taught to any of us directly – the path to success and good grades is simply to figure out not just what the teacher (or customer, or manager, or whoever) wants and the way they want to be presented with it, and give them that. This involves not just making sure your papers and things are formatted according to the instructions you’re given explicity, but also in accordance with the subtle cues you pick up from things like teaching style. The key is to figure this out early and apply it to maximum effect. That’s really it – sure, being smart and knowing stuff is good, but presentation is often what makes the difference.* This is one of those lessons that works in a wide variety of applications. Figure it out early, and you’re gold.

So, one of the first things I was assigned in this newish job of mine was to revive a dormant project to fix a system that wasn’t up to snuff. A lot of the thinking had already been done, but it still needed to be presented in the proper format to get past the proposal stage. Writing up these business cases is considered the hard thing here, but I took it on, and nailed it pretty quickly. I had my project approved after a quick ten minute briefing, which impressed the heck out of everyone (I imagined it helped that the guy before me flailed for an hour without a clearly defined problem before being sent back to the bench).

So, the moral of the story is that because of this, I’m the expert/business case rock start, and it’s my job to review everyone’s business case documents. At least I’ve made myself indispensable early on.

________________________

*- I’m sometimes amused by the fact that even though I spend so much time working on technical and objective sorts of things where there is one unabigously right answer, so much of the measurement of success depends on something squishy like salesmanship and presentation. It’s like the BS on my undergraduate degree doesn’t stand for Bachelor of Science after all.