7.3 QuoteProject Validation | A Software Engineering Approach to LabVIEW

7.3 Quote/Project Validation

You have the perfect Requirements Document, now you need to tell the customer how much it's going to cost. How easy this will be can be gauged by how many projects go over budget, sometimes by hundreds of percent. Before you can quote or estimate a job you will need to have done a certain amount of design. There is an uncomfortable balance of either completely designing a system to give a top- notch quote, or not spending enough time on the design and giving an inaccurate quote. Bearing in mind that a lot of jobs run over expectations, the latter can be very painful. However, patterns and past experience can play a huge part in making your estimate more accurate. The absolute worst mistake you can make is not understanding the requirements as completely as possible. It's probably the surest recipe for disaster.

One of the best pieces of advice you can give to a customer is not to go ahead with a project at all. You are being asked to do the project, so surely you should assess the likelihood of success. To go back to our building analogy, you would be sorely disappointed if after the house had been built, you could not live in it because the ground it is built on is the wrong type and the whole structure is sinking. You would have expected someone to check first. Advising against going ahead may go against the grain, but if the project is not feasible for whatever reason (you may have already seen a project like this fail), then it should be reassessed. For example, there often needs to be specific criteria for the project to get off the ground, which could be payback in a production environment. The customer has calculated that by employing the latest Digital Signal Processing (DSP) technology he or she can cut the test time, and the entire new project will pay for itself in one year. This may be impossible , and, hence, the project (as defined) should not go ahead.

The initial quote needs to be as accurate as possible, which is extremely hard when you are predicting the future. Careful consideration of the customer's requirements, compared with your previous experience, should play a huge part in the estimating effort. Prototypes can help immensely, especially with timing or performance issues (the analogy of tracer bullets works well here). If you are not sure that some feature can be implemented, then try it out first. There is, of course, a cost to you for doing this if the customer is not willing to pay for a trial, but that cost could be minimal compared with giving bad advice and being saddled with a failed project. It's far better to tell the customer at the project inception that he or she will not get the payback they expect, than to get that sickening feeling at the end of the project when realization sets in. Do whatever is feasible to ensure your estimate is as accurate as possible in every facet. Alternatively, just pray.

Top