Posts Tagged ‘estimating’

Fixed Price vs Daily Rate – Lessons Learned From Agile Scrum

Wednesday, April 14th, 2010

If you are involved in quoting for software projects you have to make sure that you estimate each job correctly or you could find that a job quickly becomes unprofitable. In reality it is very hard to estimate as you rarely have a defined technical spec and requirements are constantly changing.

Often the scope creep, changes and alterations can account for 20-30% of a project, could there be a better way?

I am not sure that the fixed price model is so valid any more, the scope is rarely fixed so why should the budget be fixed? I am going to experiment with a new model that take some ideas from agile development method scrum.

Instead of a scope of work have a backlog

This is a high level document for the whole project. It contains broad descriptions of all of the features, wish list items and nice to have items. The most important part is that it is then prioritised by business need with rough estimates for business value and development effort. This document should be owned by the project manager and the client.

Fast iterations, the sprint backlog

This document shows all the features that are going to be developed in the upcoming sprint (typically 1-2 weeks). The highest priority features from the backlog are developed first. The features are broken down into tasks (which should be no more than 2-12 hours work). Anyone on the development team can then work on a task they are not assigned. A task sheet is often used so you can keep track of the progress of the tasks.

Burndown

The burndown chart is something that is visible to the whole team and the client and shows the remaining work for the current sprint. It should always be up-to-date and used as a reference for when the sprint will be complete.

How can this help us with pricing?

The great thing about this method is that it prioritises the most valuable features for the business. It also means that if the client wants to add new features they must take out other features or it is very obvious that the scope has increased and that will incur an extra fee.

So your fixed price means a fixed amount of effort which is then allocated against tasks. Once the allocated time runs out and the agreed features are delivered, your client can then buy more effort or sign off the project as complete. I am not sure how this will work in practice but there has to be a better way to estimate and cost projects.

Tags: , , ,
Posted in Naked CTO | No Comments »

A Process For Estimating

Tuesday, March 24th, 2009

Following on from yesterday’s post, some people have asked me for my actual process of how we estimate.

  • Create the product breakdown schedule (PBS) – this is a list of products that you are delivering
  • Create the work breakdown schedule (WBS) – this is a set of hierarchical tasks and sub tasks
  • List any material costs from the PBS
  • List any HR costs from the WBS
  • Create a network diagram from the WBS
  • Ally the estimating strategies with the project life cycle

It is also very important to document the assumptions that you are making when you are estimating.

Tags: ,
Posted in Naked CTO | No Comments »

Estimating – The Lost Art

Monday, March 23rd, 2009

Estimating seems to be a lost art, it is one of the most important skills you can learn as it is one of the key factors in job profitability. If you do not get your estimate right and you have a fixed quote, you can literally end up out of pocket. If there is a big overrun then it can affect your reputation.

Estimating improves with experience and I am always calibrating my estimations at the project debrief. Also the more estimates you do the more you can see patterns and be able to increase the tolerance in your estimating.

Methods of estimating

There are many different methods of estimating, I have outlined a few that I have come across in different organisations. There is no right and wrong method, and the method used will depend on the project’s size and scope.

1. Top down estimating

This is used when there is limited amount of detailed information about the project, for example in the early phase of a project. Top down takes the whole view of the project. generally working by analogy with other similar projects that have accurate historical information.

2. Bottom up estimating

This works by breaking the project up into small pieces and estimating each individual piece. The people who provide the bottom up estimates are usually the ones that will perform the work. It is usually driven by the work breakdown schedule or task list. Bottom up estimating tends to underestimate as the inter-task elements or glue tasks, such as project management tend to get forgotten.

3. Comparative or analogous estimating

This is another method where estimates are driven by analogy with the details of previous projects. It is frequently used to estimate project costs when there is little detailed information about a project (early phases).

4. Delphi Method

Uses a number of different estimates from project staff and then uses a weighted average. It uses expert opinion of a group to arrive at a consensus. The process is iterative and anonymous. After each person has estimated the coordinator gathers the estimates and re-distributes them. Each person then re-estimates based on these new guidelines and the process stops when a consensus has been reached.

5. Parametric estimates

Uses statistical models obtained from historical analyses of cost, effort or material data. This is mostly used in life cycle costing to see the costs over the lifetime of the product. These costs look accurate so can be dangerous.

6. Three point estimate method

Uses an optimistic (O), most likely (ML) and pessimistic (P) value of time and cost. To get the planning value (PV) from the three point estimate with the following formula: PV = (O + 4ML + P) / 6. The multiple of 4 acts to weight the figure in favour of the most likely.

Remember that estimates should be reviewed regularly throughout the project.

Tags: , ,
Posted in Naked CTO | 4 Comments »