Can a Program Status Report be Too Sexy?

Have you ever noticed how much time your consultant invests in producing a status report for your program? Filled with the appropriate amount of industry buzzwords, these documents often times are used by the consulting service providers to lay down the groundwork in support of future change orders.  The glitz and sizzle included in these documents can often be seducing to your executives, leading them to believe that the program is well managed, even though the program is crumbling.

Status reports can serve one of two purposes. They can either be the most valuable tool that a program manager has at their disposal, or they can simply be the paper weighing down the box you use as a doorstop. Constructing and evaluating status reports is a critical skill that a majority of program managers and project leaders lack.

Status Reports Must be Valuable

To understand the potential value of status reporting you need to examine the process from both the perspective of the creator and the receiver. In my experience, 80% of the value of the status report is derived directly from the creator of the report. If done properly, the project leader is taking a methodical survey of all aspects of his or her responsibilities and assessing the situation while writing the report.

As the receiver, whenever I start to see status reports with content that is repetitive or increasingly brief, I have a pretty good idea that a component of the program is in trouble. Given my assertion that 80% of the value is derived by the creator, whenever you have a program management structure that has two or three managers in a box (client, system integrator, software provider), the status report should always be authored by the client. 

From the receiver’s point of view, aside from the content of the report itself, the value of the status reports can be derived in two additional ways:

• First, the report provides insight into the overall quality of the management of the specific area. As a Program Manager, I often gain my deepest understanding of a program’s status by recognizing what is not included in the status report.
• Second, the status report can provide an indication of overall program alignment. This alignment view is achieved by having the status of a particular deliverable or risk reported from multiple points of view. When you see differing interpretations of risk and varying statuses of deliverables across a number of status reports, then it is time to understand why inconsistencies exist.

As the Program Manager, I am typically looking for five independent points of view:

• Program Teams – These are the teams that are usually responsible for the creation of deliverables. Typically, programs are comprised of functional teams, data teams, technical build teams and organizational change management.
• User Teams – Having the end users report on the status of the program allows you to understand if the program communications are working as planned and if each area or site is doing its part to contribute to a successful implementation.
• Program Management Office – This report should look a lot like an operations report or a financial report. What you are looking for is an unbiased review of the program’s accounting, delivery progress, and issue resolution.
• System Integrator Report – This should come from the senior member of the System Integrator that is involved with the program. You want to know exactly what their perspective of the program is.
• Independent Auditors – These reports can be the most troublesome unless you commit yourself to leveraging ERP Program Audits to your advantage.

As for the content, too many status reports tend to be a dump of what was accomplished in the last week. That is about 10th on the list of what a Program Manager should be interested in. In the world of ERP / business transformation, I recommend the following organization:

1. Top Risks & Issues – Program Execution and Business Operation – This section should outline the top risks for particular areas, what program deliverables are aligned with mitigating that risk and what contingencies are in place in the event that the risk materializes. These risks should be formally recorded in the program risk/issue log and not simply reported in the status report.
2. Crucial Decisions that Need to Be Made and When – One thing that consistently causes delays in program execution is the inability of organizations to align on a crucial decision. Check your agreement with your System Integrator. You will likely find an assumption that decisions will be made in a timely manner. You want as much runway as possible in making these decisions.
3. Potential Scope Changes on the Horizon –Every program will go through a serious of scope changes. This is a natural part of the process. These scope changes can be anticipated based upon an examination of risks, decisions, and assumptions. Scope changes should recognize both subtractions as well as additions. These potential requests should be formally identified in the scope change request log as pending.
4. Major Assumptions that Have Been Made – In order to move forward on some of the critical path items, it is often necessary to anticipate the outcome of some major decisions. In doing so, you want to be clear on what those assumptions are. These assumptions should continue to be listed on the report until they become facts.
5. Talent / Inter-Team Dependencies –This section should provide insights into capabilities of new talent that have been added or specific gaps that need to be filled. It should also outline any expectations that this team has on delivery from other program teams, user teams, or outside providers.
6. Critical Path Delivery Items Status – Critical path is not always defined as the elements that take the most time. From my perspective, the critical path should be defined as those deliverables that contribute to the most significant reduction in program or business execution risk.
7. Productivity and Execution Statistics – Every team should have a number of metrics by which they can measure progress including deliverable progress, testing progress, communication plan execution, etc. Each report should include statistics that outline progress against a defined plan and forecast.

Begin With Attention to Your Audience and Your Progress

These reports should be examined and renewed on a methodical basis from the bottom up. Assembling the status report should not be something that takes hours and hours to complete. Interpretation of the reports can be a bit time-consuming, but if done properly, the Program Manager should be looking for specific gaps in the reports and any misalignment on the various teams as it relates to status or risk.

All in all, one of the critical success factors in an ERP implementation and business transformation is the attention to rigor. The creation and interpretation of program status reports is an excellent way to enforce rigor and identify where lapses in rigor may contribute to program execution or business performance risk.