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.