Inscrivez-vous ou connectez-vous pour rejoindre votre communauté professionnelle.
The project baselines are the real key for determining & dimensions for all kind of projects
The project baselines (scope, schedule, cost baselines) are the keys measures for any project.
The Management Perspective
If your project is important, your boss will be pressed hard to keep his superiors informed of its progress. Smart managers consume status on important projects voraciously. Excellent status reporting means that managers are fully informed of your projects health and overall direction without having to get involved themselves. There is particular information your boss needs in order to show her boss that she is on top of things and able to run the show effectively. Provide this information in a way your boss can consume it on a regular basis, and you will fall upstairs so fast your head will spin.
Even on relatively less important projects, effective status reporting allows your boss to spend only a few seconds skimming your report to determine what sort of progress you have made.
Excellent status creates clarity from confusion. Your job as the manager of a project is to take a swirling, chaotic cloud of information and distil it down into its most basic elements and then present them so that hundreds and thousands of hours of work can be understood in30 seconds.
To write excellent status, you must understand:
The three components of status.
How to write brief details.
What key data is needed by management.
Three Components of Status
There are three major components to reporting project status:
Overall: We need to see the overall project health. As managers, we want to be able to detect a project in trouble. We also want to help make that determination sometimes. You might not know everything we know despite our best efforts to communicate. Your project might not be as healthy as you think it is.
Milestones: Your project has major accomplishments which must be completed by specific dates. We managers want to see which milestones are complete, which ones are in progress, and which ones are coming up next. This allows us to analyse the schedule and decide to either feel comfortable with it or challenge it.
Issues: Your project also probably has one or more obstacles to completion which have been discovered. We'd like to see brief details about each issue so that we can make a decision about whether or not to step in and help if necessary.
Organising Your Status
Just as you would clean a kitchen by starting up high and working your way down ultimately to the floor, project status is best when it starts off with the highest levels of detail and works it way down to lower and lower levels.
Thus:
Overall project health comes first. If I like what I see here, I can stop reading the rest. Major milestones follow overall project health. If I don't like the project health, or if I am in need of further details, I can read a little further and check out the scheduled dates we are driving toward and your progress on them. Issues may be holding up those dates, so when I see a problem in your project schedule, I can read further and see what it is. Really slick project managers report the issues in priority order showing the issue causing the most jeopardy to progress first.
Brief Details
Your job is to report on the details of your project in concise, crisp status that we can consume rapidly without having to spend much effort on it. It might take you thirty minutes to write your status, but always remember that your manager does not have thirty minutes to spend reading it. Your manager realistically only has about30 seconds to consume your status as they may have30,40,100, or even exponentially more projects for which they are responsible.
"Brief Details" may seem oxymoronic to a project manager, but to a supervisor with a team of project managers, it is not. There is enormous value in a project manager who can report status without narrative. My recommendation is that you write as though you were creating an old-fashioned telegram. More information about how to do that is coming.
Brief Details?
How can you provide details without being long-winded? It is a formidable task that most never master, but it is not impossible. Here are some suggestions:
Write in bullets, not in prose. There shall be no paragraph anywhere in your status.
Avoid unnecessary use of titles and colons. We can see that7/4/2008 is a date. Writing "date:7/4/2008" does not tell us anything that "7/4/2008" does not.
Reduce, reduce, and reduce some more. Do your best to shorten all expressions and sentences.
Avoid adverbs (really, very, much) and avoid adjectives (good, bad, ugly).
Key Data
Management will need certain data from you in order to see overall health, performance against milestones, and the threat that project issues present. For overall project health, these data points might include:
The project's name
The project identification number if your company uses a tool to store projects.
The overall project health (red yellow green - more on this in a future article).
The % complete you expected to be at today (planned completion).
The % complete you are actually at.
The number of days behind or ahead against the plan.
The number of blocking issues you face (more about this later in this article).
The number of "normal issues" you face.
These data elements should provide a sound overview of project health for the average executive who is not details minded and is not interested in getting more involved in your project.
If I am your supervisor, I need to see more than just the overall health of the project. I also want to see where we are against certain milestones so that I can make a decision about whether or not to get more involved. One of the hardest things a manager has to do all day is decide whether to give you more room or get into your work with you. We don't want to carry your work for you, but we also don't want you to fall flat on your face.
Providing project milestones is helpful in this regard. It lets us see your schedule at a high level, determine if the schedule is acceptable as it stands, and predict pitfalls you might face down the road.
Milestones have six components:
The milestone name.
The percent complete of the milestone.
The planned start.
The planned finish.
The actual start.
The actual finish.
Some people like to provide red, yellow, green (RYG) status for each milestone in their project. I don't believe that adds any value. Of course the completed tasks are green. They are complete! All following milestones have the same status as the current milestone, so there is no point in differentiating them. The RYG status of the whole project is all that is necessary.
It's best to start with the earlier tasks first and the final delivery date at the bottom. If you list them haphazardly, you will create more confusion than clarity.
Issue Management
The final portion of your status report is to list the major issues your project faces. Important data that we need on your issues:
Ticket number: if there is a ticketing system, give us a link to the ticket or the number of the ticket.
Issue name: this should be very descriptive and brief.
Date and time reported: we need this to see ageing. The older an issue is, the more likely someone is going to get in trouble for not solving it faster.
Priority or severity of the issue: your issue is mega-important if it is a "blocking issue." If the problem is stopping the project from moving forward and is single-handedly responsible for endangering the delivery date, it is a blocking issue and is very important. If the problem is just another bug in some software that will be resolved in short order, it is not as important.
Who has it: the name of the person who currently owns driving this issue forward.
ETA: Managers are like children and always want to know when they are going to get something. "Are we there yet? Are we there yet?" Provide a time and date for when the issue will be resolved. If you cannot, then provide a time and date for when you will get to the next step in the issue resolution process. If you cannot do that, then provide an ETA for your next updated status on the issue.
Current Activity: What is currently being done to resolve this issue? Are you firing up a conference call? Are you calling out for reinforcements from a particular group? What is being done to mitigate? Are there alternatives?
Expected Results
If you produce really great status on a project and provide it often enough and to the right people, which are great topics for future articles, you should expect one of two results. Either management will become very quiet and not engage with you very much, which usually means they feel you are on top of the project and are capable of operating without their intervention, or they will increase their communications with you in order to ferret out further details and determine if they need to intervene.
Either result is better than the alternative: Management asking you for status. Your job as a project manager is to create clarity from confusion for the project team and for management. Essentially, the job is one of analysis and communication. If management is asking you for the status, either you are not sending it to the right people, you are not sending it often enough, or you are not sending a good status report.
Management should be able to passively absorb your status without having to reach out to you to find out where things are at. The pace at which you send it, the audience you select, and the content of your communications should be available to them easily and quickly.
A project manager that can status a project skilfully and briefly is a rare find. It should not be necessary to create colourful slide shows or multi-page documents in order to provide really great status reports. Many go that route and drown management in errata. Narratives and prose are always unwelcome in status reports, and yet so many write as though they were authoring a novel and create a report that management must spend inordinate amounts of time with in order to get what they need. Others fail to provide enough information at all, or worse, they provide status irregularly or rarely.
In all of the project management training and certification systems available today, almost none teach how to report the current state and next steps of a project. Learn to status your projects effectively and you have a competitive edge that goes beyond the standard project management toolkit.
Project status should be based against project baseline , provided there is no change in the scope of project that is significant. Current targets can be measured outside but in my opinion shall not be mixed along with project status because the consistency of the measurement will be lost when deviated from the baseline.
it should be against the project baselines versus the current targets.
both
base line program for client and any EOT will be subject to BL
in dealing with subcontractors current targets is better to be easy to monitor specially subcontractors always don't feel same responsibility as main contractors
Once established and agreed, the project schedule becomes what is known as the baseline schedule. Progress will be measured against the baseline schedule throughout the life of the project.
Project status report should contain the progress of the project i.e. comparison of Planned Accomplishments VS Completed Accomplishments. It includes effort and schedule variances, reasons for variances, issues and options etc.
Agaist Base line
The project baseline is key because if you don't follow it, then other projects will not be done on time
Thank you for this question, the current status should be a against the baseline showing the actual targets (amended), to track changes against baseline plan to show if there is any delay or early finishes.
I think current targets if they documented,updated and approved should be read as updated baseline.
