Given how project management software has taken advantage of today’s graphical age, there is a plethora of possible reports available for users of such systems. I’m always amused when we put such things as “200 reports included” or “thousands of reporting combinations available” in our marketing literature. Is this supposed to make people productive? As I work my way across the country and in different parts of th world meeting people who struggle with their own implementations of project control systems it’s easy to see why a system with hundreds of reports could be at once a great system to implement yet overwhelming for virtually all users.
When you start to distinguish the different kinds of audiences for these project management reports and the different kinds of reports available, the deployment of these systems makes a little more sense. Let’s start with the different types of audiences.
First of all, the users alone are an insufficient definition of the audience for the output of a project control system. These full-time or power users must be included, of course, but almost always, the users of a scheduling system are users at all because of the request or requirement of someone else. The users however will require detailed reports that allow them to identify work, debug input into the system, sequence and organize raw data into identifiable categories and orders and analyze the results of any analysis. In addition, this group will need to validate any other reporting into the system.
Another clearly distinct level of audience is the grass-roots input to the system. Some of these front-line personnel might use the system or use a “lite” level of access to the system but they will not typically be full users. The interest at this level for detailed analysis of the schedule will be low. Users at this level will be more interested in lists of tasks; in turn-around documents or forms to fill out while in the field and in simple schedules of what is expected of them next. How the system actually figured out what is expected next is of little use to them.
The ultimate ‘clients’ of many project control systems is another identifiable audience and that is the ‘Executive Suite’. Here the interest is not in the detailed analysis but in the synthesis or results of that analysis. Reports are expected in summary form with the all too elusive “One-Page Report” or an executive Dashboard being the ultimate goal for most executives. Trying to impress executives with a 20-foot flow chart of activities which stretches around 3 walls of the conference room will generally be unsuccessful.
There are likely several other potential audiences for project control reports. Project sponsors for example or the client themselves. Regulatory authorities often have specific requests and, if you’re in the defense business anywhere in the world, you’re likely to run afoul of Earned Value reporting standards. For each group of readers of the system’s reports you’ll need to look at their requirements separately.
Let’s turn our attention now to the kinds of reports which might be requested. Every project control system will have different types of standard reports but virtually every one of the systems on the market at virtually every skill level will include the following categories of views or reports: List reports sometimes referred to as spreadsheet reports, Barchart or Gantt views, Curves and Histograms, Activity Flowcharts, sometimes referred to as PERT, CPM or Network Logic diagrams, and Work Breakdown Structure (WBS) tree diagrams. There are a number of other more esoteric categories (scatter diagrams for risk data for example) and a variety of hybrids of different views but this is plenty for the moment. Let’s take these categories one at a time.
List or spreadsheet views are essentially text-oriented reports. These reports are organized in rows and columns just like a spreadsheet (hence the name) and these days are just as likely to look just like a spreadsheet when they’re output. Spreadsheet reports are useful for pretty much every audience depending on their content, their level of summary and the amount of data on them. A few products offer multiple lines of data per activity, most allow columns to be customized but only in one line per task. For executive reports, look for data to be summarized to a level of one line per project.
Barchart reports are sometimes referred to as Gantt reports. (After Henry Gantt who is credited with inventing them.) These reports are organized with tasks or summary tasks on the left with various columns of data and a bar or multiple bars against a date scale to the right. With abilities to modify what bars refer to what level of data, many different effects can be created here for different audiences. Typically, this is a good tool to use at the executive level if the system is capable of summarizing to one line per project and at the grass-roots level for individual schedules. Power users won’t often use a barchart except to validate that the schedule “looks” the way they’ve designed it.
Flow Charts are sometimes inaccurately referred to as Logic Diagrams or PERT charts after the charts designed for the PERT analysis method which is seldom used anymore. They show data at a detail level with one box per task and a line between tasks which are sequenced in order. In a good-sized project, this can add up to a lot of paper if you output the data. Still, this is the absolute best way to view the sequence of tasks. The flow chart is best targeted at serious users of project management software as the information contained in each box can be confusing for anyone not familiar with critical path methodology theory (that’s the name for the algorithm most often used to calculate schedule dates). In any serious project, there’s usually a “war room” allocated for the project team which should sport one of these diagrams as wall-paper. It’s a great tool to use while updating the project as you’ll immediately see the impact on other areas of the project when you change progress on a task. Also, having such a report ensures that proper project management techniques are being used and that the system is not simply a “barchart painter” regurgitating dates already specified by management.
Curves and Histograms show cost, resource and risk data. As summaries they are useful for management, in detail they’re of use only to experienced project managers. There’s likely no one at the grassroots level who wants to see the resource levelled histogram of data.
WBS diagrams are hierarchical tree diagrams just like an organigram. In a work breakdown structure however instead of an organization breakdown, you’re showing the breakdown of all work on the project. WBS diagrams are used to clarify other data and as such are best targeted at the power user.
In the end the system that you create should only have a dozen or so reports that are used with any frequency. These reports may be standard, out-of-the-box reports or may be customized using the many tools to be found in project control systems these days. Rather than looking for a system which has more reports than the next one, look for categories of reports. Does the system support the kind of WBS you’d like to see and are the customization tools there to alter it to exactly what you need. Finally, in this graphical age, see if the reporting view you like so much is also interactive. Can you display your data in this view then manipulate the data right on screen?
