Experiences of The software Development process

When developing a new product, the rule of project management is to never start by setting the end date. The end date is calculated from the tasks to be undertaken and the time to complete these tasks. However often the end date is given before any one knows what all the tasks are.

Sadly managers, when given an estimated time for a task, don’t realise that there is only a 50 per cent chance of that time scale being achieved. The time is an estimate and so the Gaussian distribution rule applies, meaning the esitmate is at the centre of all the possible outcomes. Of course it may be finished earlier.

For an accurate estimate, a great deal of time is required. It can only be done once the software design has been completed, and then this design has to be further investigated and possibly refined. Therefore, to come up with an accurate project completion date many weeks must be spent. Few if any companies will spend this amount of time in the quote process, so it’s no surprise that the initial project estimates are in error and are rarely ever met.

When it comes to project estimates it is often very hard when using a new interface or hardware to determine how long it will take. For a task estimate to be accurate, it must be estimated by the engineer performing the work. However, more often than not this is not the case and so the errors are only increased. It is often the case that a company secures a contract and only then recruits or is allocated the people to perform the tasks.

Where there is a project plan or schedule of some kind, the software slips start in the first few weeks, as extra tasks are identified that were not accounted for before the work started. Simple tasks become complex ones. I have seen a task on a project plan down as taking 0 days! On pointing this out I was informed by the project manager the third party software would just slot in. It was then discovered that the software was not suitable and several weeks were spent writing a usable version of the code. Despite the slips starting at the start the customer is most often only told at the very end of the process.

When developing it is normal for engineers, software teams and companies not to advertise the lack of progress they have made. After many years of observing this behaviour, it would seem that keeping your head down when progress is poor can be a benefit. If another engineer, team or company in the process are found to be late, your progress is no longer of importance. Also if the customer requires a change then any delays can be hidden in the new work to be done.

Whatever the approach your supplier is using, you need to understand how your product is being developed. You need to understand the stages of a project and what happens if you introduce a change in to the project at any given stage. You need to know if the development plan is realistic and if the project is slipping. I have worked on a project where the customer was only rang on the day of delivery to be told of a project delay.