After more than two decades in the business of providing software development, testing, and support, we have gained a clear understanding of the factors that make certain software projects successful while others fail. The following are Six Reasons Software Projects Fail.
While defects can be a cause of software project failure, the degree of impact often comes down to when they are discovered. An absolute truth for any software project is that the earlier defects are identified and corrected, the lower the cost. The cost to address defects escalates exponentially as the project progresses through the software development lifecycle. One of the leading causes of delay in defect identification is that testing teams are often notified of the new software initiative after the development team starts writing code. By engaging testing resources during the planning stages, they are able to identify defects in the plan before code is even written. Organizations that do not learn this lesson during the initial development phases are likely to repeat this process during subsequent maintenance and enhancement releases, thereby paying much higher software development costs on an ongoing basis.
2. Executive Team Commitment
Ensure that key project stakeholders are committed to providing the resources necessary to complete the initiative. In the early planning stages, statements such as “can’t we do it for less?” should be concerning. As the planning process progresses, additional costs will be identified. Hesitancy with the initial numbers may turn into a complete roadblock once the budget is complete.
Projects that do not obtain sign-off from business stakeholders, development, quality assurance, information technology, and the help desk before project kickoff face a significantly greater chance of failure or, at best, exponentially higher costs. Nothing has been more frustrating or costly to our clients than defects that could have been identified during the planning stages. As the project moves through the software development lifecycle, the cost to correct issues escalates. Obtaining input from each group from the beginning will mitigate the risk for serious errors down the road. By allowing input throughout the planning process, the organization will be committed and provide the resources necessary to complete the initiative.
After the plan is complete, the estimates should be reviewed to ensure they make sense. Errors in timeframes or resources required can considerably impact cost projections. Meet with each department leader to consider the project plan and review resource requirements. Once the review is completed, get sign off from each department and present the plan to the executive team for final approval.
5. Resource Assignment
Ensure that the assigned resources have the correct skill set. Everyone likes to learn something new, but don’t think that Mike from Accounting is suddenly going to be your new .net software developer or that Bob the janitor is going to head up test automation. Also, check with each resource to ensure that any planned time off will not interfere with getting the project into production on time. Nothing is more frustrating than to find out, a week before the system is scheduled to be pushed into production, that a key member of your implementation team will be on vacation for two weeks.
Lastly, QA teams are a big part of the problem. Unfortunately, some in our industry chose QA as a career path for the wrong reasons. Those that have the view of QA as the “Gate Keeper” rather than QA as a member of the team need to be weeded out of the QA industry. Our jobs as QA professionals need to be about assisting in the development of quality software not preventing it!
6. Technological Foundation
Before embarking on the project, perform a complete review of the projected system architecture documents. If using cloud services, be prepared for the costs associated with these services. We were once part of a large enterprise replacement project where the only components that remained, a year after implementation, were a few databases because the foundations of the system were based on outdated technology.