(^60) 97 Things Every Project Manager Should Know
Software Failure Is Organizational Failure
Software Failure Is Organizational Failure
Brian Sletten
Beverly Hills, California, U.S.
WE AlWAyS BlAME DEvEloPERS when things go wrong with software proj-
ects 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 func-
tionality 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 deliv-
ery 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 seldom deliver require more oversight, further training, and
realignment, or perhaps some members must be shown the door.
However, allow software teams time to clean up their own messes. As they rush
toward various releases,* they will incur what wiki pioneer Ward Cunningham
calls “technical debt.” Like real debt, if it is not paid down consistently and
responsibly, it will become unwieldy and require too much attention to service.
- Releases: The agile development method of software development creates specific functionality
within several short time frames. During each time period, requirements analysis, planning, design,
coding, unit testing, and acceptance testing are performed. At the end of this time, a workable
feature is “released,” or shown to the customer.