Eric Lundquist writes a great article about why software projects fail. The premise that for projects to be successful, they need to be: on time, on budget, and used. This is a big shift for a lot of organizations to move towards customer-centered design. Adding a usage requirement may be tough for a lot of internal organization. Services like Flickr, Basecamp, Amazon and others have this usage requirement built in, i.e., in order to attract new customers and retain existing customers you need to provide features and functionality that customers want.
Whether it be a high-profile government project or a sales force automation tool, not starting with the user in mind is one basic mistake sure to sink any project. A project that is on time, on budget and unused is still a failure.
Is it possible for internal organizational projects to be measured along the same lines for success. Often the ship date is more important for our internal projects than user satisfaction, while the adoption of the project and it’s eventual success are more often then not determined by user adoption and satisfaction. But as an organization, we tend to overlook or under value our employees in the equation when designing, developing and using new tools. Brian Behlendorf of CollabNet, Apache, Organic and other companies and projects, suggests moving towards a community model for software development may ultimately be more successful for development.
The software development process must be seen as an ongoing environment, where interdependence is implicit and allows coordination between projects, thereby stimulating creativity, Behlendorf said.
On of my "projects" has become a key part of the value proposition for the department. It is increasingly difficult to stop work on this project, because the user community is involved in setting my team’s priorities, bug fixes and feature requests for this project take precedence over other projects. I wonder if there is a measure that we could incorporate into our development lifecycle.