11.2 Production Support Models

< Day Day Up >

At least, that is what operations people think, because their reality is different from ours. Project managers like to slam-dunk everything, but the operations group will slow you down to a crawl because of the way they work. In my view, two flavors of production support exist in corporate America.

11.2.1 Historic Model

A very finite size staff labors, sometimes heroically, to fix things after they break. They have little time for planning. Most of their forward thinking is speculation on their next disaster. Many fixes applied on an emergency basis are Band-Aids™, so nothing is ever really finished or completely documented. This is not a criticism, by the way, but an observation regarding the fragility of technology and the stop and go nature of supporting it. A good analogy in the mundane world is the busiest road you can think of, probably the one on which you commute each day. We all grumble about potholes, lousy signage, and too few lanes, but when is there time, assuming there is money, to maintain or upgrade the beast? Do you want them to shut down 80 percent of the lanes during the day when you are using them? Or do you want to pay prohibitive tolls or taxes to subsidize costly night work so you won't be inconvenienced? You probably do not want either option.

The information technology (IT) maintenance and support organization faces similar challenges. As you might expect, these people have some-what harried and defensive temperaments to go along with their jobs. From a project manager's perspective, it takes special social skills to earn their trust before getting much value added from them. The good news is that you can sometimes get things done through negotiation and quid pro quos, and you do it in stealth mode (letting your conscience be your guide, of course).

11.2.2 Emerging Model

The other operations model is the direct opposite of the first. This one is a heavily process-oriented way of doing business, something you may have experienced in the mainframe world. The way this model works is by the book. You have to fill out umpteen forms to move or install new servers, make changes to existing equipment, get a new router port configured, or be granted a firewall exception. This process can be extremely lengthy and rather abstruse to the average project manager. The waiting part of the cycle may be weeks for a task that literally takes moments.

If you think about it, this approach is extremely logical to the operations manager who wishes to avoid being bullied into reacting to everyone else's emergencies. Therefore, to some degree, the convoluted paper chase is like quills on a porcupine (i.e., intended to repel the hunter, not make the carnivore's job easier).

The other troubling aspect of this model is the operations paradigm that has increased in popularity to the point of domination in today's environment. Because IT operations are tricky and expensive, someone has sold executive leadership on the idea that support should be automated and generic. The strategy states that call center machines can be programmed to automatically generate alerts based on predetermined, self-diagnosing actions by the possibly "troubled" network elements, servers and applications. Further, a technically unskilled "analyst" can react to those alerts with choreographed actions, which basically boil down to dispatching specified personnel. One of IT's dirty little secrets is that the same harried technician we just said has little time is the person generally dispatched by the multimillion dollar support center! This individual cannot be assumed to be an expert on everything, so he or she may only be the first step in a long list of phone calls, customer complaints, and meetings to calm everyone down before the problem eventually goes away.

< Day Day Up >