The successful companies of the future will move to better integrate their business and project decision making, thus creating realtime and two-way feedback between the project and the business. To this end, they will have to redefine traditional roles, organize around projects differently, and develop a new infrastructure that rethinks project definition and planning efforts in such a way as to support the execution efforts.
Taking the first step on the way to agility will be easy. Most likely, it will be energizing. Innovative organizations always appreciate new ideas, including ways to reap greater rewards from their investments in project management. They are also looking for the leaders who will champion these new ideas for the business. Agile project management is an evolution that is already under way in the subconscious of many project managers and organizations. This book documents some of the practices, tools, and attitudes that I’ve seen used successfully in agile environments. It is my hope that you will take some of these ideas, customize them to your unique business, and improve your overall project management effectiveness.
Appendix A: Project Status Reporting Process
Status reporting is a key project management element during the execution phase of a project. The primary intent of a status reporting process is to have a consistent mechanism for project managers to report the project’s progress to plan. Using a consistent process enables status to be easily rolled up to the program and business levels.
This process is used in conjunction with the included status report template. An electronic copy of this process and template can be downloaded from http://www.xocp.com.
Status Reporting Overview
Objectives
To communicate to the team and management:
How the project is doing against plan
What issues are currently being dealt with
What risks have been identified and what is being done about them
What changes have made to the plan since the last status report
What impact recent events related to this project may have on other projects in the portfolio
* * *
Prerequisites
Before initiating this process, ensure that you have a plan. This means, at a minimum, that you have a Project Data Sheet (PDS) completed for your project and a detailed Gantt chart, if necessary.
* * *
Resolution of common confusion
This process is sometimes referred to as a progress reporting process and sometimes as a status reporting process. For our purposes, these terms are synonymous and refer to your progress (or status) against your predetermined plan. Are you on track to meet your next milestone date? Are you ahead of schedule? Are you behind schedule? And why?
The term status is often confused with accomplishments. Accomplishments are commonly reported to management, and they usually consist of a list of items that you have accomplished or finished since your last report. This list of accomplishments may or may not be relevant to your project status. This report should not discuss accomplishments that are not part of the project plan or that are not related to a project action item, issue, or risk.
* * *
Why accomplishment reporting is still needed
Now that we have emphasized that the intent of status reporting is to communicate status to plan and not accomplishments, it is important to note that acknowledgment of accomplishments is still necessary and even desired.
Here are a few reasons why reporting on accomplishments is needed:
Functional managers usually want to know what their people have been doing and what they have accomplished.
People feel good when they have accomplished something, and being able to communicate that to a forum of their peers is a form of recognition.
To be able to fully evaluate a team member’s performance and contribution, you must know what they have accomplished, as well as how well they have delivered to plan.
Non-project related accomplishments should be reported to functional management rather than project management, which is why you should use a different mechanism. While there may be some overlap, separating general accomplishments from project status reporting will help clarify and focus both reports, thus facilitating better team/management discussions.
* * *
Completing the Status Reporting Template
Project name
Enter the project name as it appears on the Project Data Sheet (PDS).
* * *
Date
Enter the date the progress report was completed.
* * *
Status summary
Assign a general status to the project for the current date.
For example:
Green: The project is on schedule (with all milestones-to-date) and is on track to meet the next milestone date.
Yellow: The project is behind schedule, but the team feels that it’s possible to get back on schedule in the near future.
Red: The project is behind schedule and the team does not think it will be able to get back on schedule without some major help or an extension of the timeline.
* * *
Status comments
Describe your progress against your plan. Are you on schedule, ahead of schedule, or behind schedule? If you are behind schedule, why? And what are you doing about it? If your intention is to revise your plan, then that should also be discussed here.
* * *
Priority
This is the status assigned to your project during the Portfolio Prioritization Process in Appendix D. Although that process uses a numerical scoring method, the project management team should translate that data into a High-Medium-Low rating for the status report so that the priority is easily grasped by a reader not familiar with the details of the prioritization process.
If you are not using the portfolio prioritization process, you should still assign a priority based on the project’s value to the organization, as compared to other projects.
* * *
Projected completion date
Enter the date that your current timeline shows you completing your project.
* * *
Original estimated completion date
Enter the date that you originally planned on completing your project.
* * *
Milestones
The milestones can be pulled directly from the Project Data Sheet. They can be represented graphically or in bullet-list fashion. Include target completion dates for each milestone and whether they have been completed. The goal here is an easily readable (i.e., graphical) snapshot of the project’s progress against plan at the milestone level.
* * *
Issues
Describe the current issues you are encountering and how you are addressing them. If you need help or need the issue escalated, then that should also be mentioned here. Issues can be pulled directly from the issues matrix. See the Issue Tracking Process in Appendix B for details.
* * *
Risks
Describe potential future events that could have a negative (or positive) affect on your project. Also describe the impact to the project if the event were to occur and the probability that the event will occur.
Describe any mitigation efforts that you are taking to minimize the chance of the risk event occurring.
Describe your contingency plan should the risk event occur.
Risks, mitigations, and contingencies can be pulled directly from the risk matrix. See the Risk Management Workflow (Chapter 8) for details.
* * *
External impact
Describe any potential impact that this project may have on other projects in the portfolio, or on the business in general, due to recent developments described previously. As much as possible, try to identify the specific projects, project managers, technical leaders, or functional managers affected so that appropriate notification can take place.
* * *
(Project Name) Status Report (date)
Status comments: Describe progress against the plan (i.e., on track, ahead of schedule, or behind schedule). Any variance to the plan should be explained briefly here.
Milestones: Insert milestones graphs.
Issues: List open issues here. Pull this information from the Issues Tracking report (fields: Issue, Owner, and Notes).
Risks: List risks here. Pull this information from the Risks Management report.
External impact: Describe any potential impact that this project may have on other projects in the portfolio, or on the business in general, due to recent developments.
Appendix B: Issue Tracking Process
Systematically identifying and tracking project issues facilitates the efficient resolution of critical problems and is therefore necessary for good project management. In fact, many people say that driving issue resolution is one of the most important responsibilities of the project manager. This process discusses a basic method for efficiently tracking issues, as well as clarifying the confusion that often exists in distinguishing an issue, task, or risk. An electronic copy of this process and template can be downloaded from http://www.xocp.com.
Definitions
Overview
When you mention the term issue to a group of people, each person may be imagining something different, and in a certain context, each of them is probably correct. Therefore, it is critical to proper communication that everyone uses the same definition. This process uses the following definitions.
* * *
Issue:
Category 1
A technical or business situation with no known solution that is negatively affecting a project.
* * *
Issue:
Category 2
A technical or business situation that is negatively affecting a project for which there is a proposed solution that hasn’t been fully implemented yet.