Measuring the load

If I worked for a large consulting house, and offered you a new process for your software development projects, would you buy it?

Not without asking a few other questions, of course. Besides the price (and I'm amazed that companies will pay good money for a process-in-a-box) you'll ask about the phases used and the management controls and reports. You'll want to be assured that the process will let you manage (read that as "control") your projects. You'll want to know that other companies are using the process. You'll want to know that you're not taking a risk.

But here's what you probably won't ask: How much of a burden is it to your development team?

It's an important question. Every process requires that people participate in the data entry and reporting for the project: project definition, requirements, task assignment, task status updates, defects, defect corrections, defect verifications, build and test schedules, ... the list goes on. A process is not a thing as much as a way of coordinating the team's efforts.

So how much time does the process require? If I offered you a process that required four hours a day from each developer, seven hours a day from requirements analysts, and nine hours a day from architects, would you buy my process? Certainly not! Involvement in the process takes people away from their real work, and putting such a heavy "load" on your teams diverts too much effort away from the business goal.

Managers commit two sins: failure to ask the question and failure to measure the load. They don't ask the salesmen about the workload on their teams. Instead, they worry about licensing costs and compatibility with existing processes. (Both important, and neither should be ignored, but their view is too limited. One must worry about the affect on the team.) Managers should research the true cost of the process, like any other purchase.

After implementing the process, managers should measure the load the process imposes on their teams. That is, they should not take the salesman's word for it, assuming the salesman was able to supply an estimate. An effective manager will measure the "load" several times, since the load may change as people become familiar with the process. The load may also change during the development cycle, with variations at different phases.

Not measuring is bad, but assuming that the process imposes no load is worse. Any process will have some load on your staff. Using a process and thinking that it is "free" is self-delusion and will cause distortions in your project schedule. Even with a light load of one hour per day, the assumption of zero load introduces an error of 12%. You think you have eight hours available from each person, when in fact you have only seven. That missing hour will eventually catch up with you.

It's said that the first step of management is measurement. If true, then the zeroth step of management is acknowledgment. You must acknowledge that a process has a cost, a non-zero cost, and that it can affect your team. Only after that can you start to measure the cost, and only then can you start to manage it.