Introduction to the Business Analyst’s Cookbook

Purpose

The purpose of this publication is to establish a shared understanding of each recipe in review, simplify or re-order the steps where sensible, and add some context for the less informed ‘chefs’ of the world.

Ideally — the resulting process (recipe) will be in some way improved, though it should be noted that ‘improved’ in this context does not necessarily mean faster, tastier, or more consistent. It might be one or all of these things and in some cases I might cover something simply because I enjoyed it.

My hope is that these re-imagined processes will be more approachable through visualization and by offering knowledge which a recipe might normally expect the user to know or find elsewhere. That said — I’m just doing this for fun because I have the free time and enjoy cooking.

A Sample Process Model for a Japanese Beef Curry

What does this have to do with Business Analysis?

The beautiful part about cooking is the extreme range in process complexity and the diversity of skills required. Some recipes require little more than a knife & a hot pan and will deliver something delicious in 15 minutes or less, while others require an arsenal of kitchen appliances and 1–2 days of hard work.

Just as a recipe might require the use of many different tools (kitchen implements), and sub-processes (shopping, prep, etc.), so too must a business analyst frequently work with many different tools (information systems & applications) and sub-processes (ETL is a common one, but obviously this could include a whole myriad of things). It is often a critical part of any business analyst role to review, evaluate, and improve existing business processes, as well as document, disseminate, and educate users on their execution.

This is what I will aim to do with recipes.

A Few Things to Note

• Cilantro is the devil.
• I’m mostly doing this for fun, but also to illustrate the application of a business analyst’s mindset to a common everyday process.
• Dishes will usually be documented individually, rather than as an entire meal, except when a necessity. A Japanese curry will always include rice, so the rice sub-process would always be included as part of the overall flow. On the other hand, a turkey chili & jalapeno cornbread would be documented as individual processes — though they are a common pairing, neither is required to enjoy the other. On occasion, I will however post recommended meals, which will include the end-to-end documentation of the combined flow for starter, mains/sides, and dessert (or some subset of those).
• Some recipes don’t need much modification, if any. I might still document some of these anyway if only because I enjoy cooking and eating them.
• On measurements — I originally wanted to enforce a standard unit of measure in metric. However, I also didn’t want to make recipes unnecessarily difficult to follow either. It is much more common for people (at least in North America) to measure by the tablespoon or cup — especially for smaller measurements — rather than by millilitre or gram. I’ve found that is also uncommon for users to have a scale at their disposal in the kitchen. Therefore, despite my frustration at a lack of standard, I think it makes more sense to continue using this widely accepted mix & match of cooking measures. I will always include a link to a conversion tool in the ingredients section to hopefully eliminate some potential frustration.
• Assumptions: I will generally assume that all users have very basic skills such as knowing how to cut things with a knife, use a frying pan, or turn on an oven.
• I’m writing these in a way that makes sense for my brain — this bias might result in gaps in the process for other users. It is my intention to fill these gaps when found — if you are following a process in this publication and find yourself confused — I would greatly appreciate your feedback so that I can update the document accordingly.
• Coriander is disgusting.

Also, Documentation is Cool

• It gives us a shared understanding of processes, particularly important when more complexity is introduced.
• It creates a platform for discussion — do we all agree that this is how this process works or how it should work?
• It reduces training time, reinforces learning, and will hopefully prevent me from asking my girlfriend for help so I can cook for her instead of telling her I’m going to cook for her, then asking for help every few steps
• It prevents rework. Ever been 40 tabs and 5 hours into solving a problem? Documentation stops you from doing that more than once for the same problem. I am aware this a less than likely scenario in the context of the kitchen, but I have had to Google my way through some recipes more than once.

Intended Audience

If you are a professional chef — you may want to avert your eyes. The level of detail here will probably seem ridiculous to you. Aside from that — you may question my decisions to re-order steps in the recipe, avoid parallel processing, or explain what may seem obvious. I am aware that in making such changes, it might impact the flavour, texture, or freshness of the final result — but not to the extent that that typical home cook would care.

I assure you, as someone that has recently picked up cooking more seriously (and has no intention of doing it at a professional level), many of the things that would seem obvious or easy to someone working in a kitchen, were a mystery to me. I found myself working through recipes only to wonder to myself “Why did I start cooking this and then try to chop this other thing and then try to boil this other thing and slice this other thing?” when I could have very well just chopped all the things first before starting to set things on fire. To the trained chef — frying some chicken, boiling some potatoes, and roasting some veg, while preparing a sauce on the side probably seems like a simple task. To a home cook, especially a new one, it was and can be stressful, not having the innate knowledge to really know when each item should be done or in some cases, even what a finished product should look, feel, or taste like.

So this is intended for the home cook who — like me — isn’t really sure when a piece of meat is considered done, or how much seasoning is too much or too little or is not confident enough to both learn a new recipe and multi-task, especially on the first go of it.

Format

As I normally do when writing process documentation, I prefer to follow a standardized format. When I say ‘standardized’, I do not mean ‘one-size-fits-all’ — the document should fit the need. However, in this case, since I will generally be approaching processes of a very similar nature — cooking processes — I will usually follow the below format:

Section 1.00 — Summary

1.01 — Description

A very brief, high level commentary on the recipe documented.

1.02 — Origin

A reference to the original author and cookbook where the recipe was found and/or a link to the online source when applicable.

1.03 — Estimated Processing Time & Servings

Estimated Processing Time

An estimate of the time required to prep & cook based on my personal experience. The current state estimate is (usually) provided by the original recipe. The future state estimate will be based on my actual execution time.

Estimated Servings

The estimated number of servings.

1.04 — Version Control Table & Contributions

Any feedback or updates which are added to the document will be recorded here with attribution. Any published recipes will always start at v1.00

Section 2.00 — Ingredients, Tools, and Skills

2.01 — Ingredients

A list of ingredients, which should be presented in a consistent unit of measure and in as plain English terms as possible (ie. 1.5kg or ’10 tomatoes’) + possible substitutes in square brackets.

2.02 — Tools Required

A list of the tools required + possible substitutes, in the same format as ingredients above.

2.03 — Skills Required/Pre-requisite knowledge/Terminology

A list and definition of any additional skills or terminology required to understand the following process.

2.04 — Mistakes Made

Any mistakes I made during the cooking process & any lessons learned/solutions.

Section 3.00 — Related Resources

Any resources related to the recipe or completion of the recipe (ie. Links to YouTube videos describing a specific skill or possible variations of the documented recipe or the cookbook it originally came from on Amazon).

Section 4.00 — The Current State Process

The recipe instructions, in its original state + my commentary on what I personally view as the gaps in the documentation.

Typically — in this scenario, I would also model the as-is process. In the end, I decided not to model the as-is process since I think — so far — the actual flow of the process will not be heavily modified in many cases. Second — I am doing this for fun and I also don’t want to ruin the fun by over burdening myself with excessive documentation. That said, I do value a visual model of any process, so I absolutely think it’s important to include at least one & if I’m going to include one, it must obviously be the future state process.

Section 5.00 — The Future State Process

5.01 — Process Model

A BPMN 2.0 Process Model, such as the one shown at the top of this article. For a basic understanding of BPMN 2.0, see the following quick reference I’ve created: BPMN 2.0 Quick Reference.

5.02 — Process Summary

A step by step overview of the cooking process, this may be enough for more experienced cooks or if you’re cooking for a second time.

5.03 — Process Detail

Detailed, step-by-step instructions to complete the process, images included.