3 comments:

If the project is a large project, I'd suggest adding multiple buffers throughout the project instead of one big buffer at the end. The key is to separate the risk-based buffer from the actual expectations. If we pad the actual expectations, people will procrastinate.

We need to be careful in estimating whatever we estimate. If our estimate is too big (or buffered too much), a good project may never get approved. If our estimate is too small, we get into trouble when we can't perform whatever miracles we promised. The challenge is to find something realistic using whatever data we have and identify the risks and conditions when communicating our estimates.

As is said in the financial information business: Past performance is no guarantee of future success.

I used to think we could gather requirements and I as a tester should enforce those gathered requirements. I now know that requirements are going to change and we are better off making requirements a fluid part of an iterative process.

Hard up-front written requirements without checking back with the customer delivers what they asked for but often misses what they really want.