Last updated: April 28, 2006

Project End Game

* Based on a personal communication from Troy Pearse, Hewlett-Packard Co., Boise, ID, November 2002.

Here are a few thoughts about the final phase of your project, which we affectionately call the "End Game."  At this point you’re getting close to the end of the project. Your product is in Beta test at the customer’s location. You’ve put a lot of time and energy into the project and you’re probably looking forward to being finished. But right now, careful testing and defect management can mean the difference between a great final product and one with reliability problems and too many limitations to be used by your customer. Here are some things that will help achieve a successful conclusion to your project.

• You need to log each defect found, determine the customer impact, and assess the risk of fixing or not fixing it. And just because your customer submits a defect doesn't necessarily mean that they think it should be fixed.

• When defects aren’t fixed they generally need to be documented as program "limitations."  Whenever possible you should describe workarounds for limitations. (More of that documentation stuff.)

• Keep in mind that from here on out you are trying to minimize risk to the project. This means you should do extra review and testing of all changes to make sure they are good. You don't have time to find defects that are introduced by defect fixes. Team/peer review is often a good way to help minimize risk: two sets of eyes and two good heads are better than one!

• It will be hard, but you have to be willing to NOT fix a defect. As a software engineer you would like to make sure everything in the code you have produced works perfectly. So take off your engineer hat and put on your management hat. Try to make decisions based on the value of the fix to the customer vs. the risk. Remember that each time you write code there is the likelihood that you are injecting a new defect. From this point forward you should seriously consider NOT fixing every defect found. Consult with your customer to make an appropriate decision as to what gets fixed and what doesn’t.

• Effective regression testing is a key to maintaining product integrity in this phase of your project. You want to be able to show you haven't broken anything else when you fix a defect. Do as much of it as possible during last few weeks. Keep adding new tests to your regression suite.

• A well planned and implemented regression test suite is of significant value after you have made your final product delivery. Your customer will be maintaining your code and it will be helpful to them to have a set of regression tests that they can run to ensure changes they make don't break something.

• Before your last product release make one last check to ensure that all defects planned for fixing have been fixed and that all of your tests that should be passing are indeed passing. Check to see that your documentation is accurate and up to date.