An apparel manufacturer embarked on a major initiative to pioneer "mass customization" -- quickly producing clothing that's customized to buyers' requirements on a mass-production assembly line.

Of course, this business strategy was very dependent on IT. It generated a number of highly-visible projects, revamping core IT applications to accommodate the need for rapid integration of orders into production plans. These huge projects required a mix of skills from throughout the IT organization.

The CIO worried that if he assigned these very strategic projects to the existing applications managers, they'd get lost in the pressures of day-to-day support and maintenance tasks.

He also worried about the converse -- some managers might focus on these "hot" projects and neglect less glamorous maintenance work which was essential to keep the current business running.

Therefore, he separated his development staff into two groups. He assigned a young, up-and-coming manager, John, to the new "strategic systems" group, and transferred staff with the needed skills from Jean's existing applications development group.

Under the CIO were two Applications Engineering groups:

• John, strategic systems development
  
• Jean, legacy systems maintenance

Essentially, applications engineers were substructured by new-versus-old instead of their professional specialties. This led to numerous problems....

Dual Learning Curves

When new applications went into production, John's group (who designed the new systems) had to train Jean's group (who maintained them), requiring a dual learning curve.

They tried to rotate staff from one group to the other, but the numbers never worked out right; rotations were never sufficient to preclude the need for this redundant training.

This structure added costs and slowed things down.

Reduced Specialization

Dividing Engineers by new/old, not by type of application, reduced their degree of specialization. The same Engineering specialties were present in both groups. The organization needed two of every type of expert.

For example, in manufacturing systems, instead of having one group focus on scheduling and another on inventory systems, this structure had one developer and one maintainer, each of which had to know both scheduling and inventory systems.

Reduced specialization resulted in higher costs, lower quality, and a slower pace of technical innovation.

Reduced Quality

John's developers didn't have a strong incentive to "do it right the first time," since most of them didn't have to live with the consequences of their sloppy work. They could get the glory by getting projects out quickly, and leave it to Jean's group to fix their errors.

Even if they cared, John's group didn't get feedback on the quality of their work, since they didn't have to confront maintenance problems. So they had little opportunity to learn from past mistakes and improve their quality.

The resulting lack of quality required expensive repairs once systems were in production. Without first-time quality, costs rose; and in some cases, it disrupted the business.

Slowed Innovation

John's group did all the future-oriented thinking and learning. This wasted bright minds in Jean's group.

This structure created a bottleneck that slowed the pace of innovation.

Morale

There were also grave impacts on morale. The split created "two classes of citizenship" within the IT organization:

one building the future, the other maintaining obsolete systems;

one politically visible, the other with no way to be heroes but plenty of opportunities to fail if anything goes wrong;

one with great career opportunities, the other in dead-end jobs.

John's staff became arrogant. Morale in Jean's group suffered -- rightly so since they found themselves in inferior jobs. Motivation and productivity dropped, and turnover rose.

Teamwork

The internal rivalries undermined teamwork. Of course, this had a cost. The tremendous knowledge of current systems and data in Jean's staff was not well utilized in the design of the new systems. This adversely affected quality, cost, and speed.

Wasted Time

Also, costs went up for an interesting reason. Nobody in John's group wanted to be "sent down" to the maintenance group. But these projects couldn't go on forever. Staff spent a lot of time worrying about their next job, and prolonged projects unnecessarily to maintain their privileged position.

At other times, the resource inflexibility worked the other way. Since Jean's staff could not easily be shifted to projects in John's group, they kept busy with minor enhancements, even though their time might have been better spent on higher-payoff new developments.

Not Scalable

In addition to all its problems, this approach to new projects is not scalable. Over time, the organization would have to be restructured whenever major initiatives begin or end.

Bottom Line

The CIO's original concern was a resource-governance problem. This structure fenced off resources (people's time) for major new projects. But as this case illustrates, using structure to resolve resource conflicts has many serious unintended consequences.

In a principle-based structure, every group delivers its current products, supports past products, and develops the new products that will obsolete its current work. In a healthy organization, everybody has a future.

Resource-governance issues can be addressed in another, more effective way. Budgeting and demand-management processes can allocate resources to supporting past products, delivering new projects, and inventing the next generation of products beyond that.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....