Program Management

The Fourth “R” of Reporting – Reveal

by

I’ve been going through the seven R’s of Reporting for Project and Program Managers. So far we’ve had:

  • Report – always keep the reporting running.
  • Research – Figure out what’s actually going on.
  • Relate – find how the data ties together.

We’re on to stage four new – Reveal.

OK you’ve run the report. You figured out the parts. You determined how they connect together. You know, in short, how the whole reporting system runs. Or doesn’t run. Or runs incomprehensibly. Either way, you know how you get from point A to point B.

So now you reveal it. You figured it out, you documented it (you did, right?), now you show it to people.

First, you reveal it to yourself. You should look over this reporting system you were handed and look it over. Analyze it. Get to know it. Understand the repercussions of it (some of them can be pretty weird)

Now as you examine it you’ll quickly have ideas of what to do and what it means – write those down. Make records. Because as people find out what you know, you’re going to be asked how to fix things and so forth; have solutions before there are questions.

Next, after you reveal to yourself? Reveal to everyone possible.

I’m not saying tell everyone-everyone. THere may be issues of security, dignity, or avoiding causing a panic. But frankly, I believe in making a reporting system and the information about it as widely available as possible to all those who care.

You do this because you do want reactions, you do want feedback, and you do want people to know how it works. Wether it’s appreciating how great it is or freaking out over the potential issues, people should know.

Now this may not make everyone happy. It does require some thought. But you want it as public as possible.

I’ve found few downsides to a “revelation” and many upsides – those usually being good feedback. Besides, since you already thought over some solutions, you’re ready to jump in.

(And why wait this long to go to Reveal? Because you want to have your story right. Sure any major crises should be brought up, but I’ve found quite a few times that early panic isn’t helpful.)

But not everyone reacts well to these revelations. In fact you may not. This is a vital part of the reporting process, and we’ll get to the Fifth R next . . .

– Steven Savage

Steven Savage is a Geek 2.0 writer, speaker, blogger, and job coach.  He blogs on careers at http://www.musehack.com/, nerd and geek culture at http://www.nerdcaliber.com/, and does a site of creative tools at http://www.seventhsanctum.com/. He can be reached at https://www.stevensavage.com/.

The Third “R” Of Reporting – Relate

by

So you’re a Project or Program Manager confronting the reality of reporting – you got a new project, a new job, and of course you have to get the information flowing. Or make sure it’s flowing. Or make sure it’s right . . .

You’ve been there. I have. You just need to make sure it’s working. Or fix it.

Now I’ve covered how the first thing to do in Reporting is, well Reporting; keep the reports going so you can figure them out. Secondly, you want to Research and figure all the parts of how things are and how they work. Of course that’s a lot of parts . . .

That’s where we get to tying them together – what I call the third R. Relate.

In a report data is transformed, condensed, discarded, stored, and disseminated. A JIRA entry becomes an excel cell. Vast data becomes a single number. Technical stats become business meaning.

A report is a giant structure of transformation – and you need to figure out how it works, how all those parts come together.

So thus, the “Relate” stage is building a map of your reports to understand how it works. Maybe you write it down, or draw a diagram or whatever. But either way your goal is to understand not just the parts, but the structure itself.

This lets you understand:
* Where data and information come from.
* How data is transformed and why.
* How it is stored.
* How it is presented and why.
* The technologies involved.

And most importantly

* anything missing, flawed, or broken along the way. Which can get to be a pretty impressive list, especially adding onto what you found in the last stage, Research. Sometimes you don’t see the flaws until you see the system in motion.

Ultimately, the goal of the 3rd R, Relate, is to understand data flow and expectations from point A to point B.  And yes, you’ll probably do this at the same time as the Research stage, or close to it, but I want to call it out because it is very much it’s own thing.

This leads to our next R . . . which I’ll cover, of course, next column. Because it’s a doozy.

– Steven Savage

Steven Savage is a Geek 2.0 writer, speaker, blogger, and job coach.  He blogs on careers at http://www.musehack.com/, nerd and geek culture at http://www.nerdcaliber.com/, and does a site of creative tools at http://www.seventhsanctum.com/. He can be reached at https://www.stevensavage.com/.

The Second “R” of Reporting – Research

by

OK last week I gave you the first “R” of my Seven “R”‘s of reporting – Report. In short, your first step when you take over a project is to just keep the reporting running no matter how backward, confusing, inaccurate, or bizarre it is. Doing that is important for many reasons, not the least of which is you may be terribly wrong that it’s got problems – that crappy, terrible report may actually work.

Face it, as smart as you are (and you do read my writings so I assume you’re smart) you may just be wrong.

But anyway, with the reporting running, we get to the next “R” – Research.

You need to start looking into how the reporting works. You do this of course so you, the Program or Project Manager, really know what’s going on, what’s being done, and what you have to douse that’s on fire. Hopefully it reveals, as previously, that all is marvelous but I’m not going to count on it.

So you need to do your second R, “Research.” Here’s the basics you need to look into:

  • What is the report supposed to do anyway?
  • Where does the data come from and what does it mean?
  • How is it transformed, analyzed, and understood?
  • Who does it go through and to?
  • Why was it included anyway?

If you can name all these things, even abstractly, about your current reporting structure, kudos. You are lucky, talented, or a complete liar. OK, no kudos for the last one.

The reason you do this research is simple, you want to know what all of this actually means. Not what people say it means, what it actually means. If some form is not filled out by calculations but by hand, you know there’s human meaning. If some date is reported but it’s not really what it means (“well it’s live but not tested” is one of my favorites) then you know.

You want to know what all of this information is supposed to tell you and really tells you.

Of course your urge may be “wait now I understand the data and it’s wrong” and go fix it. Nope, not ready yet.

Or it could seem the data is fine. Awesome. But it may still not be right.

See once you have done research and know what it’s all supposed to mean, you have to figure out how it hooks together, and that’s the next R . . .

– Steven Savage

Steven Savage is a Geek 2.0 writer, speaker, blogger, and job coach.  He blogs on careers at http://www.musehack.com/, nerd and geek culture at http://www.nerdcaliber.com/, and does a site of creative tools at http://www.seventhsanctum.com/. He can be reached at https://www.stevensavage.com/.