The Art of Process Analysis: Seeing is Not Believing
“This is amazing. It’s so obvious now that you’ve pointed it out. We’ve been struggling with this for months, and now it just makes sense.” These words are incredibly validating and also commonplace in our customer conversations. This year alone, Tactical MA has provided nearly 600 hours of process development consultation to our customers. At the end of the day, process development is no different from any other troubleshooting effort.
This is not a different camera angle; it’s the same picture side by side. The brain simply doesn’t accept this truth.
Consider This Troubleshooting Story:
We were recently integrating Gravity Forms on a WordPress site with Act-On Software through a standard JavaScript method. However, a very talented developer had become stuck when he did not get the expected results from the script deployment. He called me into his office as a sanity check and explained the situation,
“I pushed the data to Act-On successfully. I added one parameter to the query string. It failed, so I removed the parameter to the previous successful test, and it also failed.”
Stuck.
It’s important to understand that I have absolute confidence in this developers’ WordPress and JavaScript skills and regard them as one of the world’s top ten Act-On experts. This wasn’t a training issue.
So I had him walk through the process with me. Show me the code, push the code, load the form, submit the form, validate the result.
It became quickly evident the JavaScript wasn’t actually running on the page, which I pointed out, to his frustration. He responded, “I know, but there is nothing in the code that would break the script. It is built exactly right; you just watched me do it.”
So I asked him to show me the page source code. He glowered at me, explaining why he was certain everything was correct as he navigated to the page source code.
And there it was (or wasn’t) plain as day. The script he had written was not on the page. He refreshed the page, still no script. He quickly returned to WordPress and republished the GravityForm and WordPress page – still no script.
He explained that we must be looking in the wrong spot; the code had to be there. I smiled and had him change and push the copy of the Gravity Form response page.
And it was confirmed. The saved and published changes were not showing up on the public page.
Experienced WordPress developers and users can already see exactly what the problem here was. The CDN was caching the page, and the version we were seeing wasn’t updated. His mistake was believing his own brain. He had pushed the button to update the page and made the assumption the page had been updated.
I couldn’t have told you why it wasn’t working at the start, but I followed the golden rule of troubleshooting.
Don’t trust your brain; test every assumption.
Applying These Lessons
The way we apply this lesson to process development is direct and parallel.
1. Define All Objectives
2. Collect All Facts
3. Document
4. Review and Brainstorm
1. Define All Objectives
The first step is to collect and define all objectives. Suppose we are developing processes that impact the sales and marketing teams. We should interview the sales and marketing stakeholders to understand what, specifically, they are trying to accomplish. If we’re told, “IT always makes things difficult,” then we also interview IT. By understanding the objectives of all stakeholders in the process, we can establish clear rules and boundaries for our solution.
The process must accomplish X and cannot impact Y.
2. Collect All Facts
This is where refusing to trust the brain is critical. We interview stakeholders and participants, but we also review the technology. For example, clients will often tell us how lead assignment rules work in CRM, but this only tells us how this person thinks they work. When you explain a technical process to us, we will absolutely open that process in your website, marketing, or CRM to verify it for ourselves. Once we look at the technology, we find that approximately 60% of processes are explained to us inaccurately.
It is imperative that every fact be conclusively tested before being accepted.
3. Document
The third step of effective process development is to document everything in its current state. I’m not talking about taking notes in a notebook, I mean formal process documentation; flow charts with a granular step by step workflow. Take everything we will touch and articulate exactly how it works right now before any changes are made. (See Below) There can be no assumptions in this process. While documenting processes, we commonly encounter gaps in our discovery process, places where steps must occur, but we do not know how they occur. This documentation is extensively marked up and will serve as the data source for all additional discussion and development.
If it’s not documented, it doesn’t exist.
4. Review and Brainstorm
The final step of effective process development is to review the existing workflows and imagine something better. It’s the magical piece. As one of my team members often says,
Instead of doing the dumb thing, do the smart thing instead.
This is why I likened the practice to troubleshooting. Once you have identified the problsem, it’s usually plenty easy to define a solution. The hardest part (solving the problem) becomes the easiest part.
Because we have already mapped out the process end to end and defined every single gap, contradiction, or redundant step in the process, producing an optimized process is very simple. Plug the gaps, resolve the contradictions, and eliminate redundancy. The remaining process is seemingly a work of genius.
Really, it’s just a strict adherence to fundamental troubleshooting.
Impact
We know that this type of thinking is not common, nor is it easy. We spend our lives trusting our perception, and learning to think radically different doesn’t happen overnight. That is where the impact of a third party comes in. We can facilitate change within an organization, and we become a powerful force for soliciting buy-in to new ideas.
By following this process, we have solved hundreds of “impossible” problems.
We have integrated systems that cannot be integrated, developed workflows that could not be made, and, most importantly, generated many thousands of leads and many millions in revenue for our customers.
The ability to look at the same data and reach different conclusions is the advantage of an outside consultant. We don’t have the same bias, pressure, or experience with your company, affording us objectivity in our evaluation. Because we get an incredibly detailed view of your process with zero context, our questions are detailed, often redundant, and frankly, we can ask the stupid questions that would be political suicide for an employee of the company. We don’t risk our jobs by challenging the CEO. We don’t make enemies by critiquing the status quo.
The way we stay impartial is by following simple guidelines, like the steps we’ve discussed here. The commitment to honest and analytical thinking often makes us invaluable to our customers.
