The level of detail of a Status Report should reflect the level of management for whom it is intended and the project's formal OBS (Organisation Breakdown Structure) should help in deciding it.
Tom Mochal says his status reports already have a common format - good. But content within that format can be guided by the project's formal WBS and CBS (Work and Cost Breakdown Structures).
If the project is of any size and doesn't have those formal codes then rectify it ASAP.
A status report, asits name implies should show the status, - good, bad or indifferent of WBS/CBS elements at an appropriate level. 1 to 5 assessment grades are often approprate with extra annotation for deviant scores.
If the project using any Dynamic/Feedback techniques then havng formal mechanisms for feedback in the status report is a good idea.
Discussion on:
View:
Show:
I need a high level weekly status update for multiple projects with multiple project originators. They need to see all projects but not detail. If someone wants detail I can give them the full Excel sheet for the specific project. Is there any existing Excel Macro that takes detailed information for each project and summarizes into one page?
I use Excel for status reports. I have migrated to the point where I feel the best high-level status report is one that uses the tried and tested metaphor of a stop light -- Green means all is well (or at least under control), Yellow means there is trouble (that is being worked on to salvage the date), Red means lots of trouble (the date is toast; damage control is underway). I do my coloring in a column called Status, which contains the word Green, Yellow or Red. I color the cell as follows: Green items are unshaded (for readability) with green text, Yellow items are shaded Yellow with bold white letters, and Red items are shaded Red with bold white letters. For online readers, the shading tells the story visually. For those who print, the red shading is dark and the yellow is medium dark. Again, it tells the story visually. The other columns I use are "Bottom Line" (where I include a VERY brief executive summary), and a column for each of our key milestones, example: Contract, Requirements, Development (which includes design), Testing, Client Acceptance. This serves me well. I never hear about the "Green" tasks. The key parties always know about the Yellow or Red tasks before they see it on my status. I like the individual columns as folks work hard to avoid Yellow & Green in their section. I usually use the same color coding in the milestone columns/cells. That way it is clear where the issues lie. I’ve used this concept to track multiple projects (like a implementation team) or for projects with multiple tasks (or sub projects). Works for me.
Mike,
Would you mind providing a copy of that spreadhsheet? You can email to mailto:tmurph01@mindspring.com
Thanks,
Tim Murphy
Would you mind providing a copy of that spreadhsheet? You can email to mailto:tmurph01@mindspring.com
Thanks,
Tim Murphy
I sure would appreciate, if u could send me deatils for the full Excel sheet for a specific Project. Thanks.
Eventually providing technical gobbly goo is ultimately where this is headed though with any reporting system based upon what is "sticking" the project at whatever point in it's completion. That is, if it's managements's goal to resolve the issue asopposed to downsize. Motivations must be discerned. Status for a large part on projects that are on schedule will be ignored. Management, armed w/ this new information of problems will stick their noses into those projects that are stalled. Rather instead of having a solution to the programming problem or whatever has stalled it will inevitably wind up being a brief session of uncomfortable questions of being asked/revisiting of the obvious by the non-technically knowledgable manager. Shortly after the manager will demand a time of completion, further adding to the stress of resolving it. Normally, whenever a project gets stuck, the brain trust of those who actually have the technical expertise to get the job done has been exhausted and utilized. So you can imagine, the politicians will then try to assign blame for the shortcoming of the project and who will get the black mark or layed off or fired or whatever the next level of management deems is punishment. Life is like baseball, just because someone throws you ball 4, doesn't mean you have to swing at it for strike 3.
If the purpose of project status is to help the readers, it is best to first ask and understand what the reader is interested in knowing, how the information will be used by him / her. 90% of the information is available in most reports, and simplereformatting, removing some details, or adding upfront synopsis could help. Sounds obvious, but very few do it.
Giving techie gooblygoo does not help.
This is from a Reader's Perspective.
Giving techie gooblygoo does not help.
This is from a Reader's Perspective.
I work for a software house where the CEO is not a technical person. All final project status reports have to be submitted to him.
I agree with previously posted comments that too much techno babble doesn't do much good. The higher up the management ladder you go, the more summarized the info should be.
A rating system (e.g. 1 to 5) or scale is a good tool to use. Check boxes, yes/no, or simple tables giving a "before" and "after" overview also work.
For those people who are involved in the day to day management of the project, detailed WBS and resource info is very important.
I agree with previously posted comments that too much techno babble doesn't do much good. The higher up the management ladder you go, the more summarized the info should be.
A rating system (e.g. 1 to 5) or scale is a good tool to use. Check boxes, yes/no, or simple tables giving a "before" and "after" overview also work.
For those people who are involved in the day to day management of the project, detailed WBS and resource info is very important.
Most of the managers and CEO's don't understand the technical aspects of the status of a project anyway. Oh they may be privy to the buzz words, but the last two managers I worked for had never fully proved their Excel and Access expertise during their stint at the technical/individual contributor level. This showed when they were lost in meetings on the techniques and methodology used to put the project(s) together. Why explain it to them, they want to know how to do it, they need to get off their delegating rearends and do the work. You know roll your sleeves up and stick your hands in the cr*p. And stop acting like that their 6 figure incomes are justified because they can take your processed info and make a bar graph in powerpoint.
The last status system a manager gave me was a pile of crap. It was so inadequate to track what had been assigned, in-process and accomplished, I had to add columns and worksheet tabs within 30 seconds of receiving it. The idiot asked me to explain why I left completed projects for the period statused on there. In the comments I had "completed" typed in. I told him you assigned it to me after the last status report, I thought maybe you'd like to know what we've been doing this past week and whatwe got done as well. This was an MBA ! It got to the point where I simplified everything (dummied it down), so that I could just slide it under his door instead of having to waste my time educating the moron and having to spend time talking to him. He really didn't understand most of the status comments anyway, which tells me he never did a project from womb to tomb.
The last status system a manager gave me was a pile of crap. It was so inadequate to track what had been assigned, in-process and accomplished, I had to add columns and worksheet tabs within 30 seconds of receiving it. The idiot asked me to explain why I left completed projects for the period statused on there. In the comments I had "completed" typed in. I told him you assigned it to me after the last status report, I thought maybe you'd like to know what we've been doing this past week and whatwe got done as well. This was an MBA ! It got to the point where I simplified everything (dummied it down), so that I could just slide it under his door instead of having to waste my time educating the moron and having to spend time talking to him. He really didn't understand most of the status comments anyway, which tells me he never did a project from womb to tomb.
Hi!
If you don?t report all details, you can get a crisis of trust. But when you do report all details then you can get a crisis of pressure of external solutions. Where is a gold middle?
The only must deal is - if you can?t meet deadline, you have to inform about it ASAP. But again, in fast growing project a new spec (or sketch) with 1-st priority may appear in any moment. So, when your status report explains reasons of following problems, you will get something like ?there is no another way?.
And what? - Only trusting and respectful relations between project controller and highest management can require a really useful status report.
If you don?t report all details, you can get a crisis of trust. But when you do report all details then you can get a crisis of pressure of external solutions. Where is a gold middle?
The only must deal is - if you can?t meet deadline, you have to inform about it ASAP. But again, in fast growing project a new spec (or sketch) with 1-st priority may appear in any moment. So, when your status report explains reasons of following problems, you will get something like ?there is no another way?.
And what? - Only trusting and respectful relations between project controller and highest management can require a really useful status report.
It will be appropriate to agree and determine the communications strategy and media before starting phase, i.e. in the discovery phase and into the SOW. I work as both program (with portfolio of capital projects for the organization) and project manager, and coach to senior management in PMO concept. I find it very useful to agree on the reporting format (it varies from organization to organization, and from industry to industry), frequency (ad hoc reporting required under certain circumstances), structures; then designate a common drive on intranet (if the corporation has or allows it) for the project team members to work on or assess. It allow the PM to have a hand of the project dynamics, a draft for formal reporting to senior management (up to board level), project sponsor(s), and stakeholders from various business and functional areas. Clarity is very important in all this and PM should avoid too much technical staffs so as not to confuse the readers. Whenever technical mentioning is done, a layman explaination should be in the footnote or bettter in parenthesis. A good status report incorporated in a good communications stratery will make everyone's life easier.
G.W.
G.W.
I am an IT management consultant and project manager and have done several reviews of IT projects as well as IT departments. From my experience, I believe that if status reports are not produced, then there is a strong likelihood that the project isout of control. When the project team stops communicating, this is because they have bad news or don't have a clear idea of what's going on in their project.
Every Project Manager has to provide bad news sometimes. If you are honest with your customers, they will appreciate it in the long term. At least this gives them the opportunity to fix the problem, even if they don't like what they hear.
I do weekly status reports. This ensures that my customers know what is going on and it ensures that I have a detailed record. This takes no more than 1 hour per week and it also ensures that I know exactly what is going on in my project.
It also protects me in the event of any disputes. My customers like the regular updates and "miss" them if I am late by more than 1 or 2 days.
Start producing reports weekly and you will be more in control.
Every Project Manager has to provide bad news sometimes. If you are honest with your customers, they will appreciate it in the long term. At least this gives them the opportunity to fix the problem, even if they don't like what they hear.
I do weekly status reports. This ensures that my customers know what is going on and it ensures that I have a detailed record. This takes no more than 1 hour per week and it also ensures that I know exactly what is going on in my project.
It also protects me in the event of any disputes. My customers like the regular updates and "miss" them if I am late by more than 1 or 2 days.
Start producing reports weekly and you will be more in control.
My experience based tips/hints on status reports;
1) Build it into your communication plan. Have a plan for each stakeholder in your project and be pro-active on what they expect the content to look like, how often and distribution method(more risks then more frequency and formality). RISK: If you don't take pro-active control, then THEY control you. You will be in a fighting fire, reactive status reporting mode which eats up more of your time then doing the status report as committed to.
2) Assume management does not know how to run a project or know about your technology. They know about managing people and the business. Either you must take the time to educate them or keep it simple. RISK: If you don't take the time to educate or simplify then they are in your FACE all the time trying to figure out what really is going on.
3) All status reports must address time, scope(quality) and cost in addition to all changes to pre-established baselines, highly ranked risks to those baselines and issues that management must immediately address. Usually managers care about what was accomplished, not how - unless quality is the critical component of the project. RISK: If you don't communicate the risks and immediately impacting issues - YOU OWN THEM.
1) Build it into your communication plan. Have a plan for each stakeholder in your project and be pro-active on what they expect the content to look like, how often and distribution method(more risks then more frequency and formality). RISK: If you don't take pro-active control, then THEY control you. You will be in a fighting fire, reactive status reporting mode which eats up more of your time then doing the status report as committed to.
2) Assume management does not know how to run a project or know about your technology. They know about managing people and the business. Either you must take the time to educate them or keep it simple. RISK: If you don't take the time to educate or simplify then they are in your FACE all the time trying to figure out what really is going on.
3) All status reports must address time, scope(quality) and cost in addition to all changes to pre-established baselines, highly ranked risks to those baselines and issues that management must immediately address. Usually managers care about what was accomplished, not how - unless quality is the critical component of the project. RISK: If you don't communicate the risks and immediately impacting issues - YOU OWN THEM.
All to often status reports just a jumble of words on a page that have exploded from a busy mind.
Some words of advice.
Keep it simple, try using a bullet pointed "cook book" approach.
Break the report up into completed, try using headings like, in progress, status pending (usually waiting on external service or hardware suppliers) and flag any potential issues that may impact on the completion date of the project.
Use plain language.
Too many times people get caught up in the use of acronyms and buzz words that mean alot to the people working on the project but mean nothing to those who are reading the reports.
Make yourself available for clarification of reports.
Quite often a report will go across somebody's desk and there will be a point or two that a client or boss may need clarification on, always, and I do mean always follow up the report submission with a phone call at the very least, try dropping in on them to see if all is ok, where possible.
Follow up in person or on the phone.
Too many project managers claim to be too busy to do this, due to looming deadlines.
It is this sort follow up that means you get to stay busy instead of wondering what happened to your workload. It is an important part of the report process.
Some words of advice.
Keep it simple, try using a bullet pointed "cook book" approach.
Break the report up into completed, try using headings like, in progress, status pending (usually waiting on external service or hardware suppliers) and flag any potential issues that may impact on the completion date of the project.
Use plain language.
Too many times people get caught up in the use of acronyms and buzz words that mean alot to the people working on the project but mean nothing to those who are reading the reports.
Make yourself available for clarification of reports.
Quite often a report will go across somebody's desk and there will be a point or two that a client or boss may need clarification on, always, and I do mean always follow up the report submission with a phone call at the very least, try dropping in on them to see if all is ok, where possible.
Follow up in person or on the phone.
Too many project managers claim to be too busy to do this, due to looming deadlines.
It is this sort follow up that means you get to stay busy instead of wondering what happened to your workload. It is an important part of the report process.
One rule that I always apply when writing a status report is to limit the report to a single page of 10 to 12 point text, well spaced out.
Make the report longer than that, or try to cram in a lot of densely packed text, and the chances are that a busy manager will not read it. Regardless of how accurate or complete a report may be, if people don't read it, it's a waste of time.
I normally bullet point the following items:
1. Major accomplishments since the last report
2. What the project team will do next
3. Any major issues or problems that have arisen since the last report (don't include minor items that are unlikely to impact project success)
When determining the content of a report, it's best to ask yourself the question"What would a manager really want to know about the project at this stage?"
Make the report longer than that, or try to cram in a lot of densely packed text, and the chances are that a busy manager will not read it. Regardless of how accurate or complete a report may be, if people don't read it, it's a waste of time.
I normally bullet point the following items:
1. Major accomplishments since the last report
2. What the project team will do next
3. Any major issues or problems that have arisen since the last report (don't include minor items that are unlikely to impact project success)
When determining the content of a report, it's best to ask yourself the question"What would a manager really want to know about the project at this stage?"
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
