by: Thomas Meloche

Software Success Rates

Over two thirds of all software projects experience major problems and over one quarter of them outright fail.¹ Ironically, the bigger the projects are in scope and budget the more likely they are to fail. Building great software shouldn't be this hard.

These failures are not caused by poor development capabilities; rather they are the direct result of inappropriate and incomplete development processes. Software is created to achieve business goals. Yet most development practices have isolated the business and development teams. As a result, requirements are communicated without business values. This leaves the programmers to decide what is and is not important to the business. Is a programmer rewriting your marketing plan? What is the link between your business team and development team? Is there a link or a gap?

The Delivery Team

All too often we see delivery teams staffed with the following profile:

Unfortunately, this profile only describes the Development Team.

A profile that consists only of a Development Team sets the entire project up for failure at the very start. This team is very important. But having only this team artificially elevates the voice of the developers to be the primary voice on the project. The developer voice is the voice of technology. It presents a software developer's interests, concerns and world view. It is not sufficient to have this view alone directing the entire project. If this team is working without additional input the results it produces may be technically interesting but functionally useless for the business and users.

Building a team entirely of developers omits important voices the team requires that are unrelated to technology and engineering. For example, who is representing the project stakeholders? The developers? Who provides the project vision? The developers? Who understands the business objectives and the return on investment expected from developing the software? The developers? Do the real stakeholders have the ability to direct the project? Or is the project directed by the limitations of the technology being deployed as described by the developers. Do the real stakeholders have any controls other than granting and removing budget? Are the stakeholders intimidated by the cult of technology and the engineering descriptions of the difficulty of the project? Do the stakeholders have a voice? They absolutely require one.

Building a team entirely of developers also omits the input from the users of the system. How are the users interests represented? Is the system usable by real users who are far less comfortable with technology than developers? Is the development team taking into account how users actually work in their real environment? Many systems we encounter are a great demonstration of technological prowess but they don't actually meet real users' needs. Often the developers joke about how stupid the users are. If the users were a little smarter they would understand why the system the developers built is so great, even when it doesn't help the users get their work done. The users also must have a voice on the development team.

A working delivery team is a team that properly captures and represents the multiple interests on the project: stakeholders sponsors, users and developers. Each voice must be balanced by the insights and concerns of the other voices. To provide that balance requires a mediator and coach of the entire team. The final component of a working delivery team is someone who makes these various voices work together. A coach unites the multiple voices into one functioning team.

The elements of a successful delivery team fill the gaps between business values, user values and development values. A properly constructed delivery team has multiple parts of which the development team is an important part, but still is only one part.

The Menlo Delivery Team

The Menlo Delivery Team is build to address all the these various needs. It is designed to have four teams working in concert to deliver projects successfully. The focus areas have different and distinct responsibilities:

These teams leverage different best practices from a variety of sources including:

• The Rational Unified Process^®
• Interaction Design
• Six Sigma
• Extreme Programming

Conclusion

By simply recognizing and staffing the different specialties required in the delivery team, business can make significant progress on the journey to delivering successful software projects. 

The Menlo Institute provides specific training in these specialties. However, we realize that training classes alone will not change deeply ingrained behaviors already in practice by your team. To this end, The Menlo Institute provides our clients with mentors to facilitate further growth in each focus area. This allows your personnel to have living models to emulate as they explore new behaviors and methods in building software.

The Menlo Institute encourages you to begin that journey today.

¹ Standish Group Chaos Report [2001]

Interested in Learning More?

Tom, send me Rich's free white paper "Seven Keys to Building Great Software Products"

We will not resell your contact information.

We hate spam as much as you do.

Privacy Policy: No Resale Zone.  Spam Policy: No Spam Zone.