There are two sides to me. There’s the go-to-work-every-day-and-pay-bills guy, and there’s someone longing to be in New Hampshire, where the state motto, “Live Free or Die,” is appealing.
The same is true of frameworks.
I want to be able to do things my way and “slam” things to production. Yet I recognize such anarchy (applied to everyone) will inevitably lead to a very shaky production environment. And when I hear of organizations where it takes longer migrating items to production than to do the development and testing, I want to pull my hair out.
A neatly dressed cable plant is a thing of beauty, readily maintainable:
And left to their own devices, sometimes you’ll end up with this:
So where is the dichotomy?
The issue is frameworks, such as Systems Development Lifecycles (SDLC) or IT Infrastructure Library (ITIL), applied indiscriminately, can cripple an organization.
My belief is you have to understand the framework, and then selectively extract those items appropriate for your organization (or an organization of your size.)
For example, ITIL describes a program change management process. Should a two person firm implement the exact same process as a 1200 person development organization? I would submit “no.”
Do I believe changes should be documented, understood, tested, released and verified regardless of the organization’s size? Of course. In the two person firm, a change management meeting can be accomplished over coffee…where a larger firm will need commensurately larger process.
The underlying tenants and directions are always the same…it’s the degree organizations implement items that varies.
As IT consultants, we see many organizations where the nuances of implementing processes are lost. And since processes are living things, they need occasional maintenance.
It’s rare we see an organization truly devoid of process (although undocumented processes, or “local practices,” are more common than one might expect.) We find helping organizations dial in the right degree of process key in “rightsizing” the process to the organization so they receive the benefits without being bogged down in a bureaucratic nightmare is a true value add.
When changing process, it’s important to analyze proposed changes and make sure the root cause is being addressed. We recently got a call from a client concerned their recently enhanced problem/incident process was failing. Quickly, we determined a process “role” went unfulfilled on a single incident. This does not mean the process is bad; to the contrary the process was right and all roles need to be filled.
By rightsizing process, and regularly evaluating effectiveness and appropriateness, we believe organizations can operate with high performance.
