Monday, September 15, 2003

When New Policies Move the CCR

Introducing a new policy can move the system capacity constrained resource (CCR) and create problems throughout an organization. These problems are foreseeable when a manager understands the effect of policies on the CCR. Policies are a type of constraint. The introduction of a new policy might make it the overall system constraint.

For example, let us imagine that the chief architect is becoming uncomfortable with the quality of emerging code and feels that the original architectural intent is not being achieved. With a simple announcement, he introduces a new policy that all designs must be reviewed by him before coding commences. In an instant, the chief architect is now the overall system constraint. A one-man bottleneck. It doesn’t matter where the constraint was before - UI design, Testing, Usability, Requirements or Coding - the new policy moved the constraint.

What are the effects of moving the constraint? People downstream in the process find themselves idle for periods. Work upstream begins to stock pile. People producing designs can’t get to “complete” without a long wait. The project schedule can be abandoned. It too needs to be re-written. The PMO (if there is one) needs to re-write the master schedule. Customers get frustrated and their expectations need to be managed.

When the CCR moves, everything changes. New policies can move the CCR. Changes in CCR should be planned and the overall system-wide effect understood in advance, otherwise chaos ensues, leading to accusations, blame and loss of trust. The introduction of new policies cannot be made locally. New policies should be agreed system-wide after being fully understood by the value-chain of line managers affected.

Thursday, September 04, 2003

Working smarter, not harder

I had lunch today with 4 developers. Despite the high geek quotient around the table in the Chinese restaurant of Seattle’s International District, the conversation was particularly eclectic. However, a thread on economics and politics inevitably led to the debate on the economics of out-sourcing.

At one point, I said, “If costs in Bangalore are about 1/4 those in Seattle then all you need to do is improve productivity 4 fold to compete.” One of the developers was stunned by this. He is a hard working, smart, diligent guy. How could he possible work 4 times harder? Good question.

I replied that if you have an initial quality metric of 3 bugs per Feature and you cut that to say 0.5 bugs per Feature by spending 15% of your effort on design reviews, code reviews and unit tests, then you will increase productivity 4 fold - easy! And this is just scraping the surface of what is possible. Eliminate all sorts of waste such as - queuing and waiting time, conflicts, use automation on repeating process and non-value-added activities such as reporting, improve analysis techniques to focus just enough and no more, improve flow in the value chain and reduce work-in-process. With all of these things it is possible to see up to 10 fold improvements with initially immature teams.

Monday, September 01, 2003

“Don’t apologize, be on-time”

“Don’t apologize, be on-time” was advice given by Sean Connery to Wesley Snipes in Rising Sun. It was one of the few true insights into Japanese culture in an otherwise poor movie.

Hence, it was with some surprise that I stood on the sidewalk outside my office last Friday waiting for my (Japanese) wife who was late. When I called her she was “2 minutes away”. 10 minutes later she showed up with 20 minutes to take me to an appointment which, at best, was 20 minutes away.

It turned out that she setout in plenty of time but got stuck behind a truck which had grounded itself turning off Ballard Bridge into Nickerson. On the return trip we hit the same jam, as emergency services tried to clear the mess with a heavy duty tow truck. In the end we were 10 minutes late. My wife’s journey which would normally have taken 20 minutes each way, actually took over an hour. Is it reasonable to attribute blame in this kind of situation?

There is considerable variance possible between my home and my office. The draw-bridge can be up - typical delay 5 minutes. There are numerous traffic lights. The level-crossing can be closed for a train - typical delay 10 minutes but alternative route available. A typical journey takes 20 minutes. A good time is 15 minutes. If most traffic lights are against, the bridge is up and the train is coming then it might take 30 minutes. However, if there is an accident or a fire (as happened last year) then the journey could take much longer.

These latter events are known in quality assurance as special cause. The others - train, lights, bridge - are common cause. To buffer for special cause events may allow for a face-saving delivery on-time but it is very expensive. Most estimates would be way over and projects would look far too expensive. For the collect husband and take him to appointment project a reasonable estimate for the round trip might have been 50 minutes. This would have absorbed all reasonable common cause variance with an almost 100% certainty of completing the job on-time.

Any reasonable senior manager should expect line managers to buffer common cause variance appropriately whilst accepting that unforeseeable special causes can still make a delivery late without attributing blame or fault.