Mapping Current and Future State Business Processes Is a Waste of Money

Back in my EY days, I was responsible for requirements documents that were several hundred pages long. These things were a work of art! To be fair, in the 80s and 90s, we didn't have any other options because these documents formed the basis of our promise to the governing bodies who trusted us with their precious funds to deliver a solution. But even back then, I didn't really understand why we were mapping today's processes. Sure, it provided interesting context at a summary level—but anyone reading through pages of diagrams is going to glaze over pretty quickly.

Somewhere between then and now, writing code became cheaper than writing documents. This change happened around 2010 with the advent of what I call cloud V2 technologies. Coupled with the already mature plethora of open-source tools, this means we can write code and deploy it without any lead time to consider infrastructure at all. More tangibly, I can deploy real solutions within hours or a couple of days of starting a project.

Despite this silent revolution, every project rescue I've worked on in the past decade was accompanied by volumes of current and future state process diagrams. In all cases, the research needed to produce these diagrams cost more than building a solution after restarting the project. It is no longer necessary to map out current or future states in detail to make promises to governing bodies, so seeing these documents irks me a little. This is especially true in a sector where every $100,000 of waste could have gone towards making a bigger impact.

It's also interesting that such process documents delve into the same level of detail for all processes, with no connection to the business case. In a recent example, a transformation program considered 70 business processes in its initial investigations. No filter was applied to ask, "Does it make sense to re-engineer this process?". A cursory scan showed at least 20 processes where the cost of building a digital solution couldn't deliver a commensurate benefit in less than 20 years because it affected a small group of users (typically administrators) and the process was conducted weekly, monthly, or quarterly, rather than hourly or daily. It's difficult to build a benefits case for such processes.