Quick estimation technique
(See also my notes on Function Point Analysis.)
My clients like being offered a menu of functionality so they can pick and choose what they want included in the delivered software based on how much this will cost. That means I need to be able to divide the functionality into components the client will understand, and need a quick method of getting a estimate for each bit. I find clients understand use cases, so these are the building blocks I use for an estimate. Because my clients want a price on each use case the price for the use case must include a share of the effort for auxiliary tasks such as project management, testing, deployment, etc and for contingency. A project estimate then becomes just a matter of picking the Uses Cases to be included.
Being an advocate of an Agile techniques my approach to planning and tracking development projects is to concentrate on the activities undertaken by developers and focus less on other types of activities/people. The idea is to worry about what matters most, and for me that is delivering functionality, and fit the other stuff around it. All of this has an impact on my estimating strategy, as I'm not going to spend much energy on estimating activities - the auxiliary activities - that I'm not going to spend much time tracking when the project starts.
Process
Ultimately the overall project estimate derives from the estimates to build code for individual use cases. I have the technical people - usually the technical lead - estimate each use case; the estimates must cover low level design, coding, and unit testing, but not other activities. I then add a weighting to each of these estimates for Auxiliary tasks and Contingency. The weighting is based on experience from previous projects, tweaked to cope with the requirements of the new project. Typically a new development for a new client will have a significantly higher weighting (say 2.2 - 2.5) than a maintenance project for a existing client (say 1.7 - 2.0).
As mentioned above the weightings aren't just pulled out of the air, they are based on previous projects. Generally I'm interested in tracking the effort for different roles, even if several roles are undertaken by one person. I currently track the following Auxiliary tasks:
- Management
- Project Management
- Technical Leadership
-
Analysis & Design
-
Business Analysis
-
Information Architecture
-
Visual Design
-
System Architecture
-
-
Testing
-
Functional
-
Performance / Scalability (this is separate from other testing because it is done by a developer not a tester)
-
Environmental (by environmental I mean such things as testing under different browsers or operating systems)
-
-
General tasks
-
meetings, miscellaneous
-
toolsmith,
-
travel
-
-
Documentation
-
user guides
-
on-line help
-
-
Infrastructure / Deployment
-
setting up environments
-
packaging releases
-
applying the releases
-
Then you have to add on Contingency. I tend to use a fairly low contingency (say 13-15%) and rely on strong change control to limit the risk this entails.
Example
If my Technical lead gives me the following estimates for a maintenance project ...
- User applies for membership - 20 days
- Administrator approves membership - 5 days
- User views graph of XYZ - 5 days
I will apply whatever weighting is appropriate for this product and client (say 1.7) giving the following estimates to the client:
- User applies for membership - 34 days
- Administrator approves membership - 8.5 days
- User views graph of XYZ - 8.5 days
Pros and cons
The advantages of this technique are:
- It is fast.
- It gives the technical people responsibility for estimating technical things.
- It gives the PM responsibility for estimating project wide factors.
On the down side:
- It can't cope with projects where there are non-labour costs, e.g. hardware, software, or team drinks. There is nothing you can do about extraordinary costs, but if your team culture requires team drinks for all projects - and in the UK this is true - then I'd suggest you just edge up the weighting a fraction (say 0.5 - 1.0%) to allow for it.
- It relies on having historical data, so you have to guess for the first one.