Better Software - November 2008 - (Page 40)

What might a real-world status report look like? While the content and format will vary by project and organization, a sample status report can be found in the StickyNotes. Parting Thoughts Effective status reporting is about efficient information transfer from the project manager to the project’s sponsoring executives. When asked whether the project manager should try to show bad news to executives in the best possible light, a friend once answered, “I didn’t invent reality; they pay me to explain it to them.” Wise words. Monitoring complex aspects of project performance and then succinctly and effectively communicating project status to executives can be challenging. The goal is not the ritual sacrifice of trees or painting a rosy picture to assure that your project continues to receive management support. The intent of effective status reporting is to provide executives with the timely information they need to do their job of steering the organization, establishing and supporting priorities, and allocating resources. To learn more, show a sample status report to your executives and ask them what information they wouldn’t care to know about; their answers should be instructive. Create the status reports that you would want to receive if you were an executive responsible for multiple large organizational investments and had only a few hours per month to stay on top of progress. Keep a record of your status reports, and you will find that they provide an excellent audit trail and raw material for retrospectives that can lead to process improvement of your project-reporting skills and your executive’s sponsorship skills. {end} Figure 7 toward the baseline over time. If more than fifty stories are required to implement essential functionality, this chart graphically shows that the original assumptions about scope were incorrect. Identified and unresolved faults in the product also can be a useful way for executives to see progress toward the goal and get a sense of product quality. Assume we have an agreed-upon method for sorting faults into severity 1 (fatal), severity 2 (functional), and severity 3 (cosmetic) errors. Displaying error counts alone may not be helpful. If we track the number of open errors by severity over time, as shown in figure 7, it may be easier to explain product status. We would hope that the unresolved error count would peak and then decline as we near the end of the project. We also might expect that severity 1 and 2 errors would be a priority and that this would be reflected in trend data. Where either of these expectations is not the case, this should be brought to the attention of the sponsoring executives and discussed as part of status. change and work proceeds according to plan without significant issues or risks, then simply describing scope, schedule, and resource performance against initial baselines will be sufficient status. Unfortunately, this is never the case. Describing progress against baseline expectations in the three dimensions described previously is necessary but not sufficient. Executives need to know not only what has happened but also what is happening and why. Performance against baseline expectations sets a context for the discussion. Other essential parts of project status include: • Significant project issues (surprises, incorrect assumptions, challenges, and any points of dispute or disagreement to be elevated to the executive level) • Any decisions that must be made or supported at an executive level • Significant changes to the project approach or definition • New, changed, and significant risks to project success All of this information must be monitored, assessed, packaged, and presented on a regular basis to allow informed, executive decision making. If this sounds like work, you are correct. Establishing and maintaining the systems and processes to do this are the responsibility of the project manager. www.StickyMinds.com Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. n The Rest of the Story: Issues, Decisions, Changes, and Risks Establishing baseline expectations for scope, schedule, and resource performance occurs initially as part of definition and planning. If project goals don’t 40 Sample status report BETTER SOFTWARE NOVEMBER 2008 http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.