What If...We don't have a process owner?

Quite simply, you lose. You can invest as much time and effort in process definition and mapping as you wish. You can commit a team to assessments, gap analysis and process mapping exercises. You can define the objectives, KPIs and KGIs and then document and publish your process. But without a process owner you will not be able to:

• Identify a single "go-to" person to hold accountable for the process


• Know who is qualified and authorized to make changes to the process


• Update the performance and indicator metrics as business conditions change


• Mature the process to accommodate changing customer, business and IT needs


• Drive continuous improvement to the process


• Get buy-in for use of the process by those who would prefer doing business they way they always have


• Mature the process as personnel become more skilled and automation is introduced


• Expand the process scope to other business or regional segments


• Train users, customers and management in the use of the process


• Manage the process for success


• Pro-actively identify risks to the process


• Know when the process is in control and, perhaps more importantly when it is about to go out of control


• Survive an audit


• Ensure consistency in the process output


• Manage, control and ultimately reduce costs by removing process inefficiencies


• Achieve broad and effective integration of processes

Now, do you think it is important to identify a process owner? Not only is it important, it's vital. Yet one organization after another insist upon working on their processes with no clear understanding as to who will own them. Or, they appoint a single individual with process ownership responsibility across all processes. That's unfortunate, as it is hardly reasonable to expect a well qualified Incident Management process owner to be equally effective in Capacity Management.

You must treat a process as a living, breathing entity. Processes must nurtured and cared for so they will evolve and grow in alignment with changing business conditions and technology. It does no good to spend time on a process only to have it gather dust, age and progress into obscurity and irrelevance. Unlike fine wine and Italians, processes don't get better with age - particularly if they are neglected.

Customer Service-Does It Pay?

YES! Customer Service does pay. OK, so if all you want to know is the answer, there you go. I wouldn't be writing this if I didn't believe it. If you're still reading but have a few doubts, bear with me as we explore a lesson from the retail market of, oh, say laptop computers.

What is it about an Apple computer that creates such passionate, almost fanatical loyalty among a certain portion of its user base? Consider simple customer interface elements such as the tactile sensations transmitted through the keys, the feel of brushed aluminum, the appearance of the screen, illuminated keys, the elegant simplicity of the interface. A course ware developer with whom I was working last week uses both PCs and Apples. She says she likes her PC but she loves her Apple. The word "love" seems out of place in our cold, impersonal world of technology bits, bytes and hardware. But it's no more irrelevant than customer service. So let's think of love as that ephemeral quality that conveys a sense of "value-add" which builds loyalty. Lest you think this is not important I invite you to read a Financial Times article about HP and Dell ( Fashioning an image revolution for humble PCs ). These two manufacturers have finally come to realize how design that enhances the customer experience is important at the bottom line, in capturing (and maintaining) market share and ultimately profitability.

All of these features impact the customer at the critical point that really counts - the customer interface. For years I have advised my clients to place mirrors next to the phones of their Help and Service Desk agents to remind them to smile before answering a user call. Such practice changes the tone of the support technician's voice so very subtly. But the smile, conveyed through an altered tone of voice, can be heard by the caller on the other end of the phone.

There is an attitude among some in technical support (and I say "some" as this most certainly does not apply to "all" technicians out there - many of us DO get it) that seem to think jeans, tennis shoes and a "T" shirt are appropriate attire for their support function. I hate to burst the individualistic, "this is me-accept me the way I am" bubble, but attire must meet a certain level of professionalism. Why? Let's go back to the point of interface, the moment of truth at which the customer interacts with technology, or in this case, engages the technology department. The customers of an internal IT organization are professionals. They expect to be served by professionals. And in fact, if your organization is trying to align with the ITIL principles, your IT organization is, or soon will be, a professional organization. It only makes sense that, as a representative of a professional organization, you dress like a professional. Yes, yes, there are exceptions-if you're crawling around under a raised floor, running cabling through the ceiling or what ever. In such situations you do need to dress for the job. Similarly, if you are visiting a customer, dress the part for that job if at all possible.

But even if you cannot dress as you might wish to serve your customers, remember to act as a professional in the way you speak to and work with your customer. You may be the only experience the customer will ever have of working with IT. Those impressions have a way of becoming lasting perceptions. Such perceptions are very quickly transmitted through through the informal communication channels (grapevines) of the various business units that comprise your customer base. These customers, one way or another, are paying your salary. Their perception of what they are getting for this money is influenced by your appearance, attitude and demeanor. I wrote earlier about outsourcing ("Save Money - OUTSOURCE!" - Tuesday, September 11, 2007). Too often business sees support as a line item expense not as a value-add. Support is an easy target for outsourcing. Why add to the ammunition? Build customer loyalty by enhancing the user experience with your services.

Fable for Our Times...

The following was forwarded to me from an unknown source by my friend Mark (thanks Mark!). It captures the essence of the dilemma burdening our culture.

A Fable for Our Times

A Japanese company (Toyota) and an American company (General Motors)
decided to have a canoe race on the Missouri River. Both teams practiced
long and hard to reach their peak performance before the race.

On the big day, the Japanese won by a mile.

The Americans, very discouraged and depressed, decided to investigate
the reason for the crushing defeat. A management team made up of senior
management was formed to investigate and recommend appropriate action.
Their conclusion was the Japanese had 8 people rowing and 1 person
steering, while the American team had 8 people steering and 1 person
rowing.

Feeling a deeper study was in order, American management hired a
consulting company and paid them a large amount of money for a second
opinion. They advised, of course, that too many people were steering the
boat, while not enough people were rowing.

Not sure of how to utilize that information, but wanting to prevent
another loss to the Japanese, the rowing team's management structure was
totally reorganized to 4 steering supervisors, 3 area steering
superintendents and 1 assistant superintendent steering manager. They
also implemented a new performance system that would give the 1 person
rowing the boat greater incentive to work harder. It was called the
'Rowing Team Quality First Program,' with meetings, dinners and free
pens and a certificate of completion for the rower. There was discussion
of getting new paddles, canoes and other equipment, extra vacation days
for practices and bonuses.
The next year the Japanese won by two miles.

Humiliated, the American management laid off the rower (a reduction in
workforce) for poor performance, halted development of a new canoe, sold
the paddles, and canceled all capital investments for new equipment. The
money saved was distributed to the Senior Executives as bonuses and the
next year's racing team was "out-sourced" to India ...

Sadly, the End.

However, sad, but oh so true! Here's something else to think about:
Ford has spent the last thirty years moving all its factories out of the
US, claiming they can't make money paying American wages. Toyota has
spent the last thirty years building more than a dozen plants inside the
US

The last quarter's results:

Toyota makes 4 billion in profits while Ford racked up 9 billion in
losses. Ford folks are still scratching their heads.

Comment:
In the training and orientations I do for our clients I typically introduce the Toyota Production System as a tangible and real-world example of practical, applied efficiency improvement that has yielded bottom-line results. I then present the irony...TPS is based on the Deming improvement methodology (Deming Method). Edwards Deming was an American statistician sent to Japan under the Marshall Plan after WWII to help them rebuild the Japanese economy. Prior to going to Japan he approached the Big 3 but was rebuffed: "We don't need no stinkin' quality; we've got market share." Today, Toyota has the lowest defect rate per 100 vehicles manufactured among the major automotive manufacturers, has replaced Ford as number two in sales volume and is on track to displace Chevy as the single best selling brand in the United States. As to R&D: they're positioned to dominate NASCAR, an American tradition, in the next two years. Toyota listened, the Big 3 didn't.

These basic principles of quality, the underlying principles, such as efficiency, fact-based decision making, lean manufacturing and management accountability have been around since the 30's and 40's. Interestingly, of Deming's famous 14 Points concerning quality, half of them identify management responsibilities (or point to management's negligence) as critical factors in quality systems. In Deming's day, as today, corporations were blaming the production worker for defects when, in fact, in most cases it was the system within which the production worker operated. The production worker has no control over the system. Only management can change that.

Save Money - OUTSOURCE!

I heard a commentator on CNBC this morning refer to the recent credit crisis as symptomatic of our "microwave" culture. You just have to love that term. It captures the shallowness and immediate gratification that has come to be accepted as the norm for many of our corporations. We see it in everything particularly outsourcing. Indeed, outsourcing can save money. But use of outsourcing as a solution does not (NEVER!!!) absolve the outsourcing organization of its responsibilities in managing the relationship and, more importantly, understanding what they are outsourcing in the first place. This is true for application development as well as data center operations. One might think that outsourcing should not only reduce costs but, at a minimum, maintain current service levels. This cannot happen under an outsourcing contract, though, for two reasons:
1. It is impossible to capture all that a dedicated internal team does in contract language that is acceptable to both parties to the contract.
2. The contract itself becomes the upper limit of the work effort.

When the manager of a development effort who does not understand the task he or she is outsourcing, makes the decision to outsource, too much falls through the cracks. The work that may have been done by a dedicated team is rarely fully understood or documented. It then cannot be translated into a contract that represents all that the team was doing for the project. It is nearly impossible to capture every nuance of effort expended by the team. Even a well-meaning manager cannot possibly account for everything in a contract. The outsourcing arrangement then, represents only a portion of the work actually being executed by the in-house development team.

Once the contract governing the work of an outsourcing arrangement is drafted and agreed to, not only does it fail to account for all the work that is done, but it becomes a limiting constraint to realizing the quality that may have been produced by an in-house development team. The reason is quite simply the nature of business. The outsourcing team will typically work only to the limits permitted under the contract. They will certainly do no less than called for, but they will most certainly do no more. Thus, while the existing service levels may suffer, improvement most certainly will suffer. There is seldom any incentive for the outsourcing team to drive improvement.

There is a third reason we accept less than optimal quality in our outsourcing arrangements. Since the primary motivation of outsourcing is cost savings (and is often done to pad the managing executive's resume with high-profile - albeit short-term - accomplishments), too few organizations will demand an internal process owner with the required skills, authority and motivation to own and improve the process. This sounds too much like overhead! I know from experience that the cost of outsourcing what you don't understand (and for which you don't have an accountable, internal process owner) is higher than taking the time to first understand the process and identify a process owner. To be successful, the process owner must then be allowed to manage the process and endowed with all the authority implied as a process owner.

Aggravating Transactions? Why Didn't We Ask the Customer First?

ComputerWorld's September 3 issue carried an opinion piece that demonstrates, so vividly, just how backward many organizations can be when it comes to process. The article describes a bank, which was determined to be "customer focused." Apparently they turned to technology to "make it happen" by implementing a CRM system. The design was to ensure that the branch bankers could offer, "the right products every time they interacted with customers" (ComputerWorld, Sept. 3, 2007, p. 30). As I might have predicted, the technology failed to do anything but upset the customers. This is a perfect example that I have seen over and over-technology is implemented with no insight, understanding or even the slightest consideration of the customer needs: only those of the business. The business knew what they wanted. But they didn't take the time (didn't budget for) to understand the customer. Somehow industry today seems to think that every problem has a technology solution and just by putting code in place, the problem will be resolved. The article goes on to describe just what a mess this b-ass a-kward approach created.

Unfortunately, the author of the opinion missed the point of the whole case. As I read this piece, he claims that "...process design works against this kind of re-vamp. IT needed to step back from technology and envision the future...". OK, I agree that IT needed to step back. But it needed to step back further than he suggests. Process design DOES NOT work against such an effort if, in fact, the process design is executed by a professional with an understanding of how to capture the "voice of the customer." THAT, not technology, is where you start such an undertaking. I am regularly amazed at the number of organizations that refuse to talk to the customer first: to establish the criteria that will become the specifications for the solution. Is it fear? Are they afraid to talk to the customer? Or do they just not know any better?

I find it amazing, and a wee bit amusing, that many organizations never have the money to understand the customer before setting criteria that will dictate code that will ultimately impact the customer. Yet they find the money for a "do-over" once the initial effort fails. This, however, costs them in terms of Good Will. On the surface it's an intangible. But it's a real cost. Put a price on that will ya!

A Capacity Management Lesson From the Airlines

Simply amazing! The airlines, to no one's surprise, are a mess and will only getting worse according to an article in Business Week (Fear & Loathing at the Airport). And the solution is not simple so the FAA commissioner will now, after five years in the role, admit defeat in her efforts to fix the system. Is it really so complex? It seems that our flights are delayed because too many flights are arriving and departing at the same time. (Pardon me, but, "DUH!"). No one is in charge of ensuring that the individual airlines don't over tax the existing capacity. In IT we would call the solution, "differential charging." We would charge a different rate for use of our existing capacity during peak times. The overcrowding at peak times in New York and Chicago can be resolved by a simple scheduling mandate: Once the maximum number of flights that may depart during a specific period is reached, no other flights should be scheduled for departure. The article even admits the simplicity of this idea recommending that peak hour departures be auctioned off. That way, if an airport can handle only 47 departures during a specific day part, then only 47 can be scheduled.

But the airlines are whining about this proposal because it may cost too much. They all want to schedule the best flights for the best, customer-preferred, times. Enter DIFFERENTIAL CHARGING. If I HAVE to depart at a peak departure time, then CHARGE ME for the privilege! Let the free market regulate.

If that's not acceptable, then it's technology to the rescue! The future is satellite-based GPS! When? How much will that cost? What would a good data center manager do if he or she couldn't wait for budget approval to install new technology? D-I-F-F-E-R-E-N-T-I-A-L C-H-A-R-G-I-N-G. Not that the technology upgrade isn't need. It is. But what are we going to do in the interim?

Oh, but there's another problem: No one individual, agency or organization is in charge. So, you're telling me that the airports have no control over the use of their own capacity? Hey, IT folks, does this sound familiar? I'll ask again, what would a data center manager do given a similar challenge?