Here's a case study that illustrates the confusion of structure and resource-governance issues.

Situation

An IT department needed to be flexible in assigning staff to a continually changing mix of projects, while still maintaining expertise in each application. Its solution was a "programmer pool."

Carl managed the applications engineers (systems analysts), with groups under him dedicated to particular sets of applications.

His applications managers staffed their project teams by drawing on a pool of programmers (generalists) reporting to Brian.

Under the CIO were the following Engineering groups:

• Carl, applications managers
  
• Brian, programmer pool

This put the more experienced people in the key role of applications experts and project leaders, and provided resource flexibility as demand in one area rose while in other areas it diminished.

But the drawbacks were considerable.

What Happened

The people in Brian's programmer pool could not specialize in any particular applications. They were generalists, expected to work on any system, as the workload demanded.

Thus, Brian's programmers lacked the in-depth knowledge of applications that comes with continuity and specialization. Nonetheless, they made important design decisions as they developed code. Quality suffered.

To make matters worse, there was little incentive for first-time quality. Programmers were not accountable for results, other than just showing up and doing as they were told. And at the end of the project, the programmers would move on to another project, leaving Carl's applications managers to deal with any problems they left behind.

As a result of this authority (to write the code) without accountability (for the errors), again quality suffered.

Also, things took longer, since programmers were repeatedly at the bottom of the learning curve and had to find their way around new applications with each new project.

This structure also created serious motivational issues. Brian's programmers felt like second-class citizens, not valued for their skills. They came to resent the applications engineers (who, admittedly, were a bit smug). Teamwork suffered, as did their effectiveness.

Programmers in the pool were especially demotivated because it was so hard for them to graduate to the status of applications engineers. Every new project took them into a new area of technology; so they didn't have a chance to learn any particular application in depth. They were trapped in dead-end jobs without the ability to gain competencies through specialization that would get them promoted out of the pool.

Alternative

Staffing flexibility was needed, but this was not an effective (or kind) way to attain it.

A better approach is to form technology-aligned Engineering groups comprised of managers, analysts, and programmers (all job levels).

Load balancing can be accomplished by loaning staff between groups when necessary, while still providing everyone with a permanent home that determines their area of expertise, and a career progression as skills are gained.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....