In IT, the ITIL library of processes and best practices is bringing attention to process optimization. That's very important. But some practitioners have attempted to implement ITIL by designing structure around those processes. Here's an example:

With some critical internal processes in need of attention, a CIO tried a process-centric structure. He dedicated groups to each major process within IT to minimize "hand-offs."

The structure included these groups (and a few more):

• Ruth, applications development process
  
• Bob, infrastructure engineering process
  
• Matt, incident management process
  
• Art, operational service delivery process

Silos and the Loss of Specialization

Optimizing processes is a good thing. But this structure created "silo" groups for each process, each containing the various specialists it needed. It scattered the "campus" of similar professionals.

Multiple processes require the same skills. For example, Ruth and Bob both needed database experts.

And there was a third group that also developed overlapping technical expertise. Matt's service desk took help-desk calls and managed incidents. Ruth and Bob only became involved if Matt's staff couldn't handle it, and they saw this as a distraction from their own processes. Not getting the responsive support he needed, Matt's staff developed engineering expertise, a "mid-tier" of support more specialized than his front-line call center staff but without the depth of Ruth's and Bob's engineers.

With each little group trying to cover all needed engineering disciplines, they all became less specialized, and hence less effective. And with each specialty replicated in each group, redundancies occured. Costs rose, quality suffered, and the pace of innovation slowed.

To try to mitigate this problem, the CIO declared Bob the "center of excellence" for database engineering. The charter of this group was to serve all the processes. But in practice, it served its boss first. Bob naturally preserved his resources for his own initiatives. Since he was less responsive to his peers, Ruth's duplicative database groups never went away.

Disempowerment

Furthermore, the structure was disempowering. Staff couldn't be managed by their results, since no one was responsible for the IT organization's products and services.

For example, Ruth, Bob, and Clara were all involved in developing applications; but no one group was accountable for delivering fully operational applications, or for the organization's strategy with regard to applications.

Similarly, Art was responsible for operational processes, but not for the resulting infrastructure services. It wasn't his job to ensure that the infrastructure-services business was working well; he just managed the service delivery process. This structure undermined accountability, entrepreneurship, and customer focus.

Don was responsible for analyzing all the incidents coming from Matt's service desk to find patterns. He became the champion for improvements to reduce problems. His presence gave Ruth and Bob the feeling that they weren't accountable for the quality of their solutions. As is always the case when responsibility for quality is separated from the work itself, quality suffered.

With no one accountable for final results (and hence for orchestrating all the processes that add up to deliverables), processes became disjointed and ineffective. For example, Ruth built a "rapid response" solution for a client who had a one-time need; but Clara refused to install it because it didn't meet her standards of quality, change-control rules, and schedules -- all designed for large production systems.

Even worse, in many cases, one manager was held accountable for results, and others controlled key processes. For example, Art was forced to operate whatever Bob developed and Clara put into production. He was accountable for service delivery, even though he had only indirect control of his own infrastructure assets.

Gaps in the Structure

The focus on major processes inevitably led to gaps. Smaller, less-visible processes were not represented in the structure, such as business opportunity analyses and standards planning. Since they were counting on the organization chart to make processes work, these other critical processes languished.

Wrong Signals

Also, this structure sent the wrong signals. Staff focused on executing existing processes, not on running businesses and pursuing innovations in their professions.

Professional Coordination

Finally, technology experts scattered among the various groups didn't coordinate professional practices such as methods and tools; they didn't share components; and they did poorly at product integration. Both professional and enterprise synergies were lost.

Bottom Line

Structuring by internal processes is an extremely costly way to optimize workflows. If you're concerned about the effectiveness of your internal processes, a process-facilitation function can help. And teamwork can provide a method to define processes dynamically, in the context of the needs of each project or service.

As long as you're willing to invest in process-facilitation and teamwork, there's no need to put diverse professions under a common boss just to get them to work together.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....