Program Management

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/.

Reporting – The First R is . . . Reporting

by

Last week I mentioned why Reporting, in a way is a core part of the P(x)M jobs – Program, Project, and even Product Managers. Basically knowing is core to what we do, reporting is key to knowing, so like it or not it’s a part of your job. Fortunately I like reporting, which is both an advantage an possibly a cry for help.

So what happens when you come onto a new project and need reporting to run? Well that’s my next focus here, and I’m going to explain my seven stages of reporting, each of which conveniently begins with “R”. It’s like the five stages of grief with spreadsheets and my usual display of anal-retentiveness.

When you come onto a project, one of the first things you need to do is get reporting running so you and everyone else are informed about what’s going on. Admittedly when you know what’s going on it could result in panic, but we’ll actually cover that in stage five.

So what’s your first step in getting reporting running.

Step One is . . . Reporting.

Read more