7 Out of 10 Custom Software Projects fail! This simple age old 80

7 Out of 10 Custom Software Projects fail! This simple age old 80/20 rule 'with a twist' helps you avoid failure


Published on: 05 Nov 2015

By Vinod Subbaiah

Share This:

It is estimated that 75% of all IT projects fail to meet the deadline and end up with unplanned costs.

Gartner survey published in 2012 points to the fact that most projects fail because companies fail to accurately estimate the scope of work in the initial stage. In the following sections you are about to learn how you can use the age old 80/20 rule with an ‘interesting twist’ so you can avoid project failures, minimize scope creep, and possibly eliminate cost and time overruns.

Estimating the scope of a project in the initial stage is easier said than done. At times, scope estimation without a proper requirement gathering process can really feel like shooting in the dark and hoping you’ll hit the mark.

If you’ve been in the business of Custom Software Development for any length of time – whether as a vendor or as a client, you’ll know that the  initial requirements are usually very preliminary. Generally speaking, if you are looking to build a custom solution, it is either extremely difficult or simply impossible to come up with all the requirements independently without collaboration.

The same way a building architect would have to consult a structure engineer, electrical engineer and the person in charge of plumbing and air conditioning to come up with a comprehensive building plan, a software vendor’s business analyst collaborates with the client and his team of experts – a solution architect and a project manager to clearly flesh out requirements for the custom software.

A solution architect would look at the requirements from the technology point of view to work out potential stability issues and integrations with third party systems. A business analyst looks at it from a functional standpoint by looking at the client’s specific business problems that need to be addressed. Only a collaborative effort could help capture all of the project complexities, potential pitfalls and hence arrive at the accurate scope of work.

The Real Problem…

Typically, a custom software vendor has to conduct several interviews, and have several rounds of discussions with stakeholders to clearly understand your business requirements, intended audience, business goals, and dependence on existing systems. This usually involves interviewing you and other key stakeholders of the project so that the scope and value of the project can be accurately estimated. If the custom application has to integrate with your existing software or talk to other third party systems, the complexity and time increases even more.

As you can tell, this involves a lot of work. It is difficult for a software vendor to put in this kind of effort to estimate the project scope and come up with an action plan without the guarantee of a contract.

Likewise, it might be risky for you to sign the contract and award the entire project to a vendor you barely know.

Pareto’s ’80/20′ to the Rescue?

80/20 Rule, popularly known as the ‘Pareto Principle’ was coined by Vilfredo Pareto in the 18th century. Pareto observed that everything in this world followed an interesting distribution pattern.

According to the rule, “Roughly 80% of effects are from 20% of causes”

Strangely, this applies to just about everything in life.

  • In economics, 80% of the wealth is owned by 20% of the population
  • In business, 80% of revenue comes from 20% of customers (or products)
  • 80% of sales comes from the top 20% of the sales team
  • In software, 80% of the real problems are caused by 20% of the bugs

80/20 Rule for Software Development…

Gathering functional requirements and documenting them is popularly known as the Discovery phase or Requirements Gathering Phase. This usually takes about 15 to 20% of the overall project time. Yet, this is the most critical step in software development.

As the Gartner Research confirms, most projects fail because the vendor does not do a thorough job in grasping and documenting the requirements. 80% of project complexities and issues can be captured beforehand by an effective discovery phase, which takes up roughly 20% of the project time.

Typically at the end of this Discovery process, you get the following documents, which in itself carry great value, and can serve as a blueprint for building your application:

  • A detailed requirement document
  • A project plan/schedule
  • UI/UX wireframes and design concepts
  • Testing plan and use cases
  • Cost proposal
  • Project timeline

So instead of taking a deep dive and engaging full throttle with a vendor by signing a comprehensive software development contract, you could sign up for only a discovery phase. This is a risk free way to work closely with a vendor to evaluate their approach and capabilities, before engaging in full-blown implementation.

Because the discovery phase involves working closely with senior project management team, by the time this phase ends, you would have developed a significantly better understanding of your vendor’s capabilities and approach, while also getting your requirements nailed down to the finest detail.

Since you will get a detailed project timeline and accurate cost estimate before work starts, you can be certain that you won’t face any unexpected project delays or cost overruns.

’80/20 with a twist’ and an Irresistible Offer…

Perry Marshall in his book ’80/20 sales and marketing’ breaks the 80/20 principle a level further. If fixing 20% of issues solves 80% of potential problems and failures, how about extending the Pareto principle to this 20% of issues? Obviously, even this 20% of issues should be following the 80/20 rule, right? Accordingly, 20% of 20% of the issues lead to 80% of 80% of the problems!

Sounds confusing? Let’s break this down.
20% of 20% is 4%
80% of 80% is 64%

Thus, by addressing 4% of the issues you face with respect to scope estimation, you could avoid 64% of potential problems.

Vinod Subbaiah Vinod Subbaiah