Home | Login | Recent Changes | Search | All Pages | Help

InformationRadiator

A display of information posted on the wall where passersby can see it. Sometimes called a "Big Visible Chart".

Subspecies:

  • PPPP - Public Project Progress Poster, tasks and slippage, also sometimes called "slug charts." (JerryWeinberg)
  • BurnDownChart - Work remaining, from Scrum. (KeithRay)
  • Project State Indicators / War Room - Schedule, defect trends, test trends, and requirements trends. (JohannaRothman)
  • Architecture diagram with red / green / black / yellow / gray coding for element progress & design decisions. Used for integration projects (JimBullock.)
  • SPC Charts for process error rates & variations (TQM & related.)
  • Tinderbox build status pages. Tinderbox combines recent data from different project databaseas (defect tracking, version control, automated compilation results, automated test results) and allows you to see on one page the current state of the project. (Extended to an actual regulation sized traffic light, in the hall, by the UrbanSim project - DavidSocha)
  • Project Inventory - State in life-cycle, status vs. plan - for IT project inventory (JimBullock.)
  • Project Room - From DwaynePhillips' as yet unpublished book.
  • "Floor Planning" as described by DaveSmith below. Wall variation by JimBullock.
  • ?

A good InformationRadiator can do one or more of:

  • Surface information and state and make it visible to all
  • Keep the team focused on what is currently important
  • Remove a bottleneck by distributing the ability to update the radiator
  • Reduce the number of "what's your status" interruptions
  • Make it very visible when some parties are falling behind (or are obstacles)

Useful project radiators are: timely, complete, accurate, easy to interpret, visible, shared, and easy to manipulate at least. Project radiators also seem to:

  • Present primarialy state not process information - what, done, etc.
  • Focus on the project artifacts - defects, tasks, etc.
  • Focus on the artifacts - builds, systems components source files, iterations, defects.

To be useful, a project radiator must be used, which is often the hardest part.

Contrast with InformationMagnet - which requires people to seek it out.


A great deal of the tooling in development management & automation is about creating an InformationRadiator for some important collection of factoids. If you want to know where the problem is, look for the stuff they're not willing to put up on an InformationRadiator (and BTW, 9 of 10 times the problem with getting the information out there is organizational, and 9 of 10 times organizational problems mean people problems not resource assignment or skills.)

-- JimBullock, 2003.04.03


Oh, this is one of my favorite topics. I think the term "information radiator" came out of a book by Cockburn(?). Where I worked, we called this a management information center or a project room. A place where we post information about the project(s) in progress.

I have always been puzzled why people don't want to have these radiators. A competitor to them is the local area network. Many people have told me that we don't need to post information on the walls because it is on the LAN. I have not been able to convince them that information on the LAN requires a person to go hunting for it while information on the wall is "right there."

Has anyone out there had success in creating these radiators? I could use some tips on how to convince people that they are worth the effort.

DwaynePhillips 4 April 2003


I've created radiators, but I called them "Project State Indicators" and they only had measurements, mostly of the schedule, defect trends, test trends, and requirements trends. I also provided staffing trends to management. I wasn't working in open-book management, so I couldn't show the project how far behind we were in staffing.

I agree that a war-room, a physical place with this information is much better than an intranet. If not everyone is in one physical location, you still need the intranet, but I like being able to grab management and say, "Lookee here." JohannaRothman 2003.04.04


I have always been puzzled why people don't want to have these radiators.

Somebody is benefiting from the obscurity. Jerry's article in the most recent Crosstalk is about destroying good information about development projects. He doesn't digress into motives, but there's the universal one to start from: "If the behavior persists, somebody's getting a payoff from the behavior."

So to convince people that an InformationRadiator is worth the effort, the people you're trying to convince have to have interest in the data you want to put on your radiator - it's timeliness, completeness, accuracy, and ease of interpretation at least. Also interest in spreading this information around unambiguously. This last is probably the most common motivation against an InformationRadiator. Like the RavenousBugblatterBeastOfTrall, many people believe that if they can't see a problem, it can't see them, so hiding information is the same as making the information go away.

The reason LANs aren't the same as charts on the wall is that people interact differently with different media. "Big thing on the wall" is in the shared space we all live in. LAN information is in a mental analog to "shared space" that we hope is similar for everyone. It's processed differently, starting with it's more work to deal with the LAN information, both mechanically to call it up, and mentally to create an image of it to intepret. "Processed differently" doesn't get much traction as an argument with big-brained theoretical types (read "uber-geeks promoted into development management"). I am becoming convinced that many of those can't tell the difference between what's in the world and what's in their heads. -- JimBullock, 2003.04.04


Some of best information radiators are charts.... but I'm not big on drawing charts (by hand or by printing excel charts), and so I haven't done much that way. I did something like a Scrum BurnDownChart, and got requests for more of the same -- they'll email them around... it seems like no one walks around gathering information (rumors,gossip,dilbert cartoon) but me. I guess I'll start printing them out and posting them on walls as well.

I once tried to talk high level managers into having Information Radiators for each project, but...

  • they said they were working on a software solution (about a year ago now; if it was deployed, I don't know about it and certainly don't have access to it.)

  • they protested: "but we'll have to update these things all the time." (Daily or weekly.)

KeithRay 2003.04.04


ARGHHHHHH. Keith, I pulled my hair out. WHAT DO THEY THINK THEIR JOBS ARE?? to go to meetings? NONONONONONO. Their jobs are to assess the project state, compare the state to where they want to go, and PLAN a way to get there. Not to go to some )(*)(**&^%%$ meeting. What could possibly be more important?? And I wonder why I'm a consultant. So sorry. I'll go back to being calm later today. JohannaRothman 2003.04.05

All: I took the audacious step of doing a little c2 wiki flavor editing the the top of this entry. Any reactions to this, please tell me. (I also fixed up my own last ramble some . . . because I could.)

JR, re: NONONONONONO

Sigh. Too true. And kind of true.

I think the ones who don't like having an InformationRadiator know their job is to get stuff done, and know they're not doing it. They get to stay employed (and in the way, but that bothers us, not them) to the extent they prevent this from being realized. -- JimBullock, 2003.04.05


they protested: "but we'll have to update these things all the time." (Daily or weekly.)

Calm down Johanna. When I read the above protest I smiled. Imagine, updating the status of the project daily or weekly. Then everyone would know what was happening. Sigh.

Maybe visibility and the desire to have visibility are MBTI type-things. I've always wanted to see what was happening, but there are so many people who don't care to. I don't know.

DwaynePhillips 6 April 2003


Now that I'm calm, I have access to my brain again. I've worked with managers who didn't want to know what was going on, because they thought pleading ignorance was a way to escape the consequences of failure. I still want to know what's happening, because I want to work the project to prevent failure, or somehow turn the project closer to success. JohannaRothman 2004.04.06
The most meaningul, useful information radiator I've seen in action to correct for all these management shortcomings is the PPPP chart, as described in my QSM books (vol 2, I think). People see the Public Project Progress Poster and they take action. You can tell something's happening by the conversations they have in front of it and the way they walk away from it with a different stride than they approach it with.

As far as implementing PPPPs and other charts on computers, it's almost always a delaying tactic. PostIt notes and a wall, or cards and tape and a wall, are all you need. Use a digital camera to take pictures of it if you want an historical record on your computer (not a bad idea, but not worth waiting a year to implement). - JerryWeinberg 2003.04.06


Holy coincidence Batman! (imagine Jerry dressed as Batman)

Yesterday afternoon I was revising a chapter in a book I am writing. The subject of the chapter is the "Project Room" (a type of information radiator). One of the sections I was having trouble revising concerned how people often use a computer too much in their information radiator.

There are several faults with the computer.

  • The usual output is an 8 1/2 by 11 piece of paper in 12 point font. It is really hard for more than one person to read that piece of paper at a time.

  • The output looks neat. So neat that people are wary of writing on it. So, the information radiator becomes a read-only device.

Using PostIt, Cards, tape, markers, etc. seems to invite people to read and write on the wall. (By the way, I think PostIt is a registered trademark. The generic term is Sticky Notes.)

One problem with all this that I have encountered is that some people feel these things mess up the office. I like a nice neat clean office. I also like to know what is happening.

I would like to have two offices at work. One is beautiful and peaceful. I can read, write, and have pleasant conversations in it. The other has a table and four large blank walls so I can spread information everywhere and work.

I have never had the luxury of two such offices. As a result, my one office has information all over the walls.

DwaynePhillips 7 April 2003


Another round of summary up top. - JimBullock, 2003.04.07


I am the author of once of the Tinderbox programs. So I will put a plug in for this program. Tinderbox displays information about what has been going on with the project, in the past few hours. It allows you to see what parts of the code have been changed, who has changed the code, whether the code still compiles, whether the tests still work.

I was attacted to this project, in part, because it seemed as if no other tool was helping radiate information between milestones.

More detail about Tinderbox is available at the mozilla tinderbox project page and in my upcoming STQE article. - KenEstes -2003.04.07


Ken, it sounds like a worthwhile project - I say sounds advisedly. I went to the referenced page and there wasn't a single picture on it. I'd like to see what the information coming out of Tinderbox looks like - if not, why would I be interested in adopting it. IOW, the presentation is incongruent with what it's claiming to sell - display of readily comprehensible information. - JerryWeinberg 2003.04.07

Sorry forgot to point you at the Mozilla projects pages. This is the page for the main work on the next version on the netscape browser. They are running the original tinderbox code, not my work. This works best in a netscape browser, some popupwindows do not work in Internet Explorer. However even with IE you will see most of the features.

Tinderbox for the Netscape branch called SeaMonkey

Sample page from testing my tinderbox rewrite

I can explain a bit about how this is used at netscape, but since I only know their processes from 3 weeks of observation, I may missunderstand some of the details.

My experiance in trying to deploy this simple information radiator drove me to understand the saying "you can not solve interpersonal problems with technological means".

I should state that if people are interested, my code is really modular so I can adapt it to many different situations. Also, I am also currently a casualty of the tech bust, so if you want my help getting this to work for your project, I will be glad to help.

KenEstes - 2003.04.08



Ken, have you got 4 or 5 words that describe your Tinderbox variation - something to go with the line item up top in the list of InformationRadiator examples? -- JimBullock, 2003.04.08

Jim, My tinderbox has nearly the same user interface as the old tinderbox. The difference is all internal. I have documentation, and a modular architecture and test suites. The original code has all valules hard coded and is monothic. I doubt that anyone could install the original tinderbox code in any environment other then the corporate Netscape environment.

I have added some words about tinderbox and also about my RPM work. Though my dependency work with RPM was to prevent inconsistant releases from getting into production. I do not think this is an information radiator.

--KenEstes 2003.0408


One thing to watch for with an InformationRadiator is where it overlaps other communication/reporting/status systems your organization uses.

On ShapeForum a few months ago, I described how I had created a defect tracking poster in order to get a handle on the defects we were trying to address for an important customer release. Our online corporate defect tracking system was a bit klunky and somewhat unfamiliar, people were routing around it, and I could never get a clear picture of what we were up against.

Using flipchart paper, I drew a grid: columns across the page for the status of the defect, rows down the page for the priority and a small PostIt with the identifier for each defect. As the defect was fixed, tested, etc. we moved the PostIt across the page.

The system worked great: we had stand up meetings around it, we could see the progress we were making as the PostIt notes marched across the page, even the department manager would come over to it to get updates.

However, the poster worked so well, we ended up using it instead of the online defect tracking system. As we approached the release date, we had accumulated a backlog of defects to update in the online system, which put a damper on the momentum we had going.

I think radiators are great things to have, but you do have to look at how they fit into to everything else your organization does.

StephenNorrie 2003.04.08


I'm consulting with the QA portion of an XP team. One problem we have is that people have been writing automated acceptance tests, but there isn't an infrastructure in place to run all the tests, then report the results. I was brought in to assist with creating that infrastructure.

I've used an InformationRadiator as an interim step - I run the tests manually, and put up red/green for each in a tabular display on the whiteboard behind me.

LaurentBossavit 2003.04.10


Floors can also be information radiators. I was once lucky enough to have a large area that hadn't been built out with cubicles. We used masking tape to lay out a large grid on the floor, with columns for functional areas in the system, and rows for iterations. We filled the cells in with 4x6 cards of various colors. Some cards held task information, red cards held notes on risk or concerns, and yellow cards where placeholders for unknowns. Various subteams could then have their negotiations "on the floor", moving cards, adding new ones, ripping old ones up. We kept this up until the plan was stable enough to transition to Microsoft Project, a move which our customer required. In retrospect, we would have been much better off ignoring the formal plan and sticking with the floor plan. --DaveSmith 2003.04.10

I've used this combination of grid with color coded cards for tracking multiple candidate tool & infrastructure projects several times. Green / yellow / red for state / timing. But also white for stuff we could do, and pink for stuff another team had to do - that they hadn't agreed to yet. We used a cork board, with string for the grid, and push-pins to hold the cards. Planning was very high-level, so time axis was calendar quarters. -- JimBullock, 2003.04.10


What's the official XP name for "the planning game" with the cards on the wall? Somebody want to talk about that? -- JimBullock, 2003.04.10


Mods to the inventory of good ideas up top. Moved Ken's RPM extension info down here. Maybe I imagined a UI as Ken described it.

Extensions to Red Hat Package Manager (RPM), to track and monitor object code dependencies on production systems - Jim are you sure this on this page? My work on this problem was towards release and administration issues. While I believe that project architecture SHOULD be radiated this tool is called into play too late to help. It is helpful when doing code Archaeology on an existing production system though. - KenEstes

-- JimBullock, 2003.04.10


No discussion of InformationRadiator would be complete without some discussion of InformationBlackHole. These are the folks who hoard information and actually seek to destroy information radiators whenever they appear - often under feeble claims of "security" or "it's not good for morale if people know too much about what's going on." - JerryWeinberg 2003.04.10

Drat. I was sitting on that one. Now you've gone and destroyed my little pile of power by putting the info out there for everyone to see. Sounds like a strategy, doesn't it?

Of course sharing information is also a strategy, maybe called "Throwing some data on the playing field." That refers to: "Throwing some water on the playing field." You see, water on the field makes mud, slows things down, and makes everyone slip and slide. Data on the playing field also makes mud, slows things down . . . oh. Wait a minute. Data on the playing field does exactly the opposite. Folks who hide data because it'll muck things up are either confused, or have a different agenda. -- JimBullock, 2003.04.10


DaveSmith, I appreciate you for mentioning floors as places to organize information. Any large flat surface is a good place. Has anyone seen ceilings used to keep information? I have been in some dentist chairs where they put all sorts of reading material on the ceiling.

I still own a C language reference t-shirt. The entire language reference is printed on the shirt upside down. That makes it easy for me to read while wearing the shirt.

How about a chef's apron that has a transparent holder on the front of it. I could slip a recipe into the holder upside down so I could read it while cooking.

We could go even further. People giving speeches could wear a transparent holder on their shirt and put their speech upside down in it. Am I slipping away here?

DwaynePhillips 11 April 2003


I like the T-shirt idea. It would give me an excuse for a pot belly. "If I had washboard abs, I couldn't get my C right." - JerryWeinberg 2003.04.11
Recent science news: 40% of American men have a gene (called "dd") for having a pot belly.
Ron Jeffries describing a big visible chart... in the original XP project...

The customer wasn't providing enough acceptance tests, so that increasing numbers of features were not "proven" to be correct....

I've seen similar problems on a project of 14 programmers and hundreds of stories. Used a big visible chart. Big 3M graph-ruled flipchart paper. Showed a row for each story, column for each interesting date. Green if test ran correctly. Red if it didn't. Yellow if no test existed. Did it with marker pens. Solved the problem in less than a week. The fact that the chart was Big and On The Wall helped.

KeithRay 2003.04.14


A mid-discussion summary:

A good InformationRadiator can do one or more of:

  • Surface information and state and make it visible to all
  • Keep the team focused on what is currently important
  • Remove a bottleneck by distributing the ability to update the radiator
  • Reduce the number of "what's your status" interruptions
  • Make it very visible when some parties are falling behind (or are obstacles)

--DaveSmith 2003.04.14


IMHO, that bit from Dave deserves to be up top, so I put a copy there. -- JimBullock, 2003.04.16


What's the official XP name for "the planning game" with the cards on the wall? Somebody want to talk about that?

I just read the name "Project Wall" used in an XP+Scrum success story.

KeithRay 2003.05.03


Updated: Sunday, May 4, 2003