Business Processes 1NF — The Sacred & Holy Book of the Process

I

n a mythical business in a far away land, there was a holy book called The Business Process Manual. It was written by a very, very senior Scholar with years of deep training and experience across many businesses. The vassals and peasants all had to obey The Process, but to them, it was nothing but hardship and not meaningful to their daily lives. They begged the Scholar the change The Process: to allow them to plant earlier, or to use new crops like the potato, but the Scholar huffed and puffed and said, “No such thing has ever entered the business models I learned in school, so no such thing shall be allowed in my kingdom!” And even the King was cowed.

Sadly, this story is not a legend, but real life to thousands of businesses and organizations throughout the world. A professional “business analyst” or “systems analyst” (as they used to be called) studied a dozen businesses and figured out what The One True Business Process should be. It was written down in an official binder with document control stamps on it. Everyone is supposed to use this process, but most people try to escape it.

The Business Process has lots of “shalls and shants”, but to most workers, it seems arbitrary. It doesn’t seem to reflect what they are actually supposed to do, and doesn’t even seem like the most efficient way to do it, but everyone still needs to do what needs to be done. Thus the workarounds.
A workaround is a hack for business processes. It’s a way to get something done by not following The Process, but doing all the paperwork and computer entry to make it seem like one followed The Process. The thing is, this workaround gets the real goals of the business done, and often makes the company more efficient and profitable. So why isn’t this integrated into The Process?

The Sacred Business Process

The business treats the written business process manual like holy text – it should be take verbatim and should never be edited or changed, or at least not by the common people. The business process “experts”, or committee who writes it, are treated like high priests, and no one wants to challenge their wisdom. They often have scarily impressive resumes and education credentials, and what they say sounds like it’s for the best. But the Process writing process has become disconnected from the needs of the people who deliver the goods. Why aren’t they communicating with each other?

A Legacy of Mistrust

Employees, their managers and the Business Process People (“The Guardians”) no longer trust each other. It can be broken into two cases:

Case 1: “I know better than you!”

In the first case, the Guardians no longer accept that the experience and wisdom of front-line employees and managers. The Guardians don’t listen to the people who do the work; they don’t give the employees credit for what they know. The Guardian will even show disrespect for the people who actually do the work: “What do you know? I have studied dozens of other businesses, and you haven’t, so you aren’t smart enough to criticize me!”

Case 2: “We know better than you!”

In the second case, the Guardian means well, but for historical reasons, employees and managers have nothing but contempt for the Guardian.

“You come down here telling us how to do our jobs,” They protest. “And make our lives miserable. Why should we help you make our lives worse?”

The business process analyst means well, and really, really wants to work with the front-line employees, but they’ve been burned too many times by the process to commit to it.

The Net Effect: A Useless Process

The Business Process creators are disconnected from what the business actually needs to do. This disconnect is deadly for business: it makes work more stressful, wastes time and money and doesn’t contribute to “getting the work done”. This is why management will tolerate, if not encourage, workarounds.
Sign of a good business process: it makes your job easier. If your job is not easier, then the process is wrong and must be fixed.

How to fix it

Again, the fix is simple, but engage everyone involved in the process to help define it. Everyone who is affected by the process, either because they have to follow it, or they depend on what the process accomplishes, is a stakeholder and they should be listened to. Ask all your stakeholders the following questions:

1. Goals: What is your business trying to do?
2. Processes: How should you reach those goals?
3. Roles: Who are the people in the processes that do the work and make sure it gets done?

Case Examples

At my work, the worst example is the development process management tried to force on us. Aside from the fact there was no process—just a list of documents and templates we had to deliver—the process itself did not reflect the way good software is delivered anymore. In the words of a contractor I worked with on a projected affected by the new development process: “It’s like a throwback to the 70’s.”

Unfortunately, that didn’t stop the Process Nazi lady from coming to audit my project and making our lives hell because we didn’t use the new template for the TPS reports or delivered delivery 3FC102 when it was clearly stated in the custom tailoring waiver sheet we had to have it. Ignore the fact that deliverable 3FC102 was an obscure technology delivery requirements design whose examples were for large-scale Enterprise deployment.

The process was designed at the very top then forced down on us. No one ever came to ask us what we thought of it or what our needs were! Oh well, just use these two crappy tools and try your best to do it.

One of the tools, an Excel spreadsheet-based estimator, was so out of touch with our team, my manager said we should come up with the estimate our selves then figure out how to “fudge” the spreadsheet to reach that number.

It’s not a big surprise that they’re changing the development process again based on feedback and getting rid of the two tools we used before.