I was working on some estimates for a project by first estimating the size of the project and then estimating the effort by looking at some historical data on similar sized applications done in the past. What we realised that in all our projects we were pretty much on track with the estimated efforts until we reached the validation testing phase. In this phase we realised that we were spending anywhere between the initial estimated effort and three times the initial estimated effort.
I then tried to analyse why we had such a vast variation in the estimates for this phase and I found that the prime reason for this is because there are defects slipping through all the other phases into the testing phase and thus skewing the entire estimate. If there is no control on the other phases of the project then this phase is pretty much a mess and usually it is so late in the project that it is very hard to recover from the mistakes made in the other phases.
So if you see the project team can never be lax in any of the phases as all the inaccuracies crop up and bite you in the testing phase and sometimes fixing issues so late in the project may not be possible and hence the team starts working on workarounds thus messing up the project even further. So right from requirements right up to the project is handed over to the testing team to be tested the project team should employ methods such as reviews and code walk through along with Proof of Concepts to ensure that everything that is being developed is validated so that issues do not crop up later on.
We tried to employ this in one project but there were a lot of uneasiness early in the project as there was no visible progress being made as concepts were being validated with Proof of Concepts and design documents being written and reviewed. But what we realised was that with detailed documentation the coding phase was hardly anything and the testing phase was even shorter and the end result was code that one could really be proud of as it had no workarounds and it worked exactly as desired. The best part of this was we delivered ahead of schedule as we could multitask and plan a lot better with detailed designs.
Hence short cuts taken early in the project end up creating the biggest risk of the project and that risk is an inestimable number of defects late in the project. Another problem due to this risk is that you will not be able to give a definite delivery date to business because you don't know the defects that will arise and the complexity or severity of the defects and this is something business hates. So to save yourself this risk employ quality assurance/quality control activities in every phase of the software development lifecycle.