Archive
From Change Management To Change Prevention
Assume that in order to prevent chaos from reigning in your organizational processes, you design and place into operation a change management system.
In order for your system to be effective, the turnaround time (i.e. latency), from request to disposition better be low enough so that people will be motivated to participate in the system.
If, over time, you keep adding more and more evaluation rules to your system and imposing more and more pre-conditions (e.g. requiring a formal ROI analysis paper) on your proposers, your system’s latency will keep rising and its effectiveness at managing change (accepting the good and rejecting the bad) will keep decreasing. People will conclude that it’s just not worth their time to traverse your bureaucratic gauntlet. In the extreme case, your system will automagically morph from a change management system into a change prevention system – and you may not even know that it has happened.
Taking The Low Road
In the pic below, I prefer taking the low road over the high road.
So, now that you and your accomplices have labored long and hard to transform your standard org into a high performing org, you’re happy as a clam. Whoo Hoo!
But wait! What happens when you inevitably team up to do business with a standard org? D’oh! I hate when that happens.
Durable, Resilient, Adaptable
I really love this elegantly written paragraph by Stewart Brand:
The combination of fast and slow components makes the system resilient, along with the way the differently paced parts affect each other. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power. All durable dynamic systems have this sort of structure; it is what makes them adaptable and robust. – Clock Of The Long Now – Stewart Brand
If you think about organizations, the people at the bottom of the hierarchy should be the fast components that instruct and inform the slow controlling components at the top, no? However, if those at the top allow, or turn a blind eye to bureaucratic processes and procedures that impede quickness at the bottom, they’re screwing up big time, no? Requiring the builders dwelling in the cellar to jump through multiple, multi-layer review/approval cycles to purchase a 5 dollar part, or go to a conference, or get a custom, but simple, cable built, or add some useful code to a widely used library, can be considered an impediment, no?
Ninety percent of what we call ‘management’ consists of making it difficult for people to get get things done – Peter Drucker
If those at the top of a borg solely concern themselves with “the numbers“, bonuses for themselves, and rubbing elbows with other fellow biggies while the borg’s so-called support groups and middle managers stifle the builders with ever more red tape, then fuggedaboud having any fast components in the house. And if Mr. Brand is right in that resilient, durable, adaptable, learning systems require a mix of fast and slow components, then those at the top deserve the results they get from the unresilient, undurable, unadaptable, and unlearning borg they preside over.
The Long And Winding Road
Manage-ification By Growth
Somewhere on the road from small startup sensation to huge institutional borgdom, the oft-repeated process of “manage-ification by growth” fires up and kicks into high gear. It’s inevitable, or is it?
A Bureaucrat’s Dream
Thanks to powerful, vested interests and ignorant leadership, some stodgy dinosaur orgs still cling to a bevy of high-falutin’, delay-inducing, product conception/development/maintenance processes. Because of the strong nuclear forces in place, it’s virtually impossible to change these labyrinthian processes – despite those noble “continuous improvement” initiatives that are seemingly promoted 24X7.
The state transition diagram below models a hypothetical schedule and budget busting maintenance process. But beware! Since BD00 likes to make sh*t up, the 5 role, 12 step, bureaucrat’s dream is a totally contorted fabrication that has no semblance to the truth.
Of course, some classes of discovered product defects should indeed be run through the ringer so that they don’t happen again. But mindlessly requiring every single defect (e.g. a low risk, one-line code change?, formatting violation?, documentation typo?) to plod through the glorious process is akin to using brain surgery to cure a headache.
Many of these process worshipping orgs can save a ton of time, money, and frustration if they “allowed” a parallel JFTDT process for those simple, low risk, defects discovered during and after a product is developed.
But no! In zombie orgs that have these types of beloved processes in place, it can’t be done. Despite the unsubstantiated and outrageous BD00 claim that the vast majority of discovered defects in most projects can be safely run through the insanely simple JFTDT process, anyone who’s not the CEO that thinks of advocating for a parallel, streamlined process should think twice. No one wants to be the next dude who gets shoved through the hidden JSTFU process.
The Org Is The Product
Someone once said something like: “the products an organization produces mirror the type of organization that produces them“. Thus, a highly formal, heavyweight, bureaucratic, title-obsessed, siloed, and rigid org will most likely produce products of the same ilk.
With this in mind, let’s look at the US DoD funded Software Engineering Institute (SEI) and one of its flagship products: the “CMMI® for Development, Version 1.3“. The snippet below was plucked right out of the 482 page technical report that defines the CMMI-DEV:
So, given no other organizational information other than that provided above, what kind of product would you speculate the CMMI-DEV is? Of course, like BD00 always is, you’d be dead wrong if you concluded that the CMMI-DEV is a highly formal, heavyweight, bureaucratic, title-obsessed, siloed, and rigid model for product development.
The Accumulation Of Rules
According to that dumbass BD00, in any given level in an institutional hierarsy, the number of internal org rules a member of that level is required to follow is a function of the number of levels above. Each level makes some rules for the levels below. Relatively speaking, the dudes in the head shed have to follow zero rules and they concoct the “high level” rules for the levels below them.
As one travels down a dysfunctional hierarsy, the number of rules to be obeyed is cumulative. By the time you’re down in the bilge room, the number of written and (especially) unwritten rules to follow is essentially infinite. The irony is that while the unfettered infallibles at the top keep piling on the handcuffs, they’re also simultaneously professing their love for empowerment, taking-initiative, dedication, trust, loyalty, yada-yada-yada.
T’is what it is, just another paycheck-for-repression tradeoff. You can’t have your cake and eat it too, so suck it up soldier!
The Real Customer
In “12 ‘best practices’ IT should avoid at all costs”, InfoWorld‘s Bob Lewis asserts:
I enjoy Bob’s books and columns, but I have to side with the likes of Russell Ackoff and Vineet Nayar on this one. All of an org’s “enabling” functions: HR, QA, Finance, Purchasing, IT, etc; should indeed serve the direct revenue-generating business functions and treat them as paying customers. Otherwise, the natural tendency of these groups in hierarchical orgs is to turn into obstacle-inserting, unresponsive, monopolistic dictatorships. Of course, in the “real world” this rarely happens because rational adults are in charge – and Bob is right. What is your opinion?
Temporary Enlightenment
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 