18 June 2007

Comparing Software Development to Auto-mechanics part 3

What are the similarities between IT project management and a mechanics working on a car. This is the third and last in a series comparing the methods of my mechanic to project management techniques.

You can read the previous entries here.

Build and test

What I do
Not much really. The car is in his yard and he’s working on it. I have agreed to the price and conditions and don’t really expect to hear from him, although I will if something is discovered in during the work that hasn’t already been identified.

For example if there is a problem that is discovered when the car is disassembled I’ll get a call to discuss the change of scope and the potential options and their costs. This would be similar to the change control processes used by projects.

What he does
My mechanic will be doing the work according to his plan. If pieces of work come under his allocated time budget, he’ll accrue them in his contingency – that is; I won’t hear about them unless there is time left over at the end. The same goes for parts.

If things swing the other way they will use up some of the contingency he build up or loaded in at the front of the process. If things really start to blow out I’ll get a call. Given the maturity of the estimating process that is only likely to happen if there are undiscovered problems like those mentioned above.

The test part of the process is similar also. He will test each piece of work as he goes and when completed major components will be tested together. For example once all the engine work is done the engine will be turned over and run for a few minutes. Additionally as all the components are completed the whole car will be tested with a test drive. F he notices any problems he’ll get back under the bonnet and fix them.

How he charges
At this stage I am being charged time and materials, but I have been given a cost estimate that I expect my mechanics to stick to within a certain range, say 15%.

I have opted to take the off peak time i.e. get my work done a little cheaper because I am not asking for it to be ready within a week or two. That means it could be several weeks before the car is ready. I have not worked any arrangement out for this process, although given the maturity of his business, he has indicated about 4-5 weeks as a reasonable time to wait.

Similarities and differences to software
I guess the processes are similar here, especially the change control process.

The key difference seems to be the maturity of the estimating process means that I can be confident in the cost closely matching the estimate. My experience in the past is that usually, but not always, mechanics come in under budget.

Another difference is the mechanic’s ability to act as a user (a driver.) He can test drivethe car and assess, probably better than I can, whether it is fully ready for service.

Here’s hoping.


  1. Anonymous8:30 pm

    Hi Craig,

    I liked your analogy, but... This enters into the debating zone of whether software development is an engineering discipline, a creative artistic discipline or something in between. Personally, I believe it to be something in between. This makes it difficult to compare an engineering practice that is based on known repeatable quantifiable steps with software and its myriads of variables and unknowns.

    Every time software is written, it is inventing something new, at least for that author. Otherwise, they would use what already exists and would not be writing it. It is safer to compare software development with an R&D exercise. Every project is a journey of discovery.

    The estimation tools available such as COCOMO etc, rely on a body of historical metrics and to some degree makes assumptions of continued stability and well understood problem domains. In capable hands I believe that they can produce believable order of magnitude estimates, but are more relevant for select situations, not necessarily applicable in all situations.

    Each project is full of variables that separate it from other projects. Different team members, often different or variances in technology, new problems to solve, variable scope during the life of the project, etc. This all goes to make projections based on past historical data problematic. It also makes comparing tools and processes in software development a very difficult task, leading to a total abuse of the term "Best Practice" in the software industry.

    So in summary, I liked your analogy, but I believe it can only be taken so far. IT is simply a wild beast that despite all the "silver bullets", refuses to be tamed. - Andy

  2. Thanks for the feeedback Andy.

    I guiess as the project gets more complex the art increases, but for many projects shouldn't it just be straightforward?

    For example, a website to capture sales orders should be pretty standard, right? You can do it dozns of ways but by now aren't people thinking there is one or two best ways to build it?