Project Frontier®

Hi, It's interesting to hear your perspective on the piece I wrote. I'm interested to know why you'd quibble with my extrapolation method. Is it because I'm extrapolating linearly rather than with an S-curve? I guess that reflects my agile development background, where we go out of our way to make the project linear(ish) because that makes it easier to manage. Of course , we never manage to make it perfectly linear. In my experience we can get surprisingly close, but we do tend to get a non-linear portion at the end. John Rusk

John, Really great article! I understand the linear flow of Agile which (to me) is extremely cool, because it allows me to point to an example where Core Skill 1 and Core Skill 3 apply, but Core Skill 2 can be omitted without any loss of control. (I'm sorry my site-under-construction hasn't defined these skills yet; it is because a publication is pending.) My quibble was really just nit-picking. At the time I was thinking "but what if the scope were radically changed mid-way through the project?" Then it seems a linear extrapolation from Day 1 wouldn't seem appropriate. It occurred to me that a new extrapolation would begin where the change in scope occurred. Sorry I nit-picked without being specific. I just read your follow-on piece about charting scope change. That piece includes this very insightful statement "Many people do want to show several old targets...I can't see a way to solve that problem…" It is insightfutl because many information designers haven't gotten that far yet! Yes, I admit I'm one of those people who want to show old targets, because I do have an answer (but it too is not yet published). The answer is a patent-pending kind of earned-value area chart and more importantly, the answer is an ANIMATION! An animation shows the history of what we knew at the time we knew it, and the final frame is what we currently know. My technique will also be able to show rich detail to replace the Gantt chart. My business has just been awarded a contract from the State of Oklahoma to develop this animation technique. The application will be called the Earned-value Virtual-office Animator (Eva). We start development on February 1. An animation solves the problem because there are really two kinds of "time." The first kind of time is what we know about the project, including WHEN things are supposed to happen. That's the x-axis. The second kind of time WHEN we know what we know. That's the animation frame rate. Again, I think your article is superb. You should present it Agile 2007! /Garry

Garry, Thanks for the explaining what you meant about extrapolation. Your suggestion, about starting new extrapolation from a scope change makes sense. Although, as I write this comment, I realise that's not actually what I do :-) Instead, I adopt the usual agile trick of trying to estimate new tasks (the added tasks) consistently with reference to old tasks (the original scope). Alistair Cockburn explains this well in his page, which I link to from mine. E.g. Say a new task is expected to be the same size as a particular task which we have already done. Then we enter its size (into our EVM calculations) as being the same as the _estimate_ of the completed task (NOT the _actual_ duration of the completed task). The idea is that if you're estimating wrong, then you want to be consistently wrong by the same percentage (on average). If you do that, then you never need to re-start the extrapolation - you just add the new tasks onto the end of the project. It's a slightly odd concept, at first, but then it starts to make sense. There is some discussion of this in the comments at the bottom of my agile charts page. (The XP community took a different tack, trying to use an abstract measure of task size, to that you didn't have to deliberately estimate new tasks "wrong", but it think they're coming back to measuring in hours now.) Your animation concept sounds interesting. Have you seen Cumulative Flow Diagrams? They show "what we knew when" without animation, but they miss out on some of the other advantages of the EVM approach.

> to that you didn't have to deliberately estimate new tasks "wrong Make that: "SO that you didn't have to..." PS. Naturally, you _do_ have to re-start the extrapolation if you significantly change the team size.