On the Fast Track

On the Fast Track


I recently visited a client and they explained what changes and add-ons they had made to their development method. A light-weight adaptation of RUP that I helped them implement some time ago. During the conversation they explained that they had implemented what they called Fast-tracks.


They explained that a fast-track is an even more light-weight path through the stages of the development process for projects of high importance to the business that has to be implemented and put into production quickly. To do so certain work products, check-points, tests and so on had been taken out so you could get things done more quickly. Of course, you had to get approval for upper management before you could use the fast-track approach.

Sounds like a good idea, or?

When I was listening to the explanation, it all sounded like a good idea: Make sure that what is vital to the business can be implemented quickly, knowing full well that you bypassed certain elements of process. Then I got to think about it and then is started to sound a little absurd. Here is why.

Why isn’t every project a fast-track project?

If a project that is of vital importance to get done quickly can get away with less “overhead”, so to speak, than a regular project, what is the point in having that overhead at all? Where is the logic in having to produce more work products when what you have to deliver is not of vital importance?

Lean and Mean

When I asked them that question, they told me that the idea was that what you bypassed in order to get things out quicker, had to be produced afterwards, but usually that didn’t happen. Then I asked why not have just one path where the unnecessary work products were taken out for the benefit of all the projects, and they actually agreed.

And thats what Lean is all about. Eliminate waste for the benefit of all.


No comments yet.