Project reporting

Monday, April 07, 2008 11:27:34 AM (Mountain Daylight Time, UTC-06:00)

Many organizations require a fair bit of weekly or monthly project status reports in order to provide invoices to clients and executive level visibility into project status.  Recently, I've been working through the issue of project reporting on our agile projects at the request of our COO.  He has implemented a policy requesting weekly project status reports that require reporting on the iron triangle of scope, schedule and budget.  It's not an overly complicated report and it doesn't take much time to assemble.  However, I'm not entirely sure that it provides useful information for our customers and our executives.  It's very easy to gloss over the facts in a line item report with very generalized reports for milestones, schedules, and forecasts reported only by a project manager.  Currently, my scope status section of the report looks something like this:

Milestone Schedule Current Forecast Status
Iteration 1: Foo Functionality 3/24-4/4 Complete
Iteration 2: Goo Functionality 4/7-4/18 On target In progress

I'm not sure I see much useful data here.  What I think is so valuable about Scrum and tracking our progress in Rally is that we have actual metrics being reported every day directly by our development team.  We have iteration and release burndown charts that show our progress on a daily basis from real reported metrics.  We have a prioritized project backlog that shows what's been completed and what we have left to do.  Our user stories in the backlog all have story points associated with them, and based on our team velocity, we can estimate how long it will take to complete the entire backlog or any portion of it.  Within our iteration backlogs, we have fine grained tasks with estimated and actual hours for each task.  In addition, we can add hourly rates to each developer, and based on the actuals reported through Rally, we can derive our budget status, which is especially important if we are working on a fixed-price contract.

I think that the metrics provided by using Scrum and Rally together provides far more information and visibility into the state of a project than a simple line item status report.  And, because the metrics are based on actuals being provided in near-real time by project team members, executives and customers can "peek" into the project at any given moment and know exactly what the situation is.  They don't need to wait for the weekly or monthly status reports.  Rally is especially helpful in this case because it provides project, program, and workspace dashboard widgets which can provide burndown charts for all currently active projects.  With agile project reporting, there is nowhere to hide poor performance with generic terms that don't deliver much information.  Everything is visible and accessible to everyone. 

Wednesday, April 09, 2008 8:41:59 PM (Mountain Daylight Time, UTC-06:00)
I agree as well. The metrics out of Rally are easy and answer many of the simple questions that could reduce delivering status in multiple formats, multiple times. I do think there is a benefit to have 2 other things possible in a side-by-side report of Rally's burndown: 1) issues and 2) a text field for a status. This way you could allow the scrummaster to make visible to the team and execs the most important things: status (burndown), issues, and an explanation for the burndowns positive (ie, things are on track, demo to be held on xx/xx) or negative (ie, burndown shows an overage and we are removing USxxx to mitigate the problem). We currently string these things together.
Larry Wolff
Comments are closed.