Effectiveness and efficiency

A certain large company is converting its IT shop from a development organization to a project management organization. It has succumbed to the siren call of outsourcing, and has changed its development process to impose standard processes across all projects. The goals are reduced costs, faster development, and better prediction of project completion (in terms of time and quality).

But it is not admitting that it is changing from a development shop to a project management shop. The transition is obvious to anyone paying attention: centralization of power in the PMO, creation of architect positions, outsourcing of coding, testing, and support, and -- most telling -- the emphasis on training courses for project management. By reading the actions, the transition is clear. But no one on the management team has stepped forward and stated the transition as an objective. (Possibly to avoid the departure of their best programmers.)

The project managers are no "in charge" of the project. They call the shots, make the schedules, and coordinate the activities across teams and within teams. They define the process for all of the teams.

The managers are using the "meta-programmer" model, the one advocated by Watts Humphrey (although he did not use that name). They are putting their trust in the process (and a few key architects) to produce the software with the right functionality, at the projected cost, and within the projected schedule. A few key people will make the design decisions for the software, and the rest of the team will be cogs in the development machine. (Interchangeable, outsourced cogs.)

They think that the process will tighten the distance between the top performers and the bottom performers. That is, they will raise the floor of performance.

The fault is assuming that they can raise the floor without lowering the ceiling. They think that the gains will all be upwards. But the process they impose will narrow the range, not by raising the floor but by lowering the ceiling.

The poor performers on the team will not be helped by the process. They will continue to make mistakes and use poor coding techniques. (What the process may do is identify the poor performers. Their ejection from the project may improve the team's performance.)

The best performers on the team will be hindered by the process. The process fills a technical person's schedule, allocating all time to specific tasks. This leaves no time for creativity and experimentation. At best, the high performers will be frustrated; at worst, they will deliver results of lower quality.

In other words, the ceiling is absolute but the floor is full of holes.

The managers have confused effectiveness with efficiency. They will get an efficient process. But while they will get their desired level of efficiency (so many requirements implemented per release, so many tests run per day, so many customer calls handled per hour), they will lose the the creative contributions of team members. The success of the project will rest on the creativity of the key architects, folks who are removed from the code, the testing, and the customer support tasks.

Software development is still an art. As much as we want to think of it as engineering, as a discipline, as something that can be analyzed and improved, it is not a science. It is not completely predictable. There remains an element of necessary inspiration. Any process that removes that inspiration will result in software that meets specifications but is unusable.