views:

1754

answers:

5

I work with a lot of offsite developers and contractors. I ask them daily to send me a quick 5 minute status of their work for the day. I have to sometimes consolidate the status of individuals into teams and sometimes consolidate the status of a week, for end-of-period reporting to my clients.

I want to learn:
  • Items accomplished and how much time was spent on each
  • Problems encountered and how much time was spent on each
  • Items that will be worked on next, their estimates (in man hours) and their target dates
  • Questions they have on the work
I'm looking for a format that will provide this information while:
  • Being quick for the developers to complete (5-10 minutes, without thinking too much)
  • Easy for me to read and browse quickly
  • Is uniform for each developer

What would you suggest?

A: 

Just give them a template laid out in a format that you expect to see the data returned in. You may also consider increasing the time they are going to devote to this and removing the "not thinking too much" clause if you are requiring estimates for future work. I wouldn't trust an estimate that someone came up with in 5 mins. without thinking.

If you are currently using any project management software, it should be trivial for the developers to record and review (or even just remember) what they have done compile it for you. Ideally they would be recording issues or questions throughout the day and not trying to come up with them just to fill in the report.

It seems like your "I want to learn" list is an excellent starting point to generate a template from. Only you will know what the perfect format for you is.

jasonbar
+2  A: 

Use Scrum. Create the sprint backlog, have a spreadsheet with the tasks and a column for each day of the sprint. Ask people to fill out the hours worked on each task every day. Send daily report starting with the burndown chart for the sprint and then short two one liners for each member - last worked on and next working on. Send weekly report with the burndown chart, red/yellow/green status for each major feature (and blocking issues and notes if it's not green) and the remaining items on the sprint backlog.

I don't have a link to samples, but here are some drafts:

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D
10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)
Franci Penov
Could you post a link to a sample?
David Segonds
A: 

Looks like you want to do Extreme Programming stand up meetings.

http://www.extremeprogramming.org/rules/standupmeeting.html

You can talk to off site team members using the phone with laudspeaker, or some VOIP.

Bartosz Blimke
i dont think that would work for off site contractors.
thesmallprint
Hmm. I think it could, but it's clearly *not* what the OP was after.
cori
A: 

Generally I have just relied on e-mail as a means of providing status reports, it provides the simplicity and speed of completion but does not enforce any sort of uniformity.

There are a number of options to achieve this but they all risk making the process more complex and time consuming. Some of these could be:

An online form with sections for each or a multi sheet spreadsheet, with each sheet being a section.

All of these require some effort by yourself to create them, do you need the uniformity for some purpose? e.g. to automate the summary reports.

An alternative to this would be to use some project management tool which the contractors filled in whilst they were working and that you could report on at any time. I would recommend Thoughtworks Studio Mingle, but it does rely on an agile-like process.

marcj
+2  A: 

you probably do not want to hear this, but here is it anyway -

i have been in this situation on both sides of the desk, and come to the conclusion that these kinds of rolled-up status reports are a complete waste of time for you and the developers. Here's why:

  • the developers should be working on features/deliverables with specified deadlines
  • the developers should be asking questions when they occur
  • communication should flow in both directions as needed

if these things are not happening, no amount of passive status reporting is going to fix the problems that will inevitably arise

on the developer side of the fence - a "quick five minute status" [i hate that phrase, five minutes is not quick!] interrupts the developer's flow, causing a loss of fifteen minutes (or more) of productivity (joel even blogged about this i think). But even if it really is only five minutes, if you have a dozen developers then you're wasting five man-hours per week on administrivia (and it's probably more like 20)

on the manager side of the fence - rolling up the status reports of individuals into teams by project etc. is non-productive busywork that wastes your time also. Chances are that no one even reads the reports.

but here's the real problem: this kind of reporting and roll-up may indicate reactive management instead of pro-active management. In other words, it doesn't matter what methodology is being used - scrum, xp, agile, rational, waterfall, home-grown, or whatever - if the project is properly planned and executed then you should already know what everyone is doing because it was planned in advance. And it doesn't matter if it was planned that morning or six months ago.

ignoring client requirements for a moment, if you really need this information on a daily basis to manage the projects then there are probably some serious problems with the projects - asking the developer every day what they're going to work on next and how long it will take, for example, hints that no real planning was done in advance...

as for the client requirements, if they absolutely insist on this kind of minutia [and i know that, for example, some government agencies do] then the best option is to provide a web interface or other application to automate the tedium that will do the roll-up for you. You'll still be wasting the developers' time, but at least you won't be wasting your time ;-)

oh, and to answer your question literally: the perfect status report says "on target with the project plan", and nothing more ;-)

Steven A. Lowe
Nothing happens exactly as planned. You need to know how the execution of the plans is going in order to be able to change them as needed. Tracking progress daily gives you the chance to load-balance, reprioritize or cut as you go.
Franci Penov
@[Franci Penov]: Tracking progress daily in the format listed above wastes man-weeks of effort and annoys good developers. Been there, done that, won't do it again. Instead, spend that time training the developers to time-box tasks, spike prototypes, ask questions, and report pro-actively.
Steven A. Lowe