Here's an idea that seems to come up in IT circles every decade or so, each time under a different name. The unhappy results are always the same.

In IT, traditional business systems require a detailed development process, and carefully planned and controlled change. By contrast, customer-engaging web sites need to be developed and modified quickly. The reality is, IT organizations need to be excellent at both.

One such IT organization split its developers into two groups:

• Bob, rapid applications development
  
• Larry, traditional applications development

Bob's group addressed urgent, strategic needs with small, quick solutions. Larry concentrated on large development projects, as well as enhancements and repairs to existing large systems.

This concept isn't new. In past decades, CIOs have set up small groups to handle short, high-payoff projects, perhaps labeled the "development center" or the "agile development group." Most recently, it's been called "bi-modal IT."

There were benefits. Bob's group produced many valuable solutions. But ultimately, dividing groups by means (methods) rather than ends (products) generated more problems than benefits....

Reduced Specialization

The basis for substructure (quick versus slow) didn't match what people were supposed to be good at (the applications they engineered).

While differing in their methods, both groups had to replicate essentially the same expertise: knowledge of the applications, data, and processes. Bob siphoned staff away from Larry's group; so each of Larry's people had to cover more ground. Meanwhile, Bob's small group had to cover the gamut of data and processes.

Thus, specialization in their core expertise was reduced. This impacted productivity, quality, and the pace of innovation.

Dual Learning Curves

When multiple groups produce the same products by different means, a line of business is fragmented.

This split limited professional collaboration, and forced redundant learning curves. For example, Bob's team didn't take advantage of the extensive institutional knowledge of data and business processes in Larry's group. They had to relearn the business content before applying their methods, wasting a lot of time.

Dis-integration

It also became challenging to get these two classes of systems to work together. Bob's customer-facing web sites needed data from Larry's production systems. But neither group was in a position to design a holistic architecture.

Reduced Quality

The split also impacted quality.

Clients loved Bob's rapid response on highly visible strategic initiatives. And the quality of Larry's work was less apparent to them.

So, Bob's group won in popularity ratings, and became a "loophole" that allowed clients to violate quality and architectural standards, and build quick-and-dirty solutions that were difficult to support in the long term.

Slowed Innovation

Innovation is discouraged and people cling to old ways when their jobs are defined by existing methods. Neither group had the job of discovering new methods, tools, and processes -- new means to the same ends.

Client Confusion

This competition confused clients. Bob advised them to take the quick approach; Larry gave them the opposite recommendation. Clients weren't sure whom they could trust.

Internal Strife

Furthermore, the two groups competed for work, instead of a single group offering clients two alternatives.

They tried to cooperate, but the boundary between "short" and "long" projects was unclear. Bob was limited to projects under a certain number of person-hours. But a given project may fall on either side of that dividing line, depending on something as simple as the choice of platform, the addition of a single feature, or the quality of construction.

Morale

This structure created "two classes of citizenship." Bob got the glory; Larry just kept the entire company running. Larry's staff had every right to resent Bob's group which got most of the politically visible, strategic projects. Their morale and productivity deteriorated.

Bottom Line

Ultimately, this structure was an "enabler" of the problem. The presence of Bob's quick-response group reduced pressure on Larry's mainstream applications developers to be more responsive to the spectrum of large and small projects. They became inflexible in their processes, and unresponsive to urgent projects which still required their meticulous methods.

There are two root causes that need to be addressed, neither of which is structure.

One is methods. Every Engineering group needs to flexibly adapt its methods to match the project at hand. Each should be trained and willing to apply "light" methods to small projects, and more rigorous methods where needed.

Another problem may be a project-definition (requirements planning) method that tends to define all a client's possible needs, rather than just a well-focused next step. When many requirements get bundled into one big project, the organization naturally becomes less responsive. This should be addressed with a Sales function trained in a business-driven opportunity-identification method.

The second root cause is resource-governance processes. All available hours may inadvertently be allocated to large projects, those which can be identified during the budget planning process. This leaves no resources available for the quick projects that arise throughout the year.

Instead of using structure to reserve resources for small, strategic projects, a portion of the staff's time (or budget money) should be held aside. This is a challenge for the internal economy, not structure.

Splitting Bob's group out of Larry's did not address either of these root causes.

The better answer is to use structure to provide a single group of experts in each domain of engineering, and then address the lack of responsiveness by correcting its root causes: methods, and the internal economy.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....