Mark DyslinHR Project Leader| Xerox Business Services LLCDallas, Tx, United States
I often wonder if all the material we put together in the early phases of project is much ado about nothing.
The average (read: most clear thinking people) business person wants to know:
1) when the project will start;
2) when it will end;
3) how much will it cost, and;
4) will the project deliver value added results?
Yet we provide things like:
1) stakeholder analysis matrix;
2) up/down/sideways communication channel profiles;
3) progress reports that have to be shrunk down to 42% just to fit on legal paper--landscape oriented;
4) WBS PDT Analysis with GRGFT stroke 1 addendum and so on.
What are your best practices? Saving Changes...
Sort By:
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
My best practice: only provide what people want. Anything else that you have to do to keep the project running smoothly and with excellent governance: keep in your own filing system. I've never met a project sponsor yet who wants to read a WBS.
As for the progress report on one page, the project manager from the London Olympics infrastructure project managed to report her entire programme on one piece of A3 paper, and we saw a copy at the UK Synergy conference earlier this month. If she can do that, surely we can manage to get a progress report on one page! Saving Changes...
Jeff DahlProject Leader| Edward JonesMaryland Heights, Mo, United States
I agree with Elizabeth. What you put into the first portion of your post is what the business owners and stakeholders want to know, but to develop that information you need the information from the activities you list in the second half, and them some.
I have found business leaders and key stakeholders are very much engaged in the up front planning of a project but very quickly begin to move away when the project moves into development and implementation.
In my opinion they feel that they have contributed what they need to for the project to move forward and if there are any critical ansers needed then they will make themselves available for that dicusssion, other wise they trust you to do what they hired you to do which is manage/lead the project to a sucessful outcome. Saving Changes...
Sam MotesManager II Business Sys, Operational Excellence| BA Systems Inc.Ellenton, Fl, United States
To Mark's point, knowing your executive sponsor and wanting to get to the point you tailor the communication to him/her to be directly to the point and only the key facts they want. I agree strongly with Jeff and Elizabeth though that if you don't do your homework then you may not have the data to back up what you say and if called on it you will look more than foolish. Saving Changes...
Lots of such documentation does seem unnecessary. Indeed one thing that bugs me is that some organisations require, usually for their PMO or their “gateway review process”, that certain documentation is produced and maintained and yet nobody ever actually reads it or uses it. It does tend to be the case in those organisations that completion of such items is their key measure of the PM’s performance, so you can’t avoid doing them (although some PMs have been known to fill them in with just standardised returns).
That said, just because your sponsor or whoever doesn’t want to see your WBS or stakeholder matrix or whatever, it shouldn’t stop you from creating them if you will find them of use in managing the project.
Saving Changes...
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
So funny, I just wrote a post very much in line with this thread. One of my biggest frustrations is too much detail and trying to lock down and control things too early. There are certainly items that should be put together at the outset to guide the vision and overall strategy for the project, but if you have a detailed design for the whole thing before you've started, you are doomed to rework and overhead city.
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Great post and replies. I agree with them all. Like Elizabeth advises, I would seek to only provide what people want. I would also add that these kinds of best practice techniques should be a matter of PMO guidance and continually improved upon rather than left to luck or hope and prayer. Saving Changes...
Kevin HartfordProject Manager| Olgoonik Specialty ContractorsArlington, Va, United States
I am currently cranking out program plans and I find that the more I think about it, the more it is about trying to reduce risk up front. Since, I'm working on a notional program that may or may not happen...I'm trying to develop enough detail so that all personnel involved can follow the plan, but also try to leave enough flexibility due to a whole lot of unknowns. It is challenging, I question everything on an hourly basis...but I think that if I can have a good 80% solution, I can be agile enough to make course corrections when needed. Saving Changes...
Mark DyslinHR Project Leader| Xerox Business Services LLCDallas, Tx, United States
Thank you all for the thought provoking comments. In my opinion, your posts (and some of my own $.02) can be boiled down to one simple concept: the cone of project information:
- The top 80% (way up at the top where the light is the brightest) of information is at a level so people can do a quality job and on-time - basic information with links to more detail if needed;
- the next 10% is the summary or "sales" level;
- the last (and darkest) 10% is the obnoxious level of detail level. We don't like going there, but it is there if needed.
We are all overloaded with information/junk on an hourly basis. We need to help our clients sort through the piffle (sorry, been dying to use that word) and generate information that means something and means it quickly. Saving Changes...
