Do Project Reports Really Give The Real Picture on Project Progress?
Big Picture - by aloshbennett via Flickr
Guest post by Susan de Sousa
A project manager often holds a position of great importance within an organisation. Often the projects and programs entrusted to them, together with the large project budget which can be ill afforded will determine the future of an organisation. In return, transparent project reporting through the weekly report is not unreasonably expected, to enable senior project management stakeholders to accurately track progress. But do Organisations always get the real picture?
Now there are correct and incorrect ways to fill in the project management report. Some project managers like to fill in the bare minimum of information, whilst others go for incessant detail and write reams. However it doesn’t matter how much is written, so much as what is written.
Where projects are concerned, Organisations need an update on the following:
• Summary of Progress
• Milestones
• Key Issues
• Risks
• Dependencies
• Budget
Now this might appear to be extremely straightforward, but being a project manager, is in my book at least, an art, not a science. Sometimes being economical with the truth can be an extremely good idea as it allows time for the issues to be resolved without unnecessarily raising the alarm bells with project sponsors.
The problem is that this often gets taken to extreme lengths by certain project manager’s who are simply after an easy life. With these individuals, being economical with the truth becomes a way of life and soon the problems mount up with the project becoming unachievable, but no-one understanding this until it is too late. After all it is far easier for everyone if project reports contain only good news to stop senior management asking awkward questions.
You might think that this is a far fetched scenario, but it occurs far more frequently than you may realise. Take the UK’s $468 million public sector C Norris IT System. A recent report by the National Audit Office reported that bad news about this project failed to go up the reporting ladder and that in the early stages, the project was consistently rated as green despite the lack of progress being made. By the time the project was finally reported as being in Red, three years had passed, an enormous amount of taxpayers money had been wasted and it was too late to rescue.
Of course it doesn’t have to be like this. Consistently hiding bad news from senior management is a sure fire way to bring a promising career in the profession to an ignominious end. Thankfully it doesn’t have to be that way as long as you maintain consistent project communications.
Nov 2nd, 2009 at 7:09 am
Hmmmmm…… I don’t know, Susan….. Is being “economical” with the truth a violation of any of the Coded of Ethics?
Not that I disagree with you at all, but until or unless project managers are either fired by their companies or drummed out of the professional organizations for lying, I just don’t see any changes on the horizon soon.
I am fond of using the medical profession as a baseline or standard against which I encourage project managers to consider.
You are going in for open heart surgery. Your cardiologist is going to be holding your heart in his/her hands. Just how “economical” with the truth would you (as the patient) be willing to tolerate from the cardiologist?
I suspect the answer would be ZERO.
Interesting that TED http://www.ted.com/ announced a program on “Compassion” which basically suggested that regardless of religion, values or beliefs, that if we just lived by the “Golden Rule” and showed just a bit of compassion towards one another, many of the worlds problems could be solved.
I subscribe to that philosophy fully……
BR,
Dr. PDG, Jakarta
http://www.getpmcertified.com
Reply
Josh Nankivel Reply:
November 2nd, 2009 at 9:58 am
Even better, the Platinum Rule. Treat others NOT as you would want to be treated; treat them how THEY want to be treated.
When preparing status reports, we as project managers must step outside our own perspective (what’s good for me and the team?) and see it from the viewpoint of the customer/sponsor (what delivers business value to them?)
Reply
Susan de Sousa Reply:
November 2nd, 2009 at 11:01 am
It’s a tricky one Paul. Being economical with the truth isn’t the same is actual lying. However it is certainly being unprofessional and is the sort of things that companies should sue over because the amounts of money lost as a result are huge.
I know of numerous incidents of this. In one case a project manager kept insisting that his project was green and ready to launch. The Programme Director articulated this to the main board. However when the time to launch came it appeared the project was far from in green and it took JFDI, heroics and an enormous burn rate to get the project launched 6 weeks late.
But the question I always ask myself is, was the project manager themselves so deluded that they genuinely thought the project was ready to launch, or did he simply want an easy life by pretending it was fine? And this project manager was hugely experienced as well, so I can’t work it out. I guess the pressure of delivering just got to him.
PS I’m sure you’re right on the compassion idea but I’m more into Darwin’s theory of survival of the fittest. ie either you learn the rules of project management quickly or you move aside and let someone else have the chance.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Josh Nankivel Reply:
November 2nd, 2009 at 11:44 am
That’s another level of this…if the project manager thought everything was fine and it wasn’t, why did the communication breakdown happen between him and his team?
Reply
Nov 2nd, 2009 at 7:46 am
This is a great topic to discuss and IS a big problem. I’ve seen too many projects that get reported as if everything is fine when it’s not…and then at some point it catches up with the project manager.
What about having a project coordinator-type position who does not report to any project manager and is responsible for compiling status reports. They would know the PMB inside and out and simply report progress against it, along with some other analysis and interviewing to ensure the various processes including risk management are being done properly.
I had a role similar to this once, but it was a small part of my role and I reported directly to the project manager. I’m a bit aggressive at times so sometimes my concerns would make it to the status review, and sometimes they wouldn’t. I wasn’t the project manager and being an “auditor” wasn’t my primary role at all.
Thoughts?
Reply
Susan de Sousa Reply:
November 2nd, 2009 at 11:17 am
Hi Josh,
I think the problem is that if a project manager is going to be economical with the truth on their weekly report, it’s hard for anyone else to say anything otherwise particularly a project co-ordinator who is unlikely to have an indepth view of any project unless it is very simple.
And to be honest in very complex projects all that they could do is highlight any slippage in the plan which often is counterproductive. I mean on my current project timeframes slipped, but I always found ways to mitigate this.
The onus I think has got to be on the project manager to be smart about what they report. They need to nsure they report the big picture without unduely causing panic whilst at the sametime not making their reporting line look like wallies. It’s a fine line, but one all us experienced project manager’s are well used to treading!
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Bill Duncan Reply:
November 3rd, 2009 at 7:11 am
Actually, the role that Josh proposes is the norm in the construction industry. It’s called “project controls.” The key to his proposal is that the project controls person is independent of the project manager. On major construction projects, the owner will have a separate contractor hired by the owner, not the builder, to monitor project status. It really doesn’t take a whole lot of expertise to verify and validate activity budgets vs. actuals reported, and to check a couple of end-products to see if they have actually been completed. As well, if the plan is inadequate for good control, the controls person can report that.
Reply
My-Project-Management-Expert.com Reply:
November 4th, 2009 at 1:06 am
Yes but not the norm in the IT industry which is where my experience lies. Possibly it may occur where huge IT programs are involved but even then it is rare.
Mostly in IT the person who does “project controls” is unable, unless the project is extremely simple to quantify exactly where the project is at. And quite frankly it should be the responsibility of the project manager to ensure they accurately report the situation. if you don’t trust your project manager to report properly then should they be in that position anyway?
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Bill Duncan Reply:
November 5th, 2009 at 3:17 am
I know that this isn’t the norm in IT. I was responding to your comment to Josh that suggested it was an idea that wouldn’t work in IT. I actually have an IT client who uses this approach: the controls staff reports to the head of the PMO, not to the PM. In addition, this frees the PM from having to collect status information so that he-or-she can focus on managing the project.
Reply
Glen B. Alleman Reply:
November 5th, 2009 at 9:56 pm
Susan,
I think you’re over stating the situation. There are certainty examples of really bad IT project management. At the same time there are poster child examples of how to do it right.
It depends on the domain. The enterprise IT deployments in engineering centric firms seem to be treated like physical projects – metal bending, concrete pouring. I saw this from managing some of these examples.
You’ve provided one example. I can provide a dozen counter examples – 50 site SAP roll out ahead of schedule under budget.
This is the problem with anecdotal evidence of project success – not withstanding the completely bogus statistics of Standish
Reply
Nov 2nd, 2009 at 9:50 am
I think there’s a difference between being “economical” and being cautious. And generally the difference is seen between seasoned PM’s and less experienced ones.
Being economical implies you’re leaving some information out. Being cautious means you’re being pessimistic, but truthful. As in Paul’s example – I want my Dr. to tell me it’s going to be okay, but not giving me better odds than he truly believes.
And understanding the difference usually comes from being ‘economical’ early in your career, and paying the price. Once you’ve paid that price you quickly learn that cautious but truthful is the safest avenue. For you and those you’re reporting to.
Reply
Josh Nankivel Reply:
November 2nd, 2009 at 10:09 am
Great comment Trevvor.
I’ve found that if a risk management and issue tracking/resolution process is in place and is robust enough for the project environment you’re in, being economical or even cautious isn’t really necessary.
When you are taking valid actions to address problems you can talk about the action being taken.
Sometimes it’s “we’re a little worried about this, but right now it’s in a watch status” or “this is what what we’re doing to mitigate this risk” or “we accepted this risk because it’s minor and addressing it would likely be more costly than the risk itself”.
Sometimes it’s “we’re behind schedule because of xxx, and this is what we’re doing to get back on schedule.”
And sometimes it’s “we made a mistake and underestimated how much this would take.”
Most sponsors respect candid truth (in my experience). Even if they don’t, we shouldn’t lie to them even if that’s what they want us to do. (I guess I’m going back on my “platinum rule” comment awhile ago!)
Reply
Susan de Sousa Reply:
November 2nd, 2009 at 10:48 am
Hi Trevvor,
Yes what you say is very correct. Experience is the key differentiator and we’ve all been in that situation of being “once bitten, twice shy”.
Cautious but truthful is the best way, coupled with not blowing things up out of all proportion. One needs to know when to panic and when not to. Otherwise you will spend all your time dealing with inane questions from senior management, which will make the problem even worse.
So one needs to use their judgement and highlight what is important. But never ever, portray a project as being green unless everything is going fantastically well, even when under pressure from senior management to do so.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Nov 2nd, 2009 at 11:25 am
One element is missing in this discussion … you can’t report progress unless you have a decent baseline to report against. And you can’t develop a baseline unless you have a reasonably reliable definition of what you are supposed to produce.
I continually see organizations, and especially those in IT, using fatally flawed project life-cycles based on the process groups of the PMBoK Guide. When you try to plan the entire project before either requirements or design have been completed, you are doomed to failure … and that is what so many IT organizations are doing. [side note to Susan: I couldn't find any information about "C Norris IT System" after googling that phrase and several variants. Do you have a reference?]
Re Paul’s concerns about violating any Codes of Ethics: neither ignorance nor stupidity are covered by such codes. Project managers who THINK they are doing the right thing are covered.
William R. Duncan, Project Management Partners
Director of Certification for asapm
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Reply
Josh Nankivel Reply:
November 2nd, 2009 at 11:54 am
It’s a great point Bill. When using EVM and even my own variant of “EVM-lite” there’s a systematic way to report an accurate earned value against the baseline. Schedule reporting usually requires some extra CPM analysis and reporting too, but you don’t say something is “done” in the system unless it’s really done.
This all means you have to (as Glen would say) know what “done” looks like.
I will say this: I was involved with a program once where the level of EVM reporting to the customer was TOO detailed. It meant that a bright red spot would show up for a really small piece. When you zoom out one notch everything was fine; and it just so happens that was probably a more relevant level to report at anyway. Because it was too “in the weeds” they got into (useless) discussions that probably wasted more time and $ discussing than the whole item was worth.
So, set up your control accounts at the right places!!!
Reply
Susan de Sousa Reply:
November 3rd, 2009 at 12:07 am
Hi William,
You can find more information on this particular IT fiasco at
http://www.computerweekly.com/blogs/tony_collins/2009/03/failed-234m-c-nomis-it-project.html
http://www.computerweekly.com/blogs/tony_collins/2009/06/-an-unapproved-comment-has.html
On re-reading it again it makes for even worse reading!
I would agree that it is virtually impossible to accurately report project progress unless there is an approved baseline. However from my perspective I’m more talking about the ability of the project to launch. Yes there should be plenty of checkpoints along the way which should highlight that the project is off target, however with probably 50% of the project effort expended in the last phase of the project (my experience anyway), it is often only at this stage that things go awry.
That is when many project managers try to cover things up because they are so close to the finish line and don’t want to admit they have lost control. Of course by this stage it is far too late.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Bill Duncan Reply:
November 3rd, 2009 at 7:27 am
Susan — you say “with probably 50% of the project effort expended in the last phase of the project … it is often only at this stage that things go awry.” How is that different from any other project environment? In construction, the percentage is probably closer to 80%. In New Product Development, design and engineering is often far simpler and less costly than developing the manufacturing process and figuring out all the logistics of bringing the product to market.
As well, from Mr. Collins’s blog, it’s not clear to me that this disaster had anything at all to do with project management. The root cause would appear to be two-fold:
– The contract was let without competitive bidding. This is not a project management issue. This is a management issue.
– Criminal record information systems have a long history of problems due to both privacy issues and the fact that offenders do everything possible to make it difficult to identify them reliably. EDS’s website (now HP Services) shows lots of criminal justice experience, but little or nothing related to criminal history.
Based on the information from Mr. Collins, this is simple malfeasance, and someone should go to jail.
Reply
My-Project-Management-Expert.com Reply:
November 4th, 2009 at 1:14 am
Bill,
I’m puzzled. We appear to have read completely different accounts of the same project??
In the 2nd paragraph it states:
“The National Audit Office published today an incisive report on the Home Office’s National Offender Management Information System [C-Nomis] which showed that bad news about the project failed to go up the ladder of command to those who could have made decisions to rescue it”.
and the No1 finding from the National Audit Report itself:
“There was inadequate oversight by senior management. The NOMS Board relied on the C-NOMIS Project Board to escalate issues to it through NOMS’ routine reporting systems. Between the start of the project and May 2007, the NOMS Board did not ask for or receive any other more specific reports on project progress.
Whilst the Project Board met at least once every two months, it did not actively monitor delivery of the project and was unaware of the full extent of delays or the implications of decisions it made upon project cost. ”
So I am unclear how you can say it wasn’t caused by project management??
Lastly in my view construction and IT project management are completely different things with the only real similarity being that the words project management are used in both. I have no doubt that if you tried to construct a building using agile methodology you’d run into enormous problems.
Regards
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Trevor K. Nelson Reply:
November 4th, 2009 at 9:29 am
Not to change the subject, but I find it interesting that IT PM’s always seem to think that their particular niche is unlike any other and somehow unique in the world of PM.
To your comment Susan, Agile IS being used in construction at the lower levels, as is Lean. No, I wouldn’t run an entire project that way, just as an IT project can use waterfall but wouldn’t necessarily run the entire project that way. But we have more in common than just the words ‘project management.’
Reply
Bill Duncan Reply:
November 5th, 2009 at 3:25 am
My reading of the paragraphs that you quote is that the sponsors failed to exercise oversight. That is a management problem, but not a project management problem. There is no indication that the PM failed to report status inaccurately.
Reply
Glen B. Alleman Reply:
November 4th, 2009 at 9:52 am
Bill,
Malfeasance might be too strong, lack of leadership for sure. Lose their job – yes
Reply
Nov 2nd, 2009 at 10:03 pm
I can’t believe I get to say this first!
The most important thing a project manager needs to do when reporting status is;
How much is done?
How much to go?
How aligned to the plan are we?
If we are behind schedule or over budget what action needs to be taken to get us back on track?
And the other EVM stuff.
If you use EVM or an equivalent, AND you only report on things as done or not done, you are doing your job.
Sometimes the messages are unpalatable to people, but that’s another part of the job; managing communication.
Reply
Susan de Sousa Reply:
November 3rd, 2009 at 12:11 am
Hi Craig,
The skill is in understanding what to report and what not to. It’s a very fine line to tread between ensuring your project sponsors are fully informed, but not alarmed unnecessarily.
I mean on my current project there have been times where I have chosen not to report a certain issue until I’d had a chance to remedy it myself. However I always give myself a timeframe to do so, after which time I report it upwards. In my experience you have to do this otherwise you will get a reputation for “crying wolf” and no-one will pay attention when you actually have a serious crisis on your hands.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Glen B. Alleman Reply:
November 4th, 2009 at 12:12 am
Susan,
You’ve started down the slippery slope of “relative” performance. This is a very poor approach to reporting progress for any project.
Plan the work, work the plan is the starting point for reporting any progress. Craig suggests 0/100 and this is the right starting point.
The key is to continuously ask and answer “how long are you willing to wait to find out you’re late?”
You’ll never be able to answer this question if you don’t know ahead of the start of work what “done” looks like. With this description, you can then report status about reaching “done.” “Done” of course can be incremental and iterive.
But in in the end the status report says only one thing “you either did what yuo said wouo would done for the period of performance, or you didn’t.” If you didn’t the status report must say when you will.
No crying wolf, not “cooking the facts,” nothing – let the deliverables speak for you efforts. Think 0/100 for everything you do and the status report rights itself.
Reply
My-Project-Management-Expert.com Reply:
November 4th, 2009 at 1:21 am
No Josh what I’m trying to articulate (and obviously very badly) is that reporting is not simply a set in stone process. Otherwise why bother to have a report. The PMO could simply generate it?
No it is up to the Project Manager to determine what to report and when. Alarming stakeholders and then wasting valuable time explaining the problem to them is not a good use of time.
This is why experienced project manager’s are much in demand. If they have a track record of delivery to time and budget (as I have) then we knoe what to report and when. it’s called using judgement.
After all on my existing project if I’d reported every single problem or concern I would never have left meetings with external auditors or the regulator during the entire project. As it is, we’re launching on time, and budget and to quality.
If you fall into the trap of simply following a process for reporting then you will find on huge complex projects that you are working ridiculous hours for no good reason. And I’ve seen far too many good project manager’s burn’t out unnecessarily as a result.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Glen B. Alleman Reply:
November 4th, 2009 at 9:27 am
Susan,
Here’s a piece of advice I’ve learned over the past 3 decades in the defense, space, and enterprise business.
You cannot report a problem without some type of solution. Even if the solution is “we don’t have a solution, but we’ll get back to you next month on what we’ve worked out so far.”
Could you provide an example of a piece of information that would “alarm” the stakeholders while at the same not be something they need to know?
A fundamental principle in project management is “all information conveyed to management must be actionable.” What might be alarming is information you present that is not actionable – “we found a problem and have no clue on what to do next.”
Fore example, using your statement…
“… on my existing project if I’d reported every single problem or concern I would never have left meetings with external auditors or the regulator during the entire project.”
Where are these “issues” recorded? Does the stakeholder have visibility into them? Does each issues have a “get to green” plan, with a date for getting to green? Can the stakeholders take managerial action on each of these in some way ranging from acknowledgment to intervention?
If not, I’d suggest you’re not providing them with sufficient information to “manage” their side of the project.
Reply
Nov 3rd, 2009 at 12:08 am
I’ve sold the approach of “Brutal Honesty” in reporting under the notion that it is just more efficient. This gets away from the ethical and moral discussions.
I’ve never seen a project manager hedge on the details (more than once
) if the stakeholders/senior managers encouraged and practiced frank and open reporting. The culture/environment, if it does not support honest reporting, is what inevitably “pushes” folks towards those bad habits. It can take considerable courage and professional risk to buck the trend if it is well entrenched.
Bruce
http://pmtoolsthatwork.com/honesty-efficient/
http://pmtoolsthatwork.com/eliminate-your-project-management-honesty-buffers/
Reply
My-Project-Management-Expert.com Reply:
November 4th, 2009 at 1:28 am
Hi Bruce,
Yes you are right in that. If you work in a supportive system where stakeholders and sponsors are involved and understand your project and issues then fine.
But many environments are not like that. They are full of politics, stakeholders and sponsors who simply don’t care, and nothing matters but hitting the launch date. Sadly I know for a fact that this environment is far more common than the one you describe.
For example I have been pressurised more than once to change my report status to Green from Amber. I have refused but I know of too many project manager’s who have caved and put it into Green.
It’s a fact of life. Organisations now want their projects to be delivered faster, with more functionality and much tighter timeframes. On my project the test team double shifted for 42 days in a row (yes including weekends) to hit the deadlines.
And if you don’t hit the deadline then you’ll quickly find yourself demoted or out. Of course the higher profile the project the more pressure like this there is much as is the case on my current project! There’s nothing like a $7M ad campaign which starts 7 Nov to ensure that you get your project to the finish line ontime, as I am doing this week!
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Nov 3rd, 2009 at 4:13 pm
In the domain we work – defense, aerospace, and civil federal contracts, there is only one good way to report project progress.
Report the physical percent of the planning progress. This approach is mandated by DOD 81650 and the supporting Integrated Master Plan. This approach defines the planned deliverables for each reporting period (monthly or weekly) for the project. These deliverables have associated measures of performance and measures of effectiveness. Along with these deliverables the risk retirement or risk buy down plan is connected to the Integrated Master Schedule.
The program planning and controls staff produces – with a tool – the weeks progress to plan in terms of physical percent complete measured by tangible evidence. This happens when the “owner” of the work (work package) brings this evidence to the progress review meeting.
The risk manager brings the evidence that risk is being reduced according to plan – movement from RED to YELLOW to GREEN.
Without the physical progress held in the Plan and associated schedule, writing the status report means “creating the status through an interview process or opinion of the project staff.”
The Program Planning and Controls approach separates the technical activities from the programmatic controls activities.
For the items listed in the OP,
• Risks
• Milestones
• Key issues
• Risks
• Dependencies
• Budget
Only key issues needs to be developed for each reporting period. All others come straight out of the performance measurement baseline. No performance measurement baseline, no credible source of status reporting.
Every example provided in the OP could be traced to un–credible baseline measures.
It’s a simple and as complex as that. My presentation at this week’s PMI Integrated Project Management 2009 conference, Washington DC speaks directly to this issue.
Reply
My-Project-Management-Expert.com Reply:
November 4th, 2009 at 1:34 am
Hi Glen,
Many IT projects do not have the luxury of a risk manager. They’ll be lucky to have an ITQA person on their project.
But there again most IT projects are not heavily regulated like yours would be nor would have the long timeframes that yours would.
My current one is the worst of both worlds. Heavily regulated but with insane deadlines. I’m “lucky” of what??
So in these cases report in my view need to be a judgement call on behalf of the project manager. After all I have received reports from supplier project manager’s; beautifully detailed, done by following the 0/100 process which really give one a sense of confidence. Just before the major build was due the report was all in green (as it had been for sometime). 2 days later it was red. The build was late and boom the entire program was in jeopardy. I turned things around and got him chopped and the program delivered on time.
The one thing it taught me was to never take project reports at face value unless you have worked with that project manager before and know how they work.
Regards
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Reply
Glen B. Alleman Reply:
November 4th, 2009 at 9:45 am
Susan,
Managing risk is not a luxury.
If you’re not managing risk in some way, you’re not managing the project.
Don’t confuse the management of risk with a “risk manager.”
Our project are not “regulated” in the terms you might expect. They are “managed” with a well developed framework. Risk Management is an element of that framework.
The anecdotes you present here appear to be from projects missing leadership. In the absence of leadership it is unlikely improvements will happen.
Reply
Bill Duncan Reply:
November 9th, 2009 at 11:31 pm
Hear! Hear!
Reply