I have never been a professional developer. I am as close now as I have been to being a professional developer, but I have still not contributed “production” code, or participated on a software team. My only perspective of that world is what I have been told, and the resounding statistic rolling through my head is that historically and overwhelmingly, software projects fail.
The godfathers of the agile methodology took note of this dismal fact, and introduced agile practices as a way to engage the issues behind the failures. They created a new approach software development, establishing the core principles and values that comprise the Agile Manifesto.
What I would like to address, as the agile manifesto already eloquently states the plan for the future, is talk about some of the mistakes of the past that lead to the need for a new path.
What is failure?
The first step in defining what it means for an IT project to fail is to decide what are the metrics of failure. A failed project in general is one that has not delivered what was required, in line with expectations. Requirements could be features of the project or specific functionality of the application. Expectations could refer to the timeline or budget of the project, or its quality.
Because requirements usually change (and change is embraced in agile programming), often the definition of a failed project will look different at the project’s inception from when the project concludes. Expectations may also flux, so it is important for there to be constant communication between the developers and users so that the perceived value remains consistent throughout the project.
Why projects fail
Making decisions is hard
When it comes to software management, decisions are hard. Software projects are complex. Decisions are subjective and often involve a significant amount of uncertainty. Decisions are often mutually dependant, so deciding on one thing may adversely affect something else.
Being able to manage software projects requires a great deal of skill and understanding of not only the product, but also the team and the client. Besides that, teams often have several individual decision makers, which means that several people’s decisions need to be cohesive. Learning to handle decisions takes experience with both successful and failed decisions.
Expertise Varies
A team of programmers developing an application will have varying degrees of experience and thus a range of expertise. Some may be on their very first project. Some may have never worked on a team the size of the project team. Some may have only worked in a different language or with different technologies. Some may not be familiar with the industry that the client or product exists within.
The point that I am trying to make is that people will come into a team with varying levels of expertise, yet with the way that software teams are increasingly decentralized, will probably have to make project decisions. The problem comes with the fact that members without the insight that comes with experience and expertise will lack the understanding and situational awareness required for the complexity of the decisions they will face.
Constant Pressure to Deliver
Clients bear some responsibility in both the success and failure of software projects. Rigid client expectations are often cited as a reason for failure because accepting and agreeing to such expectations puts a significant amount of pressure on the team to perform. While the idea behind setting a timeline may be innocuous, applying such rigidity to a project may lead to missed expectations if project requirements evolve. Beyond that, if a team is running behind a timeline, or even right alongside, quality control actions may be dismissed for the sake of time, reducing the overall quality of the application and increasing the probability for issues.
Inflexibility
If there is one thing I have learned about software projects, it is that requirements usually change. Teams that are not flexible to that change for whatever reason risk losing control of the product.
Agile development addresses changing requirements by the idea of increasing the communication between the client and developer team to keep the feedback cycle short. Also, quality code is adaptable and extendable if necessary to accommodate change.
Conclusion
These are just a few ways in which a software project can fail. Keeping an eye on the project’s progress, keeping in constant communication with the client, and being flexible to change are techniques that software teams can use to insulate themselves from failure.