|
Question:
Tanya Arthur
Does anyone have any advice that they could share regarding the level of
detail that should be provided in a "Project Status Report". I need to
report status to my manager as well as the Vice President of IS. It has
been brought to my attention that I provide too much detail for the VP
Level. How can I communicate status clearly without too much detail. If
anyone has examples it would be greatly appreciated.

Answer:
Zbigniew Sobkiewicz
There’s a very nice example of a project report you can find in "Goal
Directed Project Management" (I don't remember authors but it's easily
found on amazon.com).

Answer:
Karen Tate, PMP
Try to get the report on one page. Limit the report to the status of the
major areas of your project plan, (scope, schedule, cost, staff effort),
and
-
Include project
issues and changes which are of interest to the sponsor and the
customer, or require action on their part.
-
Focus on the
variances from the project plan (when approved, it described a way to
accomplish the project goals and objectives) so if it is different
now, explain why this is or is not a problem.
-
Focus on the
deliverables currently in progress and upcoming deadlines and
interim deliverables completion dates.
-
Explain the reasons
for all the variances and the plan of action, or if none is required,
why not?
-
Have each subproject
complete a status report with the same information and include the
most important items from the subprojects in the main project status
report.
Offering too much information requires the Sponsor or Customer or other
managers to analyze what is going on and to determine what the details
mean. As a result, you might find that they assume there is a problem
when there is not and then, you may get too much "help" that you didn't
want. This generally takes more of your time to explain why you don't
need it, so add an overall status (on track, ahead, in jeopardy, etc.)
If you report project status accurately and without surprises, this will
help you to gain credibility and trust.

Answer:
Diana Poirier
For a VP level status report I have used the following format:
-
Key accomplishments for the period (2-5 bullet points)
-
Plans for the upcoming period (2-5 bullet points)
-
Budget status (summary of days worked, estimate at completion, budget
variance, etc.)
-
Key issues (2-5 bullet points) & required resolution
Keep it simple, hitting the key points the VP needs to know as well as
the key points you want to highlight for the VP (both successes and
issues you need assistance with). Try also to keep it to one
page.

Answer:
Lee Peters
The executive should see hundreds of projects. Each project should have
milestones -- key deliverables, key decisions. The executive wants to
know are you on schedule and on budget for the next milestone. That is a
one line entry.
If the executive wants more detail but not all you have provided, then a
list of the five key actions (activities, operations, tasks, steps)
leading to that milestone are included. Simple color codes of red,
green, yellow can be used. Something that can tell the status in seven
seconds.
The executive needs to know issues you need help with beyond what your
manager can give.
Keep the status report and issues to less than half a page. If you are a
critical project, then one page. Keep the format the same. Keep it
simple, for the entire project.

Answer:
Jim McIntyre
Try just addressing schedule, cost, and scope (probably in that order).
What's your current status and forecast for the future (Estimate at
Complete) for the project as a whole? You don't want to include
detail like "Jim is 70% complete with coding of the reporting subsystem
but has encountered difficulty interfacing with the purchased print
library...". Some people use a green-yellow-red color scheme to provide
a quick status. If you do, make sure you provide a key that
clearly defines what each color means. I use a "Headline" that is
the first line of text in the body of the status report in which I try
to summarize, in one sentence, what has been accomplished in the
reporting period and where the project is headed., e.g. "Design phase is
complete and implementation of Build 1 is under way". I also have
a "Red Flags" section where I note critical items such as outstanding
requirements issues or late delivery of customer-furnished items.

Answer:
Jim Peters
The interest level of the management is critical to the success and
value of a status report. I would suggest proposing something like what
is described below. But allow the management to provide input. I always
include things like issues resolved and issues that could impact the
project (even if they do not want to see it). The issues may come to
nothing but if something becomes a major issue you do not want it to be
a surprise. You do not want reactions like, "You mean you knew 6 months
ago and did not tell me?". The following outline has worked well for me
in various forms since I started using it 1988. It fits into most IT
methods I have seen and it can be done very quickly (10-15 minutes) if
the project is progressing with a few interesting problems or issues. I
assume that you can quickly cut and paste information from the project
plan and resource effort/expenses from other sources.
On one page I like to have the following:
1. Project Description: Brief 1 to 3 sentence summary taken from the
project charter.
2. Resource effort (by name) this week/month and life to date:
Include human resource effort and other resource cost.
3. What was accomplished this week: This should be in terms of
the project plan. For the VP you may not list all tasks but just the
deliverables produced or milestones met.
4. What was planned but not completed - and why and the impact: Again
this is in terms of the project plan. The key is that your approach to
managing things that go wrong is clear to management. The impact of
delays on the project is critical.
5. What is planned for the next period: This is again in terms
of the project plan. If you have a good plan that includes a current
schedule then you can just take this directly from the schedule.
6. Issues that have impacted progress or may impact progress
Even if problems are resolved it is a good thing to identify that
they happened and how resolved. For example, "Required test region was
not available as planned during the week. Worked nights and weekends to
complete testing." Even though this issue is no longer a problem, it is
good to let people know that there were problems, and they have been
resolved. Most VPs would ask the right question, "Will this happen
again?" This is the result you desire since what you want is that your
project's priority is clarified without you having to start a political
battle with other managers.
You may have topics/graphics that you want to include such as risk, high
level Gantt chart (at phase level), or spending plan charts. This can
easily be fit into the appropriate section or new sections added.

Answer:
Bill Duncan
Short term, I think that you have two choices:
a. Create two reports that reflect the differing needs of these
two stakeholders.
b. Create a hierarchical report that presents an overview as the
"top" page of the report and that is supported by progressively more
detailed reports. For example, the summary might include a Gantt chart
and an Earned Value variance report for the first level of your WBS
while successive pages would provide the same 2 reports for the next
level of the WBS. You could continue this structure right on down to the
lowest level of the WBS. In this way, both individuals can review the
summary and then "drill down" into the detail only to the extent they
choose to.
Longer term (or at least on your next project), you might think about
developing a "Communications Management Plan" as described in section
10.1 of "A Guide to the Project Management Body of Knowledge." The CMP
doesn't have to be long or fancy -- it might be as simple as a matrix
showing who gets which reports when -- but it helps to identify these
kinds of issues earlier in the project so that you can plan for them.

Answer:
Rita G. Glickman
I
would recommend you consider your audience and develop two different
status reports. What's important here is what works for your
customer(s). Yes, it's more work, but you need to satisfy your Project
Sponsor's needs for a status that is different from your boss's needs
for a status. If that isn't feasible, at the very least I
recommend an Executive summary page on the status report that provides
info listed below.
The VP report should be no more than one page. If your VP is like
my VP s/he doesn't have a lot of time to absorb the details and really,
the details are what you get paid for. A suggested format is:
-
Most recent
accomplishments since last report: bullet form only and only the
significant achievements!
-
Issues discovered:
again bullet form and only those issues that your team you may need to
escalate to the VP if your team can't resolve them. If any
discussion is needed on issues, only provide brief insight into the
"definition" of the issue. If the VP considers your issue
significant, it prompts a question where you can provide further
clarification on the issue.
-
Upcoming Activities:
bullet form only, significant tasks you plan on accomplishing before
the next report.
You need to sort through the mound of details you are managing in your
project to find those key details you can provide to the VP to keep
him/her informed. You need to keep the VP informed at the level of
detail that s/he works at, so s/he can keep their bosses informed.

Back to the main FAQ Repository page
|