September 19, 2011

Recognizing catastrophic issues with a project early and shutting it down before it becomes "too big to fail" is an important skill for agile development, Aaron Erickson wrote recently for InformIT.

One of the biggest reasons doomed projects often continue and do more damage than they necessarily had to, he said, is pride. Once a decision-maker has chosen to sink large amounts of company resources into an idea, admitting defeat and walking away from even the most dysfunctional project becomes nearly unthinkable to some people.

There are a few signs that a product is destined for the scrap-heap, Erickson wrote. Serious production delays, certain patterns seen in burn-up charts and long delays between problems getting noticed and getting fixed all may indicate a fundamental issue that can doom a team's efforts.

In many cases, then, it's better to cut one's losses and end a foundering project rather than throw good money after it's gone bad.

System testing can often provide some of the best indicators of a failing project, according to experts, if routine checks discover multiple problems.

Posted under
Automotive Software NewsAvionics, Aerospace, and Defense Software NewsIndustrial Controls Software NewsMedical Device Software NewsRailway Software News