Forums

Hi,

I get asked from time-to-time what is the best format to communicate and monitor/control project schedules with team members. For stakeholders outside of the team, I usually recommend using a table with milestones with Planned, Expected, and Actual completion dates to help track progress.

But, I was wondering for those of you leading teams, how do you communicate team progress within your team? Gantt charts, Excel spreadsheets, Tables, Network Diagrams, etc?

What do you recommend or suggest?

Ron

tcomeau's picture
Training Badge

[quote="rjholohan"]...how do you communicate team progress within your team? [/quote]

I write key dates on a whiteboard. I'm working from memory (I'm at home right now), but I think it looks like this:

[code:1]
STGMS
Build Commit Reg Test Feat Test Install
3.4 2/14 2/22 3/03 3/04
3.5 3/06 3/11 3/24 4/01 (probably 4/02)

WSS
Event IRR XRR
SRR 9/01 9/12 complete! - NGST waiting on Ball
ADU FSW PDR 3/19 @ BATC
TIM @ BATC 3/20 Reqs: Tom I&T: Laura
Class Defn's 4/01 Current version on the wall - pls comment
PDR 6/30 7/29 Traveling on my birthday. :-(
CDR TBD NGST fiddling with dates

[/code:1]

The upper example is for a systems I don't lead any more, but is helpful for either incremental development or maintenance. The columns are build number; the "commit" date -- when developers have to have their changes unit tested, committed and integrated with the development baseline; the date regression testing must completed; the date new feature testing must completed; and the target installation date. There is space for comments to the right. Uncaptured is the readiness review date, which is often the day before the target install date. The actual install date is picked at the readiness review.

The lower example is the current set of dates for the JWST Wavefront system -- the software we'll use to focus an 18-segment mirror from a million miles away.

Looking at the board you can tell the key dates for who does what by when. "IRR" is internal readiness review; "XRR" is for external readiness dates. If I get a question that requires more detail, I usually slap the answer up on the board. For example, we have a meeting in March where I'm responsible for requirements updates, and Laura is responsible for the draft of the integration and test plan. There is also a date up there that doesn't require any work from us, but does affect us -- the ADU flight software preliminary design review, which is the day before our meeting at Ball Aerospace (BATC). Most of us are going to that review, which is the day before our meeting.

A friend of mine from school uses a similar system for incremental development, but he's required to have his schedules web-accessible. So he has a webcam across the hall, pointed at the whiteboard, which updates once a minute.

The point is that while I provide the Mission Office with updates to an MS Project schedule with pretty GANTT charts, resource loading, and deltas from the schedule baseline, I don't inflict that on the team. I just put the information they need up on a whiteboard, and let them comment if they need to.

We also use burndown charts once we have individual modules or features identified. That's just a plot of items remaining for a particular build by date. I'll try to find an example that I can sanitize.

tc>

jhack's picture

We use Excel, which has the most relevant milestones culled from the detailed GANTT charts.

Each row has, in order:
What gets done by whom and when, followed by status and comments.

Status is color coded (red, yellow, green) allows for quick take on how things are going.

Columns have autofilter on so each person can look at their deliverables alone, and we can filter by status, etc...

John

BJ_Marshall's picture
Licensee BadgeTraining Badge

Ron,

Have you asked your stakeholders (internal and external) what information they would like to see and in what formats they would like the see that information? I would suggest checking out the "Tools and Techniques" section pertaining to the "Communication Plan" process under Project Communications Management in the PMBOK.

Specifically for my project, I use an MSProject report. For example, I have created a custom report that shows only open work packages (or work packages that ought to have been opened by the time of the report). The report displays the Task Notes (formatted to look like a cross between a WBS Dictionary and an Activity List), Responsible party, and Actual and Baselined Start and Finish dates.

Cheers,
BJ

tcomeau's picture
Training Badge

[quote="tcomeau"]
We also use burndown charts once we have individual modules or features identified. That's just a plot of items remaining for a particular build by date. I'll try to find an example that I can sanitize.
[/quote]

So here's a fairly clean example of what I've used in the past.
[url]http://www.stsci.edu/~tcomeau/3_42.jpg[/url]
(I was going to make it an inline image, but it's too darn big.)

This is the previous build of one of our systems. The blue line -- how close are we to done -- is the only line that matters, but the other two give you some context. You can use these for any task where you can definitively count completed chunks, and the chunks are all the same order of magnitude.

I've even used this for external communication for customers who understand the size of the chunks and the effort required to complete a chunk.

tc>

rjholohan's picture

Tom,

Thanks for sharing the burn-down chart. I am unfamiliar with these charts (I assume this is more of a software dev/IT tool?) But, I am very intrigued by it.

Are items listed bugs or are they additional features? What do you use as a baseline?

Ron

tcomeau's picture
Training Badge

[quote="rjholohan"]Tom,

Thanks for sharing the burn-down chart. I am unfamiliar with these charts (I assume this is more of a software dev tool?) But, I am very intrigued by it.

Are items listed bugs or are they additional features? What do you use as a baseline?
[/quote]

You can use them for anything where you have well-identified, similarly-sized chunks to complete. They are very popular with the Scrum community, tracking "implemented stories." I used a similar chart for a media migration project, "burning down" the number of Hubble datasets we had to move to a new archive media. Another example is Hubble observing programs for each cycle: Plot the number of science orbits remaining to be scheduled for each weekly scheduling cycle, and you can predict when all the science orbits for a cycle will be done. (Or at least on a science mission schedule.)

But you can use them for completely mundane things, too. A developer near my home is about to start 299 new townhouses. You could plot units remaining to get foundations, be framed, be sided, be outfitted and get occupancy permits. That's five burndown charts that count from 299 to zero, and you can mine those slopes for productivity information, cycle times, and probably (at least for the first two) weather data.

The plot is easy if you know how many things you'll be doing, because you just subtract what you've done, and plot the number of things remaining. Fit a trend line, and you'll be done where it crosses zero. Watch how that prediction moves, and you can start looking for causes of delays, or ways to accelerate progress.

For this build, 24 of the 33 are new features. One is classed as a defect, though I would argue the user changed his mind about what the behavior should be, so it should also be a feature.

There were 30 change requests in the baseline when the build was defined, and three bugfixes were later added during testing. Progress was a bit overstated early in the build, because the lead developer committed about a third of the total changes on one day, but then took four weeks to do the next two. But by the 1st of October, you could fit a straight trendline and predict the build complete date within a couple of days.

Sometimes the Scrum people will put progress that was not in the baseline below the zero line (extra work is "negative productivity") so that you can also trend added work. (Example and discussion [url=http://www.mountaingoatsoftware.com/alt_releaseburndown]here[/url]) If you have a lot of volatility in the baseline, that's a good alternative.

When I get through my design review I'll have a good idea of the total number of classes we'll need to implement, and I'll do a burndown based on unit-tested classes. That won't have a "baseline" per se, since I'm not required to get anybody's approval to add or remove a class from the count. If I see a lot of volatility in the estimated total, I'll probably do something snarky like plot the first derivative of the estimate against completed classes, so I can track whether work is being created or destroyed.

tc>