Monthly Status Report Object Oriented Project Management

Monthly Status Report

Thu, 03 Feb 2011 10:00:42 | Object Oriented Project

On a monthly basis, the development lead or project manager assembles and presents a status report at the monthly program review. In addition, the next level of management in your organization conducts a monthly review of all of the programs in his or her organization. The report is designed to assess the overall status, progress, and stability of the development. The report serves two functions:

• Early detection and assessment of program risks.

• An opportunity to communicate the risks early so that the customer and upper management has a chance to help and/or respond.

The format is designed to enable you to maintain control of your program. The format tracking includes mechanisms that give sufficient feedback to allow for timely adjustments to the teams' activities or to the plan. In addition, the format has a mechanism to communicate status and risk to other stakeholders: upper management, other teams, and the customer.

As you will see, the format communicates the project's progress, stability, and risk status. One of the strengths of object-oriented techniques is that they provide tangible, demonstrable items against which to track progress and stability. They are measured in terms of use cases accepted, detailed, and integrated.

The monthly status report format is a sequence of charts, designed to quickly convey the current risk status of your program from a variety of views. Cost, schedule, and customer satisfaction risks are addressed. The report is designed so that it can be presented in 15 minutes. Follow this outline when presenting the report:

1. Title Page

2. News

3. Risk Assessment

4. Earned Value Analysis

5. Schedule Tracking and Stability

6. Development Tracking and Stability

7. Other Metrics

8. Review of action items

Previous	Table of Contents	Next

HOME

LOON

® O Q Ö @

SEARCH MY ITKMOWLEDGE FAQ SITEMAP COMTACT LIS

^ SEARCH

ITKHOWLCDGE



Keyword

• Advanced Search

• Search Tips

• Advanced Search

• Search Tips

tU BROWSE

ÖY TOPIC

To access the contents, click the chapter and section titles. Object-Oriented Project Management with UML

(Publisher: John Wiley & Sons, Inc.) Author(s): Murray Cantor ISBN: 0471253030 Publication Date: 08/01/98

Search this book:

Previous	Table of Contents	Next

These reports can be generated in a presentation tool. In my organization, we maintain them in a set of spreadsheets linked as HTML pages so they can be easily maintained, viewed by anyone on our corporate network, and projected at review meetings. We do not pass out hard copies.

You as program manager own the responsibility of assembling the monthly status review. However, as a competent program manager, you should delegate the effort. Your administrative assistant should assemble the earned value analysis charts. The schedule development charts should be assembled by the development lead.

The following details the contents of each of the outlined sections:

Title Page. The title page identifies the project, the month, and the program manager. An example is given in Figure 9.5. You might want to use this chart to give your program some identity—perhaps add a logo or a slogan.

Figure 9.5 Monthly review title page.

News. This chart is a simple bullet list used to convey any information that may be of interest and is not covered elsewhere. Use it to convey information that you think should be brought forward. For example, major changes in personnel, changes in customer personnel, or competitive announcements might be reported on this chart. Figure 9.6 is an example.

Figure 9.6 Program news.

Risk Assessment and Status. This key chart, shown in Figure 9.7, summarizes the overall risk status of the program. This is your opportunity to assess the project's overall status in simple terms that even an executive can understand: red, yellow, and green. Add up or down arrows to report the trend—such as whether the risk items are getting worse or improving. More important, identify any causes for concern and report how these concerns are being handled. Use this chart to ask for help or to reset expectations. For example, if the cause of the slip is a missed dependency from another organization in your company, your manager can raise the issue with his or her peer. Using this chart efficiently can help you enlist your manager as partner in the effort.

Figure 9.7 Program risk summary chart.

Be candid and straightforward when presenting this chart—tell the whole truth. For example, if you decide to put off reporting the bad news by reporting green up to the month before delivery, and then in the last month move everything to red, your manager has every right to be annoyed, and you will have lost credibility.

Earned Value Analysis. This section consists of the tables shown in Figures 9.1 and 9.3 with the most recent data. I also suggest you include a current variance trend graph like that in Figure 9.2. The charts add detail to the risk assessment. In particular, the variances quantify the cost and schedule risk identified in the previous chart.

Schedule Tracking and Stability. The schedule tracking and stability section of the review consists of two charts. The first is a summary Gantt. The Gantt chart, as shown in Figure 9.8, shows the summary tasks and the program milestones. You can choose to show some detailed tasks if you want to discuss their progress during the review, but keep the detail to a minimum.

■ -—

-i.-.....■•■■■>

--------"........;

. Er

~ 7:

mi,:: ....

8 Review Gantt Chart

The second, the schedule delta chart (delta is tech-speak for "difference"), is a simple table explaining how the schedule has changed since the last review (see Figure 9.9). The first column is the WBS item or milestone, the second column is the schedule change, the third is the reason for the change, and the fourth is its impact.

Figure 9.9 Sample schedule delta chart.

Development Tracking and Stability. This portion of the report consists of a series of artifact status charts in the format of Figure 9.4. Include the following charts:

• Use cases detailed. Original and current number of planned use cases, along with the plan for and status of each step fully delineated. This chart measures progress during the inception phase, but may need to be updated during all of the phases if requirements change.

• Development-level use cases detailed. Original and current number of planned development use cases, along with the plan for and status of each step fully delineated. This chart measures progress during the elaboration phase, but may need to be updated during the construction and transition phases.

• Classes specified. Original and current number of planned object classes in the system design, along with the plan for and status of each of the classes' attributes and methods specified. This chart measures progress during the elaboration phase, but may need to be updated during all of the phases if requirements change. Track only the initial specification: do not be concerned with the inevitable changes.

• Use cases integrated. Original and current number of planned use cases, along with the plan for and status of their functionality as tested in system integration. This chart measures progress during the construction phase, but may need to be updated during the transition phase if requirements change.

• Methods integrated. Original and current number of planned class methods, along with the plan for and status of their implementation as tested in a system integration. This chart measures progress during the construction phase, but may need to be updated during the transition phase if requirements change.

• Lines of code integrated. Original and current number of lines of source code, along with the plan for and status of developing and testing in a system integration. This chart measures progress during the construction phase, but may need to be updated during the transition phase if requirements change.

Do not use all of the charts. Use only those that provide useful information for your particular project. I suggest Use Cases Detailed, Classes Specified, Use Cases Integrated, and Lines of Code Integrated as a minimal set of charts.

Other Metrics. This section includes any other charts that would give insight into your status. Some examples include:

• Staffing curves. Staff onboard versus staff planned

• Defect analysis. The charts from Chapter 8

• System and operational test status. Number of system tests written and number successfully executed

Review of Action Items. The final chart is a review of the status of the action items generated during previous reviews. It should include the action item, its date, its status (open or closed), and the outcome. It can be maintained as a table; Figure 9.10 is an example.

Figure 9.10 Action item review.

Previous	Table of Contents	Next

Valutor Project Management

» Object Oriented Project Management