This post originally appeared on November 5, 2010 on BetterProjects.net
Recently I read an article entitled Taco Bell Programming (link contains some rough language at the end, but excellent concepts throughout) in which the author, Ted Dziuba, has some interesting thoughts on development tasks that apply to business analysis and project management as well.
Taco Bell has 8 basic ingredients that, when combined in different ways, can be used to create their entire menu. That’s pretty impressive when you think about it, because they can maintain a very small set of inventory items, yet produce a wide variety of products for consumption. Because the company is creative in the way it combines their inputs, most customers don’t even recognize the repetitiveness in the menu.
Ted’s basic premise as to why development should learn a few lessons from Taco Bell is two fold… first, reuse of existing functions that you do not have to rewrite and then maintain is better than creating new software that produces the exact same outcome. I couldn’t agree more. I’ll give you an example of this from my own life: how I approach a Work Breakdown session. We’ve all been in these, where we spend a few hours writing on post-it notes and tacking them up on the wall. Necessary, but really boring.
Whenever I’m asked to participate, I come in with a stack of ‘boilerplate’ tasks. There are certain steps which always occur, no matter what the project, so I come in with that set of tasks already written out and ready to go. I cut my time in the WBS to 1/3 of the otherwise needed time, just because its crazy to reinvent the wheel. That’s not to say I don’t add additional tasks that are unique to that project, I most certainly do, but those tasks that myself or my team do every single time always come with me in a stack.
The second premise Ted brings us is that unless there is a very compelling reason, we should prefer older and simpler tools over newer and more complex ones. Yes, using that new development tool can be sexy and may teach you a lot, but what do you lose by spending the time implementing a solution that could be done more quickly and with less risk by using an older tool?
To me, this is why BPMN just hasn’t caught fire as of yet, namely that Visio flowcharts work just as well, if not better, than a BPMN tool. Why do I say that? Simple. Most BAs, and a large portion of our stakeholders, likely have seen and used Visio, while they likely don’t know BPMN and don’t understand what all the more complex (and more precise) stencils mean. BPMN 'looks too difficult’ so stakeholders, and some BAs, dismiss it, even though there are some nice things the tools allow us to do.
Its just not the analysis side, either. There are lots of web-based project management tools out there which have a simplified workflow when compared with MS Project, but because most PMs and stakeholders understand MS Project, they stick with that tool. Its not that web-based tools are inferior, they usually are not, but Project is a known quantity which everyone can relate to (no matter how bad it is).
I must, in all fairness, point out one flaw in Ted’s logic: Taco Bell’s products, while cheap and easy to make, are not what most people would think of when they consider when looking for a 'quality’ eating establishment. Menu ingredient simplicity does allow for quick and cheap, but when sophistication is really needed, it just can not be found at this location. There are times when sophistication is necessary, both in the culinary disciplines and with Business Analysis and Project Management, and we must remember to choose wisely when that need arises.