Today I want to talk about why software projects fail. But first, let's define failure. For a project to be considered a failure, at least one of the following three conditions must exist:
- The budget is exceeded by more than 10 percent.
- The schedule is exceeded by more than 15 percent.
- The application fails to meet the goals and objectives of the client.
Notice that I haven't mentioned the skill or experience of the developer? Projects normally don't fail for this reason (but they can). In most cases, projects fail for one or more of the above reasons. The good news is these items can be successfully mitigated by the software company you hire. In fact, if a project fails for any of the above reasons, I believe the software company is at least partially responsible. Let's examine why.
Blowing the Budget
Why are software budgets exceeded, or blown? Occasionally, the client has not clearly defined what they want to build in advance, and the developer doesn't discover these new requirements until they are well into development. This is a costly time to discover new scope! But realistically this doesn't happen too often. In most cases budgets are blown because the developer did not ask the right questions to ascertain the complete scope of the project. And I don't believe this is completely the responsiblity of the client. How can they be expected to know what information is critical to estimate their project?
The bottom line is that in most cases budgets are blown because the software developer failed to determine the exact scope of the client's project.
Blowing the Schedule
As you might imagine, blowing the budget goes hand in hand with blowing the schedule. If you don't understand the entire scope of the project, you aren't going to deliver the application on time. But realistically, most often the schedule expands due to poor project management. A complex software project usually involves thousands of details. Each detail needs to be tracked and managed, and with large projects this can overwhelm inexperienced teams. A very large project is no more than many smaller projects running concurrently. Without an effective way to manage the details dates are going to slip.
My point is that schedules are usually blown because teams are unable to manage all the details that make up the project plan itself.
Not Meeting Client Goals and Objectives
Why build software your client doesn't want? Seems like a big waste of time if you ask me. But it happens for the same reason that budgets and schedules are blown. Again the problem is not understanding the nature of the project the client is asking us to build. Part of the problem is developers have a tendency to want to start programming as soon as possible. Without understanding all the requirements in advance, there is a strong likelihood that they will be building the wrong application. Again, I see this more as a developer failure than a client failure.
As professionals, we need to ask the right questions, and fill in all the blanks. Otherwise we are building something our clients do not want.
How We Mitigate These Risks
Risks are always present in software development. Do we understand the scope? Do we have enough time and resources? Are we building the right application? These questions, and hundreds more, make up what equates to the challenges and risks of the project. So how do we mitigate these risks? The simplest strategy is to fully understand the nature of the problem our clients want us to solve. There are no shortcuts here. We have to discuss and define the project requirements in detail. This takes time, but in the long run it saves a lot of time. And by doing this we eliminate the three main issues plaguing most software projects today.
I hope you found this discussion useful. Thanks for reading.
Rob
