Phone: (678) 366-1363 | Toll Free: (866) 675-2125

When did Process Improvement start?

One of the questions I ask students in my classes is, “When did business analysis start?” Usually, within a few seconds (and some auditory discussion) they get that it has been done since the first business was created. Which brings me to my question for this blog – when did process improvement start? If you read the second sentence, you can probably figure out that it started with the first business in existence needing to improve its process. I have evidence of this from a summer vacation to St Augustine. Yes, I still look at stuff from a BA perspective, even on vacation (it’s a sickness, I know).

I was at the Castillo de St Marcos in St Augustine, watching a historical demonstration of 18th-century fort defense. Part of that was cannon, part was infantry. It was the infantry that attracted and piqued my BA skills. The infantrymen gave a demonstration of how they fired their flintlock muskets. The stated time for the entire process was 1 shot fired every 15 seconds. Now keep in mind the soldiers had to: clean the barrel, drop a charge into the musket barrel, ram it in with the ramrod, drop the musket ball into the barrel, fill the flash pan with gunpowder, cock the hammer, aim the weapon, and only then, fire. 15 seconds? I would be lucky if I could do it in one minute. However, the more I looked at it, the more I realized how they looked at the process to improve it.

First, they drilled constantly so the soldiers would not have to think about it. It became “muscle memory” to them. Over and over again. They didn’t think about the processes, they just did it. The correct amount of gunpowder was not estimated, the necessary amount was carefully packed into a paper cartridge which was opened and poured into the barrel at the appropriate time. Same with the musket’s flash pan (which the flint struck to create the spark). The commander would call out the commands, but in most cases, the infantrymen already knew the next step. Why?

Simple. They had made the process repeatable and removed as much inefficiency as possible. Repeatable in that the soldiers knew exactly what needed to be done. One of them fell due to combat? Another knew the drill and could take his place immediately. Efficient? Sure. The soldiers did not have to measure the amount of gunpowder. The measuring had already been done prior to the battle, and the exact amount was packed into cartridges. Efficient and repeatable

When looking at your processes, how can you take what the infantry developed and apply it to your organization? If you concentrate on just the pre-measured powder packets, you can see how they were using those to prevent mistakes. By taking out decisions in the process, you can forget about having to fix errors in the process because you PREVENT errors from happening in the first place. Just like pre-measured gunpowder packets prevented incorrect measurement, error prevention in your processes ensures you don’t have to design a second process to correct them later. Have employees entering expense accounts? Make sure they have a predefined list of categories to choose from, instead of entering them. Instead of having an accounting associate validate the entries later, build in controls that don’t allow incorrect entries to come in during process execution.

Now I’m not saying that your business area is a combat zone, but what can you learn about your processes from the 18th century militia with flintlock muskets?


  1. first, lets analyze what you observed watching the musket demonstration … you were watching the very end of the BA process … you were seeing the result of years of infantry experience applied to the unique problems of rapidly firing a musket …

    in other words without the experience of actually firing a musket you couldn’t begin to attempt to improve the process …

    but what could you do if you where asked to improve the musket firing process (before the refinements you witnessed where implemented) and you had no experience ?

    Well, you could do what every BA should be doing … talking to the end users … asking them questions and maybe even firing a musket a few hundred times …
    but that takes time and we all know that Agile can’t wait for no da*n requirements …

    a BA with musket no experience might look at the process and say, Why clean the barrel each time ? Wouldn’t that save alot of time to not do that ? a BA with experience would not even ask the question (assuming the experience of trying to load a new powder charge into a dirty barrel didn’t blow their face off) …

    In the end its not the BA that defines the goals and problems to be solved, its the end users … you know, the ones with the experience … the BA is like a farmer who cultivates a crop of ideas and information from the soil of the end users experiences and insights …

  2. @JeffC – thanks for the response! You get it! You bring up some good points about who really performs the business analysis. In many times, it’s not just someone with the title of Business Analyst. A sole proprietor shop with one employee probably does not employ a “Business Analyst” but does that mean he doesn’t do any business analysis? No. It may be the end user interacting with the process day in and day out that figures out the problem as well as a workaround.
    In the process of firing the musket, there are strict procedures to be followed. Your point about making the process more efficient by removing the gun barrel cleaning is valid. Removing that would indeed shorten the timeframe between shots, but it’s not the most effective from a safety perspective. The person performing the analysis DOES need to understand the system and the process before improvements are made.
    Many times, process improvement suggestions come from those performing the process as they find better or faster ways to perform it. The BA (person performing business analysis) then ensures their solution doesn’t impact another process or system, or their workaround doesn’t harm someone else’s process. Also, the BA can drill into the root cause of the problem, and doing so would be the correct response, and certainly talking to the end users (the musketeers), observing them, and asking questions would be part of the analysis necessary to understand the process prior to looking towards the improvement.

Leave a Reply