Clarety’s 10 Laws of IT Project Estimation

Posted by Kevin Brady on Fri 1st September 2006 at 09:00 AM, Filed in Programme Management,  Project Management

(1) Never Never “Top-down” estimate your Project. Please see Timeboxing IT Projects Parts 1, 2, 3 for definition of “Top-down” & “Bottom-up” planning /estimation and why it is always preferential to develop estimate on the basis of the later.

(2) Never Bully your project team to provide estimates. Do this and you will end up with a CRAP estimate and an unfeasible project to run. Furthermore, you now have a bunch of de-motivated staff who, if things do not work out, will say “I told you so”. Like a Bomber Pilot flying over enemy territory, there’s not much future in doing that.

Encourage project team members to explain their reticence in give estimates through additions to the risk/issue and assumptions logs. 

(3) Estimates given by your project team are always light on time /effort

The reasons for this run as follows:-

• Many IT Professionals feel intimidated by senior management and feel a need to tell them what they want to hear rather than get involved in discussing reality because of worries about being branded “Negative” – “Not a team player”. Seen this all to often.

• Very often IT Professionals are very over optimistic about their abilities and want to impress people.

Either way the result is the same - A plan, which is thin on tasks with those tasks, underestimated in terms of duration and effort.

Always start the estimation process with the belief that your “Bottom-up” estimates will be 100% light in terms of duration /effort.

(4) Accurate “Bottom-up” estimating involves putting peoples jobs on the line

Your job as a manager is always on the line.  So a little pressure delegation is not always a bad thing.

Always make the following clear when asking for estimates from your team:-

• They will ‘own’ the tasks and products they specify and estimate

• These will be Timeboxed

• Their future salary reviews depend on performance against these estimates.

Until you get a “butt clench factor of 10” for each member of your project team you are not going to get accurate estimates. You want to get the degree of focus that a skydiver has just before he exits a plane at 25,000 feet. Only then do you get serious, accurate, and well thought out estimates from each team member.

(5) Always put contingency in your estimates

Checklist typical contingency items you need to take into account into your contingency estimates i.e.

• Untaken holiday leave

• National Holidays

• Sick /Illness rates

• Go slow time around Christmas and New Year

• Risk /Issue profile

• Assumption profile

Have a back to front knowledge of these estimates because you will be challenged on these, and your creditability and your project could be blown away if you do not have sound reasoning behind you contingency estimates.

(6) Where possible review old project plans and associated artefacts.

These old project plans, if kept up to date, can be useful checklists for picking up missing tasks /products from your plan

The risk /issue and assumption logs are also valuable checklists for double-checking that you have identified all the key risks /issues and assumptions

This is a key, and often overlooked, activity.

(7) Always assume with the best will in the world that when complete your estimate is likely to be 30% light in terms of tasks specified.

This because it is very difficult the further away one looks in terms of duration, to imagine all the detailed tasks one needs to carry out to deliver a product or stage. It’s a bit like looking at a picture hanging on a wall. The further you are away from it the less detail you see. Stand far enough away and you’re guessing what the picture is about. Project estimation is like this.

(8) Never release an estimate until you resource level you project plan

If you do not do this, you will be high on costs and light on time. Disaster if you don’t take this boring activity seriously.

(9) Always normalise your estimates before releasing to the client /sponsor

• Check your plan’s critical path

• Check to see all tasks have attaching dependencies. All tasks must have dependencies! If they don’t then they are either not necessary, or should be perhaps a separate project and thus part of a programme of work and not a project.

(10) Always base cost estimates on resource durations and not from the resource plans generated by Microsoft Project

MS Project assumes that when a task is completed the resource is dumped back in the resource pool and is no longer chargeable to a project. Hired project resource is not usually paid on peace time work i.e. people get paid for the days and hours worked. These down times are often born by the project budget and are called “project burn cost”. MS Project is not good at making assumptions concerning people’s contracts of hire and relating these to MS Project resource plans. This requires expert tinkering by the project manager. Very often these down times are only a few hours or half a day and as such it is not feasible to reallocate these professionals to an alternative project.

I therefore tend to use resource start and finish dates on projects (MS Project Resource Sheet can tell you this) and the average percentage of utilisation to come up with the utilisation cost and the burn cost of all the resource working on a project.

Reader Comments:

Next entry: FREE Prince 2 Project Initiation Document (PID) Template

Previous entry: Timeboxing IT Projects - Part 3

<< Back to main