Software Estimation: Are we neglecting something important?

Software Estimation: Are we neglecting something important?

Let me take the liberty to ask - how accurate was the effort, cost and schedule estimate for your last software project? Were you within 10 percent? 50 percent?  100 percent?

Recent studies show that

  • Only 9% of IT projects in large businesses completed on time and on budget;
  • 53% of projects cost 200% of original estimates
  • Projects in large US companies delivered with only 42% of originally proposed features

Estimating software projects is as much an art as a science. While there are several environmental factors that need to be considered in estimating projects, two key data points are essential:

  1. Size of the deliverable. This can be derived from Function Points (FP).
  2. Capability to deliver no. of Function Points per hour or per day or per month (for a specific tool set and platform). This is also known as “Productivity”. Productivity can be calculated based on past project performance or by using industry benchmarks.

Project Effort = Size / Productivity

Above can be called Engineering Effort (Software Development Life Cycle effort).

Can we say, this is the FINAL Effort to deliver the project?

Answer is “NO”.  Then, let’s discuss WHAT IS MISSING here?

Any Software Project consists of diverse tasks which need to be coordinated and integrated carefully on and above the engineering tasks. Unfortunately, the time and efforts needed for coordination, integration, implementation, business waiting time etc. are often underestimated (or even totally overlooked) by project decision makers. Let’s call this effort as “Surrounding Efforts” which are essential to deliver any software project. If these efforts are not included in Cost, Schedule calculation, then are we expecting the Vendor or the Implementing Agency to pay the Cost of these additional efforts on and above the Engineering Efforts?

In principle, each applicable Surrounding Efforts should be identified as some percentage of the Engineering Efforts and added in the overall Engineering Effort or the Project Efforts.

Example: Let’s say that Project Management Effort is expected 15% of the Engineering Efforts

- Other possible “Surrounding Efforts” are:

- Time spent on various meeting including review with client

- Business Waiting Time

- Delay in getting approvals from clients

- Release Management

- Quality Control Effort

- Staff Training Efforts

- Liaison / Coordination for Signoffs Efforts

- Post-Implementation clean-up efforts

- Network Support

- Warranty

- User Documentation

- Contingency for ambiguity or unclear requirements etc.

While adding “Surrounding Efforts” to calculate the Total Project Efforts, do not forget to reduce the effort if there is “Re-usability” in code or time savings due to use of tool or automation.

 This means:

Overall Project Efforts = Engineering Efforts + Sum of (all applicable Surrounding Efforts) – Effort savings due to REUSE

Example: In a Project A

If Engineering Efforts is 100 person Days………………………….....……………....…(A)

Let’s say that, applicable Surrounding Efforts are:

Project Management Activities – 15% (of Engineering Efforts) = 15 Days……  (B)

Delay in getting approvals – 2% (of Engineering Efforts) = 2 Days………………(C)

Post-Impl. clean-up efforts– 5% (of Engineering Efforts) = 5 Days..............…(D)

Staff Training Efforts – 5% (of Engineering Efforts) = 5 Days…………………...…(E)

Contingency – 10% (of Engineering Efforts) = 10 Days ……....……………………..(F)

REUSE Savings – 5% (of Engineering Efforts) = 5 Days …………………………….(G)

Overall Project Efforts = (A+B+C+D+E+F) – (G) i.e. 132 Days,

Which is 32% more than Engineering Efforts

It is advised that any cost, schedule etc. calculation should be done using “Overall Project Efforts”.

Note: Normally, the Surrounding Efforts including Contingency Effort should be 25-40% of the “Engineering Efforts”. Any exceptions need to be handled separately.

Good one. Huge efforts spent for customer depedencies be it requirement clarifications or with their other applications or integrations, approval etc. The list will be never ending.. Also, one key point, we do sizing using FP for functional requirements, but for those "Code Data" or Masters management screens - efforts need to be spent, which in general FP doesnt support. I would suggest to include that as well as part of overall efforts.

Total surrounding efforts should be within 20% of total effort. Then it would be reasonable and cost effective. I would also suggest that the delay in getting the approvals from the client should be out of total effort. This effort also can be excluded while calculating productivity.

In my opinion delivery rate not only includes Coding and Testing effort. It involves all cost including Project Management. Delivery rate derives from Past projects which includes all cost which was delivered. Some PMs add contingency effort for previous release scope creep.

To view or add a comment, sign in

More articles by Rashmi Jain

  • Handsome degrees in pockets make a Good Leader?

    Many "Agree"..

    3 Comments
  • Am I ready for Start-up?

    There is no surprise in today’s scenario, if an enthusiastic and entrepreneurial teen or a fresh graduate decides to…

  • Lean Process Framework

    It is a common practice in any organization to have multiple projects which are mix of development and enhancement. And…

    5 Comments
  • Software Estimation is mix of Art and Science

    Poor estimation haunts the software industry… The primary purpose of software estimation is to determine if project’s…

    3 Comments

Others also viewed

Explore content categories