I'm not sure whether you agree with me or not, but IMHO we (in general) get better & better in embracing increasingly complex tools & technologies, while in the same time we keep failing in the most fundamental activities that do not change so dynamically over the years - like basic interpersonal communication, especially if it spans between teams / locations / career ranks / specialties.

Where ... are we?

Many people do not know how to communicate effectively and / or (what's even worse) undervalue the importance of the efficient communication. Perfect example to illustrate this issue is so-called "status/progress reporting" or in other (more modern) words: sharing delivery status with important stakeholders who (due to whatever reason) can't stay in full sync / dive deep into what / how team is doing. Anti-patterns are so common here:

• some teams just keep verbally repeating "we're doing well, no problems" (without anything tangible to back this thesis up) & ... it seems sufficient for the other side (until the hell breaks loose ...)
• some teams substitute mantra mentioned above with set of manually generated RAG lights (red/amber/green) or any other kind of manually forged report -> takes a lot of time to create, prone to manual errors, already inaccurate in the moment of presenting, tends to drift away from presenting what's truly meaningful towards what's easy to get / forge :>

Needless to say, such information doesn't really reflect real status & is nothing more than simply confusing ...

While in fact, this problem is very easy to solve if you apply the idea of Information Radiator correctly. It's very simple - to properly expose information about the real state of work, one has to make this information a side effect of actual work (so no-one has to care about updating/creating it manually).

In other words - if you're using board / Trello / Kanbanery / JIRA / whatever to organize the task flow, automate transforming current state kept in this tool into condensed management information (in form of dashboard / report / view) needed by your stakeholders. All the data should be already there (plans, what's actually going on, dynamics of change, etc.) & usually it doesn't take much effort to get it out (OK, if you're using just a physical board it will not work, but these are discouraged in multi-team scenarios anyway).

Making a difference

So, are Information Radiators just about having some kind of dashboard in the tool you manage your task flow (or other important process)? Not precisely, devil is in the details - what really matters is:

• information is supposed to be real-time & accurate (reflect actual state of things, but modeled in a way that serves some particular purpose)
• using this information is completely asynchronous, access to it is open & sort of subscription-based (not obligatory), i.e. anyone who is interested can access it whenever (s)he wants - individuals can subscribe to only these pieces of information that are interested for them & update themselves as often as suits their needs
• information is presented in an extremely simple way, so extracting actual knowledge from it is immediate (cleat at a glance) & doesn't require additional post-processing

Information Radiators are awesome, because:

1. they don't require any effort to prepare the output information (once you have dashboards / reports configured, but it should be a one-time effort + adjustments), it's there automatically
2. information is up-to-date all the time, not once a week (after any sort of manual report update)
3. having a small data mart with all the information about how you guys work is very useful if you're looking for some insight for your team's Continuous Improvement considerations, e.g.: you've introduced a change & now you can measure the effects of change using whatever metrics you prefer - "did cycle time improve?", "are we getting less defects now?"
4. once you learn your first steps here, you can radiate (very cheaply) different perspectives on the same information fit for different interested parties - e.g. different for program management & different for peer team that has some dependencies on you & should have a constantly open peep hole into what's going on :)

Price to pay

Of course to have a properly working Information Radiator you need to introduce some regime (& some may hate it):

• build habit of updating the information in the tool when there's something going on with the task - it sounds unintuitive, but what has worked best for me before was tight weaving development process into task management tool, e.g. by requiring task ID in VCS'es commit message
• establish clear naming / classification / hierarchy conventions, so people know how to keep things tidy
• work closely with your stakeholders to understand what they really want to know & how does this map into how your tools & process are organized

Information Radiators may also have some drawbacks / carry additional risk:

1. it may be tempting to over-substitute regular person-to-person communication with checking the radiators - of course it's unhealthy as this communication channel is (by its definition) more limited (especially in terms of breadth & expressiveness)
2. "shit in, shit out" - if correct regime is not applied or people don't understand (it was not clarified to them and / or they didn't accepted it), radiated information will be useless (or even harmful, because of inaccuracy or incorrectness)
3. the most common error is to push out all the information present, without any structure, sanitization, verification against stakeholders' needs - in a result, they get overwhelmed by tons of illegible crap (sometimes even internally inconsistent and contradictory) - that tends to kill any will for cooperation they had

Some could argue that this is an overkill & good example of over-technicizing a simple problem. I find radiators an absolutely critical building block of work transparency & a great auxiliary communication tools that scales superbly even in the most complex work environments.

Pic: © bluedesign - Fotolia.com