That Estimation Thing

Right now I’m managing 3 projects at TAMU and 3 projects at AGSI.

 

It’s interesting because none of the programmers are in a traditional work environment.

 

The TAMU programmers are all part time, and the AGSI developers are all over the World and are all contract.

 

Estimating tasks, identifying risks, figuring out budgets and delivery dates are all part of management.  But doing it with non-traditional resources means that I have less of the "body of knowledge" to rely on.  I have to roll my own. 

 

It’s ironic, because when I first started supervising other programmers some 20 years ago, I didn’t know what I didn’t know about managing programmers.  Over the years I have made many mistakes, and have discovered many resources.  The Internet surely helped as it provided access to small snippits of knowledge, articles, and of course, others in similiar lines of work.

 

Which brings me to my current project – "that estimation thing"

 

My current experiment (and there have been MANY) involves Excel and one tab per deliverable, one line per person’s task.  I started with columns for initial estimate, current estimate, % complete, risks, and notes.   The intent was to be able to produce a Velocity Chart to provide us an indication of our progress (rear view mirror) and some idea of our anticipated rate of work (the road ahead).

 

Unfortunately, we seemed to pickup new tasks so quickly that the scope changes were all in the wrong direction.  Yes, that in itself was a good indicator, but it didn’t help me understand progress.

 

My next attempt at this was with the AGSI coders.  Here we are trying each deliverable per tab, one line per person/task.  Columns are:

Task: Task name

Days Work: Sum of the columns below

% Compl: Coder’s estimate of completion

Est Fwd:  Calculated from % Compl and Days Work

Days Scope: Original, unchanging, estimate of work (in Days)

Days Act. Wrk: Only when % Compl is 100% does this get set to Days Work.

Who: Assigned developer
Notes:  Comments

[one col per week]:  Actual days of work for the week.

 

Note that we update this once per week right before one of our two IRC sessions.

 

We have the velocity chart and the forward estimation of work completed is based on the average work done, adjusted for holidays and other known down days.

 

We recently did a project for a Defense Contractor and starting the design in October, prototype code in November, and tracking in November, and saw that we’d be done the 1st or 2nd week in January.  We triaged the requirements and delivered the first week in January.   Our actual work ended up pretty close to the revised scope.

 

We are repeating this for a Beta delivery and will see how it turns out.

 

I was pleased enough that I’m going to take this version back to TAMU and try it on a new release for eCalc (http://ecalc.tamu.edu)