Thursday, June 01, 2006

It's All About Moroccan Chocolate

I'm a genius.

It makes me angry that this isn't more widely recognised. I should be making millions from book deals and speaking engagements but that will come. It's all part of the master plan. For now I have to convince people of my genius one by one at work and in slightly higher numbers via this blog. The fact that my rantings on this blog probably convince an equal number of people I'm insane is neither here nor there. There a fine line between genius and insanity. That's my story and I'm sticking to it.

Anyway, on to my latest evidence that I am in fact a genius. At work yesterday I had a breakthrough with the age-old problem of IT workers, how do you explain IT requirements to non-IT people? My role as a Business Analyst (BA) means I have to document the requirements for IT projects which usually presents two challenges. One is the actual discovery process - finding what the requirements actually are is harder than it sounds. Everybody thinks they know what they want from an IT system but once you start to press them on the specifics they realise (9 times out of 10) they haven't thought it through very well.

The second issue is often simply convincing a business they need some sort of formal requirements gathering process. This usually follows on closely from the "we know what we want" delusion. I call it the "just do it" delusion - that might work as a slogan for a shoe company but it's the equivalent of a suicide note for most IT projects. At this point any proponents of XP/Agile development approaches will be calling me an old stick-in-the-mud. Any reader who has no idea what XP/Agile development means can safely ignore that comment. Proponents of XP/Agile methodologies are crazy people (who nevertheless never respond to deliberate troll comments in blog posts).

So we had a team meeting yesterday to discuss our methodology, how to improve it and how to communicate the process to the business. Our System Development Life Cycle (SDLC) involves defining scope first, then formalising the Business Requirements, then a Functional Specification then handing off to the development group. One team member put forward how he had tried to describe the SDLC in architectural terms because he used to be an architect. This didn't work because nobody else used to be an architect. So we decided we needed a simpler analogy, how about describing it like a recipe? Why not indeed. So I took that idea and ran with it.

Forget IT, we're working on something else. There's a big party coming up and our project is to provide a chocolate cake. The first step is to meet with the business and confirm the scope. Do we have to do anything else for the party? Book a venue? Set up decorations? Bring beer and chips? No on all counts. Our scope is confirmed: all we are providing is a chocolate cake.

Next we have to confirm the Business Requirements in some more detail. What do they specifically want from the chocolate cake? Well, it has to be enough for 36 people. Ken is allergic to nuts so make sure it doesn't contain nuts. Should it be a sponge cake or a mud cake? At this point we don't worry about the details of the recipe (that's in the Functional Specification) or the baking process (that's the Technical Specification), we just talk about the outcomes we want. A mud cake that can feed 36 people and won't kill Ken because of his nut allergy.

Then comes finalising the recipe (the Functional Specification). This tells us everything that needs to happen to deliver on the business requirements (the mud cake needs this much flour, this much cocoa etc.) but doesn't tell a baker what to do (the IT development team write a Technical Specification - the equivalent of baking instructions).

If you've ever worked on an IT project you'll know one of your big enemies is "scope creep". This is when the business wants more and more features even when you have previously agreed on the limits of what you are doing. This takes longer, costs more money and makes it more likely that something will go wrong. So what happens when our chocolate cake project is chugging along and a manager sees a lifestyle program extolling the virtues of Moroccan chocolate? He decides the cake absolutely must be made with Moroccan chocolate and comes in the next day to insist the project plan is changed. How do you deal with this?

It depends how far the project has progressed when the manager starts pressing for Moroccan chocolate. If this happens in your requirements stage, you're in luck. The manager declares the cake project will be a failure without this so, by definition, Moroccan chocolate is a core business requirement. This may require some changes to your project plan. Is Moroccan chocolate more expensive? If it is, that means either increasing the budget or cutting back somewhere else. Can you get it locally or will someone have to fly to Morocco? Does cooking with Moroccan chocolate require special training? If so, do the skills already exist in-house or will an outside expert be required. Time and money comes into it again.

The later the requirement for Moroccan chocolate is identified, the bigger the impact may be. If you were already finalising your recipe (Functional Specification), you need to change it. If you want to keep track of why the project changed (and it's a big mistake not to) you need to document this change request. You can use this later to identify why it took longer and cost more. The later you were in your project the more trouble you may have making the change. If the bakers had already started they will have to throw out the work they've done so far. And if they don't have Moroccan chocolate cooking expertise, well, the whole thing's on hold until you find someone with the right experience.

In essence, you can always add Moroccan chocolate as a requirement, so long as the person asking for it appreciates the additional trouble, time and expense involved. And this is harder to establish if you don't document your scope, business requirements and functional specification.

And with that convoluted analogy we had had our solution. Explain to the business: it's all about the Moroccan chocolate. Do you need it? Are you willing to accept increased time and expense? Can you see how bringing up these requirements later causes many more problems than bringing them up earlier? And the funny thing is the business understood what we were getting at. It's quickly becoming a catchphrase, if someone talks about a new or potentially difficult requirement the response is "Is that a Moroccan chocolate requirement?"

And that's how I spend the non-blog part of my day.

11 comments:

pigeon weather said...

sounds like you're on the critical path, or it's mission critical, or something about traction, or maybe you're on the bleeding edge, the foreskin of technology ...

gotta love "process". that's what happens when XP/Agile boys flame out.

Mr Angry said...

Hmmm, I should have worked foreskin in there somewhere. That's still the #1 search term that leads to my blog. I'm all over the critical path right now. I think I got hit by a critical truck while I was standing there.

Alex said...

Damn you! All this talk of baked goods and now I'm hungry!
I have two options, neither of which are very appealing:
1. Scrounge for something that isn't cake but will serve the purpose of dampening the hunger gurgles. The con is in knowing that this will only leave me spiritually unfulfilled, being that bread and vegemite do not equal moroccan chocolate cake.
Or 2. Attempt to make aforementioned moroccan chocolate cake. This one is pretty much out the window because I'm far too lazy to drive to the shops to buy ingredients.
So, I suppose I'm going to go with the unmentioned option 3. Complain and otherwise do nothing.

Mr Angry said...

Ruse: yes if it isn't morrocan chocolate, it simply isn't the right solution.

Michelle said...

What if someone is allergic to chocolate, how do you cater to those people?

moonflake said...

wow. as a BA myself, i have to say Angry, you have really hit the nail on the head.

The big project i'm handling atm had a 254 page FuncSpec, is on Change Control 140 and counting, and has so much scope creep we can't even see the horizon anymore. But that's okay, because we charge them for everything, including the time i take to write out the change control document ;)

PS, if you want to know what project i'm talking about, look here. Not just the website, ALL the software that supports this attraction, including onsite sales terminals, PDA admissions terminals, LED and plasma displays, online and reseller ticket sales... i think you can see the space for creep :)

moonflake said...

As explanations of project lifecycle go, this one's just as good as cake.

Mr Angry said...

Micelle: that would have been uncovered in the requirements gathering, like the nut allergy. My recommendation would have been to give them a piece of dry bread.

Moonflake: Typical nightmare project eh? Being paid for it is good tho :)

Di said...

Write a book and I'll probably buy it.

schpat said...

Dude, I seem to do almost the exact same job as you, any jobs going there in Oz? What you've said is undoubtedly pure genius. I printed copies of the analogy and distributed them to my team, with the blog address of course. I'm passing to make "Moroccan Chocolate Requirement" a catchphrase here as well, if it catches on it could spread the world over. That would so rock.

Post more stuff I can distribute at work that makes it look like I'm keeping abreast with industry developments, as opposed to arbing around reading amusing blogs.

Thanks for the insight.

Mr Angry said...

Di: I may hold you to that!

Schpat: Dude, I write this stuff so it looks like I'm working instead of blogging for fun! Not that I want to contribute to the SA brain drain but lots of IT-trained saffers are coming out here as skilled migrants. It's a boom job market right now. Best in about 5-6years.