Have you ever noticed how much time your consultant invests in producing a status report for\u00a0your\u00a0program? Filled with the appropriate amount of industry buzzwords, these documents often are used by the consulting service providers to lay down the groundwork in support of future change orders. \u00a0The 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.\nStatus reports\u00a0can\u00a0serve 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 many program managers and project leaders lack.\nStatus reports must be valuable\nTo 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.\nAs 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),\u00a0the status report should always be authored by the client.\u00a0\nFrom the receiver\u2019s point of view, aside from the content of the report itself, the value of the status reports can be derived in two additional ways:\n\nFirst, 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\u2019s status by recognizing what is\u00a0not\u00a0included in the status report.\nSecond, 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 several status reports, then it is time to understand why inconsistencies exist.\n\nAs the program manager, I am typically looking for five independent\u00a0points of view:\n\nProgram teams\u00a0\u2013 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.\nUser teams\u00a0\u2013 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.\nProgram management office\u00a0\u2013 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\u2019s accounting, delivery progress, and issue resolution.\nSystem integrator report\u00a0\u2013 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.\nIndependent auditors\u00a0\u2013 These reports can be the most troublesome unless you\u00a0commit yourself to leveraging ERP Program Audits to your advantage.\n\nAs 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:\n1. Top risks & issues \u2013 program execution and business operation\nThis section should outline the\u00a0top risks for particular areas, what program deliverables are aligned with mitigating that risk and what contingencies are in place if the risk materializes. These risks should be formally recorded in the\u00a0program risk\/issue log\u00a0and not simply reported in the status report.\n2. Crucial decisions that need to be made and when\nOne 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.\n3. Potential scope changes on the horizon\nEvery 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\u00a0pending.\n4. Major assumptions that have been made\nTo 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.\n5. Talent\/inter-team dependencies\nThis 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.\n6. Critical path delivery items status\nCritical 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.\n7. Productivity and execution statistics\nEvery team should have a few 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.\nBegin with attention to your audience and your progress\nThese 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.\nAll 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.