The Complete Software Project Manager

Chapter 12Problems: Identifying and Troubleshooting the Three Most Serious Project Problems; Criteria for Cancellation

I recognize that many readers may pick up this book and flip right to this chapter because they are two-thirds of the way through a software project and have problems. In fact, you may be the unlucky person who was asked to step into a project at the two-thirds mark because of all the problems. If that is the case, I encourage you to refer also to Chapters 5 to 11 for the background necessary for understanding what you're facing.

As discussed in the previous chapter, there is a “dark side of the moon” phenomenon in software development, especially one that isn't “agile enough.” Business requirements get settled and then the programming team goes off and develops. At the first-look stage the business finally gets a taste of the software. And that point—about the two-thirds mark—is when things can come crashing down.

A Rule About Problems

When problems occur in a software project, they almost always require more time, money, or (usually) both.

Sometimes, to solve problems, an additional vendor must be hired or an additional piece of technology must be purchased. If you're using an external software development resource, keeping them on longer will inevitably cost you more.

In the case of an internal team working on software development, the budgetary impact may be masked. You're not paying any more for these people to keep working; they're already employed. But, ...