THE ABSOLUTELY UNBEATABLE WAY OF ESTIMATING CUSTOM SOFTWARE PROJECTS

//

Successful projects require accurate estimates of the effort required to deliver on the project requirements.

Where do Project Budgets Come From?

So where do Project Budgets actually come from?

Budgets for a project are set in various ways.

  1. Market and Competitor’s Price
  2. Urgency
  3. What the board will fund
  4. Perception of Value
  5. An actual estimation of the actual costs of the effort

My times the actual estimate is the last consideration in setting the budget as budgets are often planned in advance and when the project team comes up with its plan then put it to management they are told they came up with the wrong answer and to replan.

A Target Focuses the Mind

One good thing about setting a target budget and delivery date is that it focuses the mind. At first it should focus the mind of the leader and then through them the entire delivery team. This can facilitated partly be setting well thought out incentives.

Risk Management

To ensure your greatest chance of success you need to identify and manage risks.

Some risks might be:

  1. Sufficient resources
  2. Security of finished solution
  3. Scalability of delivered solution and its ability to support the expected load
  4. Product Market fit
  5. Learning curve of new adopted technology

What you want to do is schedule these risks in a way that they reduce as your project progresses.

Production Possibilities

The Production Possibility Frontier is an economics term relating to the choice between producing 2 different products. Consider a farm community that produces both wine and cotton. Given they have limited inputs and time then producing more wine will mean producing more cotton.

At point A they produce more wine and less cotton. At point B they produce about the same of each. At point C more cotton. At point X they produce about the same of each but not the maximum amount possible. Point Y sits outside what is currently possible.

Expanding What is Possible

If the farmer’s technology improves by for instance hiring more staff, introducing irrigation or getting a tractor then what’s possible expands.

So now that frontier has moved outward it becomes possible to produce at point Y.

How Does this Apply to Software Development?

In software projects we talk about the concept of velocity. We can invest our resources in either 2 products:

  1. New or updated features
  2. Acceleration

In a future article I go into more detail on how to apply this speeding up your schedule. For now we are going to estimate a single sprint.

The Super Invoicing Solution

For this exercise we are going to develop and estimate for a a new invoicing solution we are calling Super Invoicing.

The first step is determine what components this solution will have. We need to determine the requirements. There are generally 2 types of requirements:

  1. Functional
  2. Non Functional

Functional requirements are about a specific feature of the solution.

Non-functional requirements apply across the solution.

Let me give you an example. Consider the following requirements:

  1. The site should be secure
  2. Pages should render in 2 seconds
  3. User need to login via a login page
  4. Invoices are entered via an invoice entry screen
  5. User should be able to send an invoice via email

In this case the first two requirements are considered non-functional as they apply across all features and the last 3 are specific functions.

Work Breakdown

Now we need to break down the requirements into more detail. I prefer to use a mind mapping tool such as Simple Mind.

Relative Complexity

Not all tasks are created equal. To deal with this we attribute relative complexity to each task. In an Agile methodology we tend to use Fibonacci numbers.

1 – Simple task

2 – Fairly simple task

3 – Easy task

5 – Getting more complex

8 – Medium complexity

13 – Complex task

The number assigned to each task is called the story point value.

Velocity and Calibration

We need to map story points to actual time. This is a factor of the developer availability and capability. For this exercise we estimate the average developer on the team can complete 2 story points per day. This equates to the “Velocity” of the team. We also estimate from experience developers work 6 hours per day on the project. You should be able to slowly increase a team’s velocity over time but hours per day will be fairly static.

Planning Worksheet

The planning worksheet is designed to give a snapshot of a project. Both an initial estimate and actual progress over time.

To use the worksheet enter in the project details in the highlighted yellow cells. Also enter the actual completion dates as each task is completed.

Performance Tracking

As tasks are completed the actual completion date is entered into the worksheet. On the worksheet tabe called: Earned Value you can check the project performance.

What you want is for the dashed green line (the “Forecast”) to track dashed blue line (the “Target”). In the example below the forecast is slightly above the target so the project is slightly ahead of schedule.

Conclusion

Succeeding at custom development projects requires attention to detail in planning and diligently tracking progress, taking corrective action when required.

Leave a comment