Some people think processes are the silver bullet to every problem. “That wouldn’t have happened if a process had been in place and followed,” they say. Other people think processes are a waste across the board. “We did just fine before management started making us follow this process, and now it adds three weeks to our work,” they insist.

The big question is, how do we meet halfway? How do we show the value of business processes while not forcing people to choke them down? How do we establish guidelines for business process management and still let people do their jobs in the way they are most productive?

The Daily WTF had a recent post (albeit fictionalized) about how a blind adherence to processes completely eclipsed common sense. I can’t personally believe that the people in that story would be so ignorant as to lose an entire day’s work from such a simple matter, but at the same time, the story does have a point: IT stuff is not trusted as much as they should be, and the checks and balances in place can cause more trouble than they’re worth. That’s not the fault of “business process management.” It’s the fault of the people who put the processes in place, ensure they’re being followed, and carry out the work involved. In other words, everyone.

On the other side of the coin, there are untold numbers of success stories that involve business processes that work. We never pay attention to the things that go right; we only care about the things that go wrong. Never mind that the electricity stays on when you pay your bill, or that your car hasn’t been repossessed because the bank paid your check to your lienholder. We ignore these things because we take the processes for granted, and because they are someone else’s problem.

What do you do when the process is choking the life out of your work? You change it. I’m reminded of a story I heard in a computer science class I took a long time ago:

I worked for a shipping company for several years in the data processing department, and since I did a good job and my programs worked, I eventually got promoted to supervisor. My job duties included everything I was already doing, with some extra responsibility over the other data processing clerks.

One Monday I came into the office and my manager called me into his office. “John, we need to talk about one of your clerks, Bill. The computer says he has processed an average 24 large shipments over the past three weeks, and the minimum threshold for data throughput is 30 shipments.”

I knew he had been having some trouble at home with a sick child, so I didn’t push him to work harder. And I didn’t even know there was a “minimum threshold for data throughput.”

“We want you to let him go,” my manager said. I was shocked and tried to change his mind, but he had the hard data showing my coworker’s productivity.

A week later my manager called me into his office. “I see you didn’t let Bill go. I’m glad you didn’t because his output exceeds the minimum by a large amount. But next time, talk to me before you go against what I say.”

I couldn’t fire Bill. He wasn’t the problem. It was the program. Some programmer had made an arbitrary decision to set a default value for a variable to 30–the number of days in the month of June, when the code was written–and I changed it to ‘0′. The “minimum threshold” that my boss was talking about was the initializer for a counter that tracked all processed large shipments by a user. Since the code was testing for values less than that “threshold,” an exception was thrown. Someone had written a business process around the code, instead of the other way around.

I think the moral of his story is “common sense prevails.”

The laptop was delivered to me pretty bare, with just the standard install (Windows XP and Office 2003). I knew I wouldn’t have time to get it set up tomorrow in the office, and besides, it wouldn’t be fair to bill my customer for my time spent setting up my own machine, so I brought it it home and got it all ready for work tomorrow.

After I finished installing everything, setting my desktop background, and organizing my folders, I leaned back in my chair with a smug sense of accomplishment. Then it hit me: I have a meeting tomorrow morning at 8:30, and I’ll need to use my PC in the meeting to draw network diagrams. I don’t have any of the supporting documentation for the meeting on this new laptop. I got so caught up in the excitement of replacing my old one that I neglected to think about the risk of trading it in on the new one the night before a big meeting.

This is the kind of risk I point out on a weekly basis in my role in the PMO. People want to make changes to production systems and they think the changes are minor and easy, so they don’t want to go through the formal process we have in place. But the smallest change can quickly snowball into the biggest problem. One little oversight can cause a massive headache. And that’s where I am now.

I’ll be ok in the meeting tomorrow because I’ll go in earlier to get the files onto my machine. That means I have to get up earlier, and have a more stressful morning. That bit of unpleasantness could have been mitigated by simply waiting a day. I’m mitigating my risk by sacrificing some sleep.

Since I’m not a morning person, getting less sleep risks a tired afternoon, and my technical review board meeting is tomorrow afternoon.

Do you see where this is going?

I can represent the high level process rather simply.

Of course, there’s a lot of stuff going on in there, but it works at a high level. The detailed process is much more complex, and I don’t have a model for it yet because I haven’t figured out how to represent it in notation.

That describes, then, a larger problem: is my process so complex that it is too difficult to model? Or is the process flawed and should be redefined using a model-driven approach? The current method is a very manual process. My attempts to automate individual aspects of the process have proven quite difficult. That indicates to me that the overall process is flawed and needs to be redesigned.

I think I’m going to take a step back and analyze the technical review process with a more objective eye. That is, instead of looking at it in terms of "this is what we’re using, and it gets the job done," I’ll look at it as "this is a new process that has not been executed before." At the end of the day, the process should be easily understood by people who are not intimately involved with the actual work.

Perhaps at that point, the process will be clearly documented and individual tasks can be relegated to automated workflows. More on that later!