Reducing Schedule Risk (Part 2)

 

Reducing Schedule Risk, which I wrote more than a year ago, describes how project managers can identify and track project milestones to reduce schedule risk. While every manager should adhere to this best practice, it's clear that setting miniature milestones will not entirely eliminate the risk associated with the development of a complex software system. Hence, Reducing Schedule Risk, Part 2.

Build on a Solid Base

Bugs are inevitable. Good software development practices will reduce the number of defects per KLOC, but it will not eliminate them.

Unless you're starting from scratch, you're adding features to a system that already contains bugs. While these defects might not be have a huge impact to the system's current functionality, they might seriously impede and even block your ability to develop new features.

Imagine, for example, a bug raised against a low-level API that's currently not being exercised. Given that the specific interface is not being called, you might have opted to simply document the bug in a release note, or perhaps ignore it altogether. However, building a new feature that requires this interface will now be affected. Not only will you have to develop the feature, but you'll also need to fix the bug(s), which will certainly increase the duration of your overall task. If the person in charge of sizing the feature is aware of the bug, he/she …

Please log in or sign up below to read the rest of the article.