97 Things Every Project Manager Should Know

Chapter 30. Software Failure Is Organizational Failure

Brian Sletten

WE ALWAYS BLAME DEVELOPERS when things go wrong with software projects in an organization. When deadlines are missed, or when what is delivered has more bugs than an entomologist's wildest fantasy, it may seem that the team is not good enough, smart enough, productive enough, or up to the challenge. While individual teams may deserve a fair amount of criticism, you cannot forget that successful software projects require active and adequate participation by all stakeholders.

Everyone's participation is crucial, because in order to stave off failure, you need to know who is building what, when, and why. You need to add business functionality in deliberate, prioritized ways. You need to catch problems with poorly captured and expressed requirements. You need to nip latent impediments in the bud by spotting people who are potential blockers, noting communication failures, and soothing overwhelmed (but overeager) development teams.

Developing software requires valid metrics, clear communication, and engaged business and executive stakeholders. They must be involved in software delivery efforts and assume partial responsibility for both positive and negative outcomes. The software project manager needs to measure and track success and failure records. Teams that consistently deliver can be trusted to do so again. Teams that ...