InformationPulsars

We've talked about InformationRadiator for the willing and InformationBlackHole for the unwilling. How often should the willing update their radiator? How should it be decided? How should the update frequency be adjusted given that someone thinks the wave length is too long? Is there such a thing as too often?

Radiators get updated when there's anything new worth radiating. Otherwise, if people come to believe that the "radiators" are stale, people will stop looking at them, and they'll lose their value as radiators.

If radiators are being updated promptly, and there's still too little timely information, that's a valuable clue about the state of the project. (Radiators that flood people with continuously changing information are also serving up valuable clues.) --DaveSmith 2003.04.13

I feel the need to be more concrete here (hehehehe :-) I tend to have these update frequencies for projects of 3 months or more:

Weekly: defect trends, Fault Feedback Ratio, size (LOC or fp or whatever you count), change in requirements
Bi-weekly (or monthly for longer projects): End-date estimation (EQF), staffing profile
by project: milestone estimates and actuals

I know I measure more than this, but since I can't remember and can't find it, I'm too fuzzy to continue. I'll continue later when my brain has caught up with my body. -- JohannaRothman 2003.04.15

How often should the willing update their radiator?

An effective InformationRadiator should be getting updated by the team directly, not bottlenecking upon "the owner" of the thing.

While the initiator may need to prime the pump, the team should step up to keeping the info current. --BobLee 2003.04.15

Updated: Tuesday, April 15, 2003