Parking Lot Diagrams Revisited – Using Area to Show Effort

Parking Lot diagrams are a great way of summarizing an entire project’s progress and status onto a single page. They illustrate work done, work in progress, work planned and identify what is behind schedule.
 
In this example we can see that “Stock Search” in red, is behind, it was due to finish in November. “Create New Order” shown in green is complete, the boxes in yellow are ‘in progress’ and those in white have not been started yet. I have posted previously about their use and examples of how to produce them.

However, they miss an important element, the relative sizes (usually in terms of effort, but could be cost or risk) of the functional areas. So, in the example above, the fact that “Enter Order Details” might be 3 times the development effort of “Create New Order” is likely lost on the stakeholders reviewing the chart. Sure they can look at the number of features 15 vs 5 and likely surmise “Enter Order Details” is more work, but upon first impression, this is not immediately apparent.

So, bring on Scaled Progress charts, the box size represents estimated development effort. I have been using these with my current Steering Committee for a while. I meet some of these people infrequently and these charts provide a nice reminder of the overall project scope and where the project progress right now.

 
Development sequence is left to right, top down. We can see that progress is being made in “Contractual Estimating” which is a bigger chunk of development than, say “Monthly Billing”. I use PowerPoint for these diagrams, the box widths are all the same and I use the development point estimates to determine the height of the box. This way box size (area) is proportional to development effort. The percent complete shading effect is created by using another similar sized shape drawn on top shortened to the appropriate percent complete.

All this manual sizing and progress bar manufacturing is time consuming. What I really want is an Excel based Parking Lot diagram that automatically scales box size (area) to development effort. Like the one shown below:

 

Only I had to create this version in Powerpoint and that is not really practical, as estimates for functional areas change frequently, and while Excel can easily do the colour changes via conditional formatting, this has to be done manually in Powerpoint). So, if there are readers out there who can do this in Excel I would love to hear from you and share your solution with other readers here.

In the mean time, with my goal of keeping these graphs quick and easy to produce, I have been looking around for other ways of showing progress against work packages of different sizes. Microsoft Project is of course a prime candidate, and using the Tracking Gantt View shows progress against tasks, rolled up by group. I have recently been playing with the MS Project 2010 beta and the screen shot below shows the same project in MS Project 2010.


 
This is quite useful and I particularly like the new Timeline feature of MS Project 2010, giving a graphical summary of the entire project schedule above the Gantt. We can see the progress against each of the Feature Groups. For instance  “Create New Order” is 100% done, “Capture Customer Details” is 75% done, and “Stock Search” is only 95% done yet lagging behind the vertical orange line marking today’s date, so therefore it must be behind schedule.

However, this is my problem with Gantt charts, unless you are a project manager, or someone who understands Gantt charts, they are not that intuitive. This mess of bars accurately shows progress and schedule, but is difficult for many stakeholders to interpret. Notably, it fails in a couple of areas:

1)    It is difficult to see how the work areas contribute to the whole project
2)    Issues such as late tasks may not be immediately apparent

So what other ways of illustrating how components relate to the whole, and illustrating progress do we have? Well, pie charts are good at showing how components relate to the whole, and maybe we can do some fancy overlay of percent complete.

Here I have broken the work areas into pie segments to show their relative sizes and superimposed an additional pie segment which represents percent complete. This is OK, we could do some conditional formatting to make late segments change colour, but it breaks down when the number of segments increases. Plus it fails my “easy to create” requirement as this was a combination of Excel and Powerpoint.

So perhaps we are back to some kind of scaled bar chart

Of one sort or another...


 
Yet they are looking a little Gantt’ish again. I am hoping that this post will prompt someone to show us how we easily create a one page image that represents the whole project scope and then progress against each of the various components inside it.

Comments

[Guðlaugur Egilsson]

I'm curious. What is the problem that progress in percentages is solving? Last time I knew that was considered an anti-agile practice to use this metric due to all the different kinds of disfunctions that follow the focusing on schedule that this practice brings.

You can measure how much is left in all kinds of ways other than using percentage done.

[Mike Griffiths]

This is a good question and I should have explained I am not reporting percentage complete against a schedule. I am reporting percent complete in terms of stories done verses stories remaining. For instance a feature like “Order Movie” may contain 20 stories, I want to report after completing 10 of them, we are about 50% done that feature. Parking Lot diagrams let us roll up story progress by feature group and display the results as a dashboard to give a comprehensive view. I agree that focussing on progress against a schedule that may well be flawed is not a great thing to try. Thanks for raising the question, likely other readers were thinking the same, I appreciate it.

Regards
Mike

[Guðlaugur Egilsson]

I see. For that kind of metric, I prefer measuring the level of completeness across the features, rather than percentage of stories done. I very recently went to a CPO class by Jeff Patton which taught this very well IMHO. In this metric, each feature gets a score on a grading scale (A+,A,A-,...,F), denoting the completeness of the feature in terms of how usable and pleasing it is, basically on the scale from meeting minimum functionality to being aesthetically pleasing for the user. This can be shown very nicely on a bar graph, with a bar for each feature.

The plus with this approach is that it does not assume that you knew beforehand how much needs to be done beforehand to be shippable, it leaves you open with a decision to ship at any time, given that the features were sliced up into stories and implemented properly. And, it does give you a sense of the real quality of the system as it is.

[Mike Griffiths]

Hi Guðlaugur,
I like the A-F scheme for a subjective measure of feature completeness, but often sponsors want to guage percent complete to validate estimates. I suspect there is a place for both sets of metrics on a project.
Thanks for sharing, regards.
Mike

[Robert Cowham]

It should be easy to take an Excel spreadsheet and automate the transfer of information to PowerPoint. If you care to post example spreadsheet and example result in Powerpoint...

You can contact me through blog below.

[Mike Griffiths]

Hi Robert,

Thanks for commenting and your offer of help. I have sent you some examples and would love to share the solution with my readers. I have also been corresponding with Chandoo from the “Pointy Haired Dilbert” Excel blog and he has explained why what I am trying to do may not be the best way of visualizing data. Anyway, I am working on an updated post to address his points and it should be up soon. Thanks again for your help.

Best regards
Mike.