During any BPMS demo, the vendor will demonstrate how the application handles the review and approval cycle of some work product, e.g., a document, form, or report. Review and approval of these products is a process cycle that all businesses share, and in my opinion, one that’s entirely too common. Reviews aren’t disappearing anytime soon. They are in some cases a necessary evil. However, let’s be clear – reviews aren’t value added activities.
During any BPMS demo, the vendor will demonstrate how the application handles the review and approval cycle of some work product, e.g., a document, form, or report. Review and approval of these products is a process cycle that all businesses share, and in my opinion, one that’s entirely too common. Reviews aren’t disappearing anytime soon. They are in some cases a necessary evil. However, let’s be clear – reviews aren’t value added activities. When highly paid knowledge workers are spending time on these cycles, they aren’t adding to the bottom line.
All too often, reviews are purely administrative. Accounting checks to see that the math is right, then sends it to someone that ensures all sections are complete, who in turn sends it to a manager who confirms that the employee did, indeed, check it thoroughly, approves it, and passes it on to… You see where I’m going with this. We have what a former manager of mine used to call “checkers checking the checkers”. Sometimes multiple groups check a product for the same thing, but more often, each group has a specific, unique task.
There are times when reviews are entirely appropriate. However, they might mask deeper issues, and be a symptom of these common organizational ailments:
- Unclear or badly articulated business rules – When the creator of a product does not have specific, measurable, and exact specifications for what the product looks like when it is defect-free, they cannot deliver a defect-free product. This often leaves the downstream organization to check it for what they know to be correct, but which they haven’t articulated to the upstream supplier.
- Withholding organizational knowledge – Leaders should strive constantly to drive decision-making and organizational knowledge to the lowest levels in the company. A proliferation of review and approval cycles can signal that managers or departments are not sharing the knowledge required to make decisions at lower levels. This sometimes is intentional, but most often is a side effect of ailment #1.
- Lack of strategic direction – Where there is a frequent need for review and approval by executive management, beware. This might be a sign that the leadership hasn’t provided specific strategic direction to the tactical levels beneath. Effective communication linking mission, goals, and strategy allows those responsible for execution to act autonomously in most circumstances.
- Undocumented processes – When people do what they do because that’s the way it’s always been done, and there are no visual representations of the process, it’s no wonder reviews proliferate. A process flow chart makes it easy to count the number of reviews.
- Someone got it wrong once, and someone yelled at us – You know the situation: eight years ago, the system that posted the customer address automatically into the customer address field failed. A manager got in trouble over it, and added a manual review step to the process the next day. IT replaced the system, and it has worked flawlessly for 7-1/2 years, but since no one remembers why the step exists, no one questions it.
Reviews often occur at the handoff of a product from one department to another. Keep in mind that every downstream review – and its associated corrections – enables the upstream department to continue to deliver a substandard product. What’s the incentive to provide excellence when another group will bear the cost of catching, and perhaps fixing, mistakes?
So, when is review and approval a good idea? Check against these two conditions, both of which must be met:
- The reviewer has a highly specialized expertise and
- The consequences of getting it wrong are dire.
Dire does not mean someone gets yelled at. Dire means executives landing in jail because the financial earnings report was wrong and they were out of SOX compliance. Dire means a gotcha clause in a contract cost the company a cool million. Accounting reviews and legal reviews are examples of when a review is necessary. Evil, in that it doesn’t add to the bottom line, but still is necessary. This also doesn’t apply to peer reviews. In highly specialized fields – application development, medicine, law, to name a few – structured peer reviews augment or take the place of quality assurance tests, or ensure reproducible results. Introducing a formal peer review process in an IT department is widely accepted as a way to increase the quality of the finished product – be it code, a design document, or a technical specification. No, here I’m referring to the mundane, administrative reviews that eat up time, delay through-put, and generally don’t contribute to a company’s mission. Reviews of this kind become less and less necessary when a company has well-articulated business rules, clearly communicated strategic direction, a lack of political dysfunction, well documented processes, and continual process analysis that prompts someone to ask “why?”
