The Second “R” of Reporting – Research

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

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

Reporting And Project/Program Management

One of the most important tasks of a Project/Program Manager (even if they don’t call you that) is reporting.

That may sound odd. It’s supposed to be management, or projects, to tracking things. Which is of course core to what you do, but just because people are managers doesn’t mean management is the most important task. Management can only happen in the right environment and place.

An environment and place where you, the manager, are properly informed and aware.

It doesn’t matter how organized you are, how well you plan, how well you update your gantt charts, or if you’re SCRUM certified if you lack information and if you don’t know you have the right information. No matter your skills and abilities and inclinations, you have to know in order to manage, and if you don’t know you can’t do your job.

That comes back to what I said – reporting is one of the most important tasks of Project and Program Management.

Good reporting is all about making sure information flows to and from the right people, in the right format, and that includes yourself. Without that information flow you can’t do your job, people can’t know what their jobs are, no one knows what’s going on – and you’re probably going to get blamed for it. In fact things could be a complete mess reporting-wise and you may not even know it since . . . reporting is so bad.

Again, reporting is one of the most important tasks for people in the Project/Program Management profession.

In fact we have to work on it even if it’s not officially our job. Because we stand in the middle of everything and know how things work. Because information can flow to us and often does, even if it’s half-baked. In short, because we’re in the best position to make reporting work unless someone has specifically been given that job (whoever that poor sot is).

I’d like to see more of this covered in Project/Program and even Product Management training.

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