 |
| AI-generated image - see Note #1 |
The Tectonic Speed of Government, Part 11: "Lifting Up Rocks"
This blog’s metaphor is visual – and specific. Stick with me here, please:
Imagine that it is 1835 and you are clearing a path for new railroad tracks through the Midwest prairie, where trees are scarce but stones in the ground are abundant. You have a rudimentary hand-drawn map for the route, written by someone far away who didn’t scout the land themself.
Your task is to move along the planned path, finding and removing rocks of different sizes. Some are easy to move; others require more effort. Appearances can deceive: the bit you see above the ground could be much deeper below the surface.
This metaphor represents the analysis phase of a software project. In this stage, the project team clears the path for the new system by comparing the client’s business process to the software, finding and removing issues (rocks) along the way.
Probing a Nasty Rock
Now imagine that you’ve come to a big ugly-looking rock. It is slimy with moss and hard to grip. Clearing this rock won't be pleasant.
This represents the moment in a software project when you uncover a significant disconnect between the established process and how the new software works.
It’s normal to find these – it’s actually why you’re there. But your job is to find and remove them, so where to start?
First, you need to back up and examine the rock from all angles.
On software projects, the first step is to explore the process that’s different from the software. Why do people do it that way? And no, “that’s how we’ve always done it” isn’t reason enough. (Note #2)
A decent number of cases resolve themselves here, because people decide that the easiest solution is to modify the process. This is especially true for smaller entities using cloud-based (SaaS) software. Because you can’t change the way the product works, you might as well adapt to it. (Note #3)
In the metaphor, changing a process is the equivalent of digging out a rock to remove it. It is the cleanest resolution and keeps the railroad tracks running in a straight line.
Pro tip: these situations measure the readiness of change in the organization. The cliché of government workers who are locked into their processes is increasingly out of date. Higher staff turnover in government (due to the silver tsunami and worse retirement benefits) and the increasing frequency of system transitions mean that government workers are more open to change. (Note #4)
Sometimes what lies behind the process are the organization’s policies – or even a statutory law. It’s still OK to question these and find out what can be amended. Changes are more likely with policies, but even statutes can be modified – although the delay may be too long to benefit the project.
Working Through (or Around) the Rock
What if you can’t move the rock? Sometimes there’s not a natural fit between the process and the software. This is the rock that’s too big to move.
The first step is to document and escalate the issue. In the metaphor, this would be drawing a picture of the rock to show to people who aren’t there. (Remember, it’s 1835.) In software projects, it’s documentation about the issue and possible resolutions.
Important: The worst thing to do is no action; not raising the project risk flag and just hoping that the problem goes away on its own. Don’t wait for the rain to wear away the stone – you don’t have that kind of time!
One option for a rock that won’t move is to bury the rock in a mound of dirt. This lets the train roll through but creates a bump that will disrupt travelers every time they go by. On software projects, this is creating a work-around (like forcing people to do double entry) that will impact the users every time they go through this process.
Another option is to go backwards and adjust the railroad tracks around the rock. Since tracks can’t turn sharply, you have to back up a distance, which requires more effort and cost. On a software project, this is increasing the scope of the project, for example by bringing in and integrating a third-party solution. Sometimes this is needed – but it means backing up and re-doing work. You don’t want to do this unless you’ve attempted to move the rock and failed.
Ultimately, you need to try to clear the rock first – and waiting longer before you make the attempt will only postpone the inevitable. (Note #5)
Building Over the Rock
There is one more option, but it’s not available to most: customizing the software to meet the process. This is more likely on big projects and isn’t an option (or recommended) for most local governments. (See Note #3.)
Recently, I worked with a project team that found just such a rock – and inspired this whole blog.
First, they ignored it and hoped the rock would remove itself. That didn’t work. (In their defense, they were clearing several paths at the same time – and other paths were more urgently needed, so this issue lingered in the background.)
The problem was that while ignoring the rock, they burned through months of time when they could have been moving forward. Ultimately, to get them to even return to the rock I had to use a different visual metaphor: lancing a boil. Letting the issue fester had caused it to infect inter-related processes. I had to shine a light on this so that we could finally have an open discussion on it.
The team was at an impasse. The rock was too big to easily remove, and the project spent so much time ignoring the issue that they could no longer back up and change the path. The train tracks had to go this way, but that big rock was still there.
 |
| Middle picture - see Note #1 for the prompt |
At that point, good news came down: the project timeline was extended! (This is a common situation on government IT projects – as discussed in the blog linked in Note #3).
Suddenly, a new option was available: request changes to the software to accommodate their needs. This was viable because the software changes were small - and the client was large. (This is not normally the case!)
Returning to the railroad analogy, this is a more expensive option of building a small bridge over the rock. This was the solution I proposed, since this project had the capability to do it.
However, that approach was shot down, and a burying project commenced. There will be double-entry, and therefore a noticeable big bump that will disrupt the path in the future. Fortunately, it’s only a few people who need to deal with it. (I’d really be torturing the train analogy to come up with a metaphor for that part!) But for those few people, the ride will be bumpy.
 |
| Last picture - see Note #1 for the prompt |
Final Thoughts
My goal in writing this blog was to share some lessons learned for Business Analysts. Removing rocks can be a thankless task and – like so much else – no one every thinks “wow, this ride is so smooth, I appreciate whoever took the time to make this possible.” Instead, what people do is complain about the bumps.
On projects with limited finances, some bumps are inevitable. Be realistic about your role. Remember that your job is to scout ahead and find rocks, remove the ones you can, and call attention to other ones for further action. You can’t remove them all, but you can find them and address them as early in the process as possible.
Notes
Note #1: I’ve been writing this blog for more than six months. What’s different this time is that I created the pictures early on, using AI – in February and March 2025. With more awareness of the resource-intensive process for AI pictures, I don’t plan to use Bing image generation for a while. (At some point, we’ll be able to run that logic on a Raspberry Pi – but until then…) Since I had them, I used them - and here are the prompts for the pictures:
- Header picture: “clearing a path through the grass there are some medium sized rocks stuck into the ground.” I don't know what kind of a weird tool is in the picture on the left side of the path. I'm imagining it's a pick of some kind - very 1835.
- Middle picture: “the view from on top of a train as it rolls down a track towards a rock that sits across and blocking the train tracks.” The rock is too big here, but you get the idea.
- Last picture: “a clearing of grass there is a fancy railroad bridge built of wood that bridges over a rock.” I love this image - it really nails the idea.
Note #2: A word to consultants: just because they've always done it that way doesn't mean that way is wrong. During these conversations, some consultants lose patience because the users take a delight in explaining every step of the absurd convoluted process in excruciating detail. A reminder to be patient. Understand that this is that person’s chance to share something they know well, and few other people understand; this is their time to shine. Consultants should listen and take careful notes. Once they’ve spewed out the details (ultimately, it won’t be as crazy as they make it sound at first…), you can acknowledge their expertise and then guide the group to come up with a better approach, or acknowledge that the process is truly required. (Sometimes it is!)
Note #3: Here’s my maxim: “Find the best software you can afford and then change yourself to adapt to it.” The only exception is an entity with a unique process - like the IRS. For more on this discussion, see the section called “Own the Data, Rent the System” in Tectonic Speed part 2: https://blog.tectonicspeed.com/2020/01/the-tectonic-speed-of-government-part-2.html
Note #4: The move to SaaS software helped here in two ways. First, frequent transitions between software mean people aren’t as tied to their processes. Second, customizations to SaaS software are less likely. As a contrast, back in the 1900s when I worked on COBOL systems, it was often the first time we had automated a process – and our tool was mainframe code that was designed to be customized. So early software systems were adapted to the business process, further reinforcing how things worked. (Many of those mainframe systems were in place for decades - a few are still operating as I write this in 2025.) Later employees just assume that the system, and the process, have always worked that way – because it was true! That’s all those employees have experienced.
Note #5: Detecting the disconnect between the client and the system is an advanced business analyst skill. While understanding someone's process and fitting it cleanly to software is a core proficiency, sensing when they don’t line up is even more valuable. As with bugs caught during development (https://wabbisoft.com/wp-content/uploads/2024/02/IBM-System-Science-Institute-Relative-Cost-of-Fixing-Defects.png), finding and addressing a problem earlier reduces the overall costs of the issue. Resolving it during analysis is much better than during testing or (gulp) after go-live.