At least, I like Lean when it's applied within its proven domain, which is process optimization. And that's in spite of the nearly Messianic fervor of some of its proselytizers, not to mention their annoying decision to build their impenetrable jargon on a Japanese vocabulary, instead of the gratuitous Latin that lawyers and George Will prefer or the three-letter acronyms all right-thinking people use.
But I digress ...
Lean has discovered that IT's traditional waterfall methodology is a batch-and-queue process, making it Bad (clue: It's in English, as opposed to chaku-chaku, or single-piece flow, which clearly is Good as it's Japanese). Waterfall is inferior to what we had been calling, in our unenlightened way, agile or adaptive methodologies until the Lean experts came along to point out the virtues of kaizen-driven Lean Software Development (LSD -- see "Too mean about Lean?" KJR, 2/9/2009) for more). Which looks a lot like Agile except for the Japanesisms.
As I say, I like Lean within its proven domain of process optimization. Lean Software Development (LSD) annoys me for two reasons. First, its proponents present as new and brilliant some ideas that have been in productive use for decades. Iterative and incremental design weren't even new back in 2001when "Agile" first gained recognition as a "real" alternative.
And second, no matter how well LSD achieves its goals, it starts with the wrong goal, as Lean proponents should know better than anyone. According to www.poppendieck.com, which I'm told is the authoritative source on such matters, LSD's first goal is to eliminate extra features ... "We need a process which allows us to develop just those 20% of the features that give 80% of the value."
It's a classic case of hitting the bulls-eye but aiming at the wrong target. Software is, after all, an enabler of value, not a creator of value. What it enables is more effective business process and practice. Which means there is no such thing as a one-to-one mapping between feature and value. Software needs to perform its roles as described in the process map. 80/20 has nothing to do with the subject.
Why can't the Lean folks leave us alone and pick on someone else instead, like Accounting?
And, in fact, they are (if you're interested, "Lean Accounting: What's It All About?" by Brian H. Maskell and Bruce L. Baggaley summarizes discussions from the 2005 Lean Accounting Summit, providing a useful overview). And yet ...
Two aspects of Lean Accounting appear most notable (which to a member in good standing of Sarcastics Anonymous means they're the easiest to ridicule). The first: Here's one of the most damning accusations of traditional accounting the Lean Accounting movement can make: It has, "... no good way to identify the financial impact of the lean improvements taking place throughout the company."
Feeling unappreciated in the financial reports? Aw, that's too bad. And yet, here's a piece of advice you can take to the bank, whether you use traditional or Lean accounting to make the deposit: Under no circumstances should you allow a process improvement consultant to define the metrics used to assess improvement.
The reason is easily stated: Doing so violates the first principle of internal controls, which is separation of function. I have personally watched process improvement consultants design new processes, develop the metrics, implement the new processes, demonstrably improve the metrics, all while seriously damaging the enterprise.
But because they defined the metrics, they were able to conclusively "prove" that the pain everyone was feeling was merely their supposed innate resistance to change. Cycle time had, after all, measurably and dramatically improved.
That the new process had cut throughput in half was irrelevant -- an invisible, unmeasured consequence.
Let's just say the Lean Accounting movement would have been more convincing had it phrased this criticism of traditional accounting in a less self-serving fashion. Call it a quibble, and leave it at that.
Here's something that isn't a quibble: Lean Accounting wants to correct a laundry list of issues while leaving the most notably un-Lean aspect of traditional accounting intact: The month-end, quarter-end and year-end closing rituals that build batch-and-queue processing into traditional accounting's heart.
Years ago, in Bob Lewis's IS Survival Guide (MacMillan/SAMS, 1999) I told the tale of Martian colonization: Five years after the first settlers arrive a Martian corporation opens for business. Five years later the last terrestrial corporation shutters its doors, unable to compete with the Martians.
The Martian competitive advantage? Half the number of year-end closings.
Lean Accounting strives to make period closings easier, when it should be working to eliminate them.
It's akin, as someone once said in a different context, to performing the face lift but leaving the hairy mole.
This week's KJR CIO Conversation asks whether separating process improvement and process metrics responsibilities is as important as stated here. Share your thoughts, opinions or war stories -- you'll find the thread here.
Copyright 2009, IS Survivor Publishing, all rights reserved.
Comment on this article
Only registered users can write comments. Please login or register.
