Why Software Development Projects Fail
Introduction
Let's start with a worrying statistic. According to the Standish Group in 1995, only 16% of software projects were successful, 53% challenged (that is schedule overruns - exceeded by greater than 10%, budget overruns - budget is exceeded by 15% or the application fails to meet the goals and objectives of the client) and 31% cancelled. Further, they say the average software project runs 222% late, 189% over budget and delivers only 61% of the specified functions. Evidence suggests little has changed since then. Failure has become the IT industry norm. So what can we do about it? A good starting point is by addressing some of the key reasons software projects fail.
Not Enough Time
Often the deadline date is decided before the project starts and is non-negotiable. This results in a headlong rush to get started on the assumption that if we begin coding the sooner the sooner we'll finish.
This is almost always the wrong approach. Succumbing to this trap leads to continuing changes throughout the development phase. When this happens time and budget are consumed at a rapid rate.
Solution:
We always allot time to create a good design ... as a matter of fact, this is defined as an actual project deliverable. We are never tempted to jump straight in and begin coding ... 20 years of application development has ingrained this concept into our consciousness. By taking the time to create a good design, we have improved our reputation since we always deliver a product that fulfills the customer's expectations and works properly the first time ... all within defined schedule and budgetary constraints.
Insufficient Budget
Many projects have a "lowest price most successful candidate" policy, or an unrealistically low budget, not based on the true requirements. When this happens everything slows down. Resources are slow to arrive, or never arrive, corners are cut and quality suffers.
Solution:
We urge you to be realistic about the budget and we back our proposal by relying on the accurate scope of the full requirements specification that we just talked about. We tend to avoid projects where the client bases selection of a consultant solely on lowest price. Usually, by using our detailed requirements specification, we are able to justify an accurate estimate of budget and schedule. You should be wary of a consultant who quickly gives you a fixed cost estimate without first fully discovering the requirements of the project. Always go with a consultant or team that has a proven track record of delivery within budget.
Poor Communication
There's an old saying, "never assume anything", and this is especially true for software projects. Good communication with the customer, users and especially the development team is important for project success. You should ask these questions: Does everyone in the team understand you? Do they know exactly what is expected of them or have you assumed they know? Do they communicate well with one another, with users and with other departments?
Solution:
We are familiar with all of the potential communication breakdowns and take measures to ensure they do not occur. If we didn't do this, it could lead to confusion and complications later in the project. We never assume that everyone understands. We will take time to create an environment that brings the project in on time, on budget and to your expectations. "Well, that's all well and good" you might be thinking but that leads to the question "Exactly how do you do that"? The answer is simple and multifaceted. Our primary means of communication is the weekly status report where we show you what we have completed and update you on the completion status of the project. Our secondary means of communication is an on-line project management portal that allows you to view, sometimes daily, updates in the status of your project. We let you know who is working on what and how they are progressing. This portal also allows you to ask your project manager questions ... all the while completely and accurately storing the comnunications between our companies in one cohesive place.
Never Reviewing Project Progress
As a project progresses things change and these changes can have a significant impact. It is important to review progress regularly so challenges can be overcome early, and stakeholders warned of possible delays and changes to the product.
Solution:
In order to accomplish this, we translate your requirements specifications into tasks to be completed and enter them into Microsoft Project. Once we assign the estimated time to each task the end result is a detailed project plan with concrete deadlines. These tasks are then combined into milestones which allows us to review the project's progress with your team and ours, and adjust as necessary to stay on course. We will stay close to your team so you understand what is going on, and what challenges we are facing.
Inadequate Testing
When the pressure to deliver is on, it is often testing that suffers. All the testing is left until the end of the development cycle and only lip service paid to it. Often, the result is a product filled with bugs and an unhappy customer.
Solution:
We account for testing throughout the development life cycle. Testing (both automated and manual) is accomplished as the software is created. The process starts with manual testing. As we manually test, we are creating the user manuals that describe how to use the product as well as creating the scripts required to perform "regression" testing. Regression testing ensures that continuing development has not introduced new faults into already completed portions of the application. By doing this we ensure that testing is not left out until the end of the project. We have found that users can allocate a couple of hours of testing each week ... but they rarely have the time to perform weeks worth of testing at the end of the project. We have also discovered that observing these rules results in the users already knowing how to use the software before it comes time to deploy the application to production.
Testing in the Production Environment
It's surprising how many organisations test products in their production environment. This is a high-risk strategy that can lead to security breaches and release without testing, disrupting the production environment.
Solution:
We NEVER test in a production environment ... EVER. At the beginning of the project, we create a testing environment that is separated from production. ALL new functionality is tested thoroughly for accuracy BEFORE it is promoted to production.
Lack of Quality Assurance
Often in the haste to deliver the software, quality assurance suffers. Documentation is not completed for code changes, the design contains flaws, and implementations can be incomplete. These all lead to rework, lost time and eventually unhappy customers.
Solution:
We use the CUPRIMDSO formula to ensure their software has lived to your expectations. The acronym stands for the following: Capability, Usability, Performance, Reliability, Installability, Maintainability, Documentation, Service and Overall. The list is, undoubtedly, a handful since it ensures that the intended software will work as planned. From performance to the ability to handle stress, we emphasize giving the software a thorough check before it is launched and presented as a candidate for your production environment.
Not Conforming to Industry Standards
Conforming to industry standards in your software projects can prove effective by ensuring accessibility, portability, usability, robustness and reducing problems now and in the future. Bodies such as the International Organization for Standardisation (ISO) and World Wide Web Consortium (W3C) have developed open standards that when used are hard to challenge.
Solution:
We take time to introduce standards for your projects. Most notably those presented by Steve McConnell's excellent book Code Complete. We identify what works well and we keep doing it. We regularly re-evaluate our standards to ensure we keep up with industry expectations.
Conclusion
The next time you contract for a software project, review this list first and remind yourself what is needed to ensure your success. You'll be surprised at the difference it makes.