/kevinbehr/home

 “I wish we had dedicated project resources. I am so busy with operations that I just don’t have time for projects.”

“Why does every IT issue get escalated to my top network and security people?”

“I don’t care if you have enough time. I need this stuff done now.”

“It takes me more time to fill out a change request than to make the actual change”

“We spend over 70% of our time doing operations which only leaves me 10-15% to work on projects after I read my email”

Sound Familiar?

I love the provocative statement that Goldratt made (I paraphrase):

“Technology CAN (not does) provide value IF and only IF it diminishes a business constraint.”

Before you go off emailing me that technology has many other values please reflect deeply on this statement.  Please reflect deeply on what business value IT provides. 

I love the notion of continuity that the “diminishes” brings to the statement.  In other words the constraint must be continually diminished as opposed to the word vanquished.

In order for the constraint to be continually diminished the technology must operate without ceasing or the constraint is re-introduced and the business is forced to deal with the issue once more, usually without any warning.

One could argue that not all applications in service deliver the best business value. But for the purposes of this discussion on IT operations let us assume that everything we are running in our datacenters provides the business with some critical constraint-busting capability.

By doing everything we can to ensure that those systems continue to operate free of interruption we are performing IT operations that support business operations.

The basic definition of Operations is “The act of harvesting value from resources”.  More specific to IT I believe that IT operations represent our collective approach (strategy) and tactics (tasks, instructions, and programs) designed to prevent outages and interruptions to the IT services that existing business operations depend on.

Since the whole point of business operations at large is to produce profit (or achieve the mission for you non-profits) from its resources, when we perform IT operations successfully we are protecting business revenue generation.  I like to call it “protecting revenue” for short

You may notice that firefighting, support or outages did not appear in my definition or mission of operations.

This is very important.

When we are troubleshooting, or firefighting an outage, operations have ceased and we are now in recovery mode (attempting to recover operations).  Even if the issue is service impairment versus a full blown IT black-out we are attempting to recover from the situation and therefore are not in nominal operation. Both scenarios interrupt or affect business operations and can put revenue at risk in many ways.

So if you were really spending 70% of your time in operations..Do you think there would be so much chaos?

Next Post I will talk more about defining and measuring operations and the value it can provide. 

kb

Have you ever read “The Mythical Man-Month: Essays on Software Engineering“?

If so you are a rare bird (or over 45) in today’s tech zoo.

I wish I could drop this book (among many others such as The Goal, Critical Chain, The Machine that Changed the World, Great Boss Dead Boss, and Chasing the Rabbit  - see the right side column to buy them!) out of airplanes and organize study groups with my IT; operations, security, audit, project management, executive management and yes especially development brethren.

I was reflecting on this text and several other seminal management books I have collected over the years and I decided I needed to write a series for my blog on this topic. As of late Gene Kim and I are working on some amazing projects for fun and exciting internet 2.0 companies. We have been writing a new IT management novel with George Spafford (think “The Goal” for IT) , and helping a bunch of IT shops solve the quality, reliability and cost reduction realities that have now become must-do (all at the same time mind you).

Just yesterday we began working with long time collaborator and joyful subversive, Eileen Forrester, from the Software Engineering Institute at Carnegie Mellon University.

We are shaping up a few writing projects for the newly released CMMI-Service model.  Eileen has been in charge of getting the new model released on time and has actually over-performed and it is out much earlier than expected for the first time in history.

I relish the opportunity to exchange ideas and approaches for improving the delivery of services with folks from all sectors of the economy (especially those disciplines outside of the IT world).

Many of these industries and business disciplines have a long history of systems design and improvement that reads like rich history.

Where is this similar lineage taught and practiced for IT today?

As I work with many IT executives and teams around the globe I often find myself wondering if the collective “we” has forgotten more than we have learned up to this point.

For a community that not only leans towards scientific interest our entire profession exists on the shoulders of science (knowledge and technology are the output) so little of the way we actually do IT is built on the scientific method or around what I have dubbed the “System Building and Continuous Improving Arts” (SBCIA).  We often are just reacting rather than treating every request as a hypothesis and making sure we have built a repeatable response that correctly satisfies all of the implicit assumptions in the request.

To better explain what I am talking about I will use the Japanese term RYU, which denotes the flow of water.  The idea represents formal Japanese traditions such as the Martial Arts.  In Karate fluidity and finding one’s path are compared.  Water will find its own path in balance with the terrain it is surrounded by, just as the Karate student must advance through his or her path by practice and training.

Bringing me to the point of my concern in this post…

Much of “the path” for IT practitioners and managers of all levels travels through the acquisition and appropriation of myopic technical domain knowledge (yes even auditors). In other words “what we must know” so “we” know how to react in a given technical situation”.

What is missing?  What we need to understand holistically (see) to decide how we should work together as a system .  This information is both timeless and too time consuming to amass through trial and error in our own life experience. The old adage applies here “Time may be the best teacher but it kills all of its pupils”. In order to amass the collective wisdom about how to see the work in order to build an effective system to do the work, we need the collective wisdom of our predecessors and our current community at large. We also need to look outside of our industry and find analogs to improve our execution, quality and safety with larger and scientifically validated levers. Stop chasing consensus based “Best Practices” and start purpose-building systems around scientifically proven practices.

There is much room in IT to build a new flow of knowledge about the “System Building and Continuous Improving Arts” (SBCIA).  This economy is shaping up to be the ultimate Dojo for us to do so.  Let’s just say performance is no longer optional but survival is.

So pick up a copy of “The Mythical Man-Month: Essays on Software Engineering” and start a study group and learn from your ancestors.  Create a culture of Kung-Fu, a Chinese term that means “individual accomplishment or skill cultivated through long and hard work” .  Set the tone with your team and define skill from a systemic and improvement standpoint rather than merely a technical one.

Check out the books in the far right column on this blog to find a handy DOJO compendium to get you started on this journey.  If you are serious about improving IT flow, reaping the drastic cost savings, increases in project execution and infrastructure reliability that result, feel free to contact me about mentoring and staff coaching.  It really does make a huge difference!

If you have stumbled upon a nugget on your journey please let me know I am @kevinbehr on Twitter - join the conversation!