The PMBOK identifies several process areas, all of which make up the job of the project manager. Two recent areas of current discussion within our organization are those of Time Management and Cost Management. In order to manage time and cost, it would seem obvious to many that you need to establish a baseline for these (or budget if you prefer), and then be able to record and contrast what actually happens in order to compare and control. There is a camp within our organization that feels that collecting and tracking actual hours/costs is an administrative burden on the project manager that takes away from the time required to manage the project. The other camp states that without this information, managing the project is not possible. I’d like to find out if other organizations have had to deal with such a debate, and how it was resolved. I’m obviously too close to the issue, and know that this discussion board is more than willing to provide opinions that I had not yet considered. Thoughts?
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Rich, Looks like the debate in your organization is still raging! I agree with your characterization of the just do it approach -- pre-school says it all! The debate misses the mark. What is needed is a middle ground between overly formal, rigid methods and winging it. Saying what you are going to do, then monitoring that its getting done is basic to project management, as is a clear way to manage change that occurs in the interim. Maybe the proponents of just do it are into things like extreme programming and agile methods and confuse these methods with anarchy. One argument in support of the use of at least somewhat structured methods is that managing projects has a fiduciary responsibility. Organizations need to know how money and other resources are being spent so informed decisions regarding continued investment can be made. Maybe some folks in your organization feel a need to avoid scrutiny. Saving Changes...
I agree, it sounds like the "just do it" crowd are repeating the mistakes of the past.
One of my favorite elements in debates like this is they often defend the don't plan, don't track, and work hard approach by quoting approaches like Extreme Programming. I can say with confidence that anyone who defends the "just do it" by quoting Extreme Programming hasn?t read extreme programming. I would ask the person who is promoting the "just do it" approach to validate with resources and information why they believe what they are saying. I nailed my current client about extreme programming. He was telling his team that extreme programming promoted two people locking themselves in to a room and working hard and furious until they were done. He doesn?t say that anymore.
Nearly all iterative development practices, rapid development methods, and efficient product delivery approaches defend planning, quality assurance, and a formal design process. Don?t let someone?s opinion and propaganda deter you from the course of proper project management. Have people defend their sources and justify their approach with industry best practices. Saving Changes...
Picking up a couple of the themes in this discussion that I whole-heartedly support:
Rich: There ARE people out there who still take the JUST DO IT approach. Fortunately they are less populous in project mature organisations.
Frank (W): The secret lies in working out what data really contributes to the project outcome in the specific organisational context, AND establishing at the outset the most effective and efficient way of doing this. In complex projects, manual(even semi-automised) collection is PURE "D" Dumb - there are smarter techniques.
Mike O'C: There certainly are three typical constraints, and this is supported by a trend to specify other strategic KPI for a project (albeit a very finite set), on which performance measurement is based. It makes sense therefore that qualitative if not quantitative data on these KPI are kept. (E.g. a project may be undertaken specifically to win future sales - this must be enshrined as a KPI and metricised -even if the actual results are seen downstream there have to be some project attributes related to this KPI that are observable during the project.)
I would push the boundaries further. Currently working with a group in Australia to develop performance metrics for projects against each PMBOK function. Can't say this is any easy process, and the metrics need to quite generic as a general standard. e,g How many risks eventuated that weren't previously identified on the risk register? Of course one of the issues here is to set up an organisational baseline for performance.
AgGree with Frank W's last comment in that the issue is contentious, although within project mature organisations the idea of setting project metrics in key areas, and project managers maintaining strong baseline control is a virtual given.
But Rich, the classic problem remains how to hold discipline whent the organisational mind set does not support this philosophy. Just like the old problem of teaching pigs to sing, they aren't very good at it, and they get angry as hell during rehearsal.
David Hudson, Brisbane, OZ
Saving Changes...
Anonymous
We are in the process of defining and implementing several project management processes within our organization. Specific to Risk Management - can anyone suggest a quality and efficiency metric that they've used to measure the output and goodness of that process? Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Anonymous, one approach we use is to measure how well the output of the risk management process, the risk plan, identifies and mitigates project risk. After the project as part of our continuous improvement process step, we assign a value of 1.0 if the risk plan identified and mitigated the incurred project risks, a value of .5 if the risk plan identified but did not mititgate the incurred project risks, and a value of 0.0 if the risk plan did not identify the incurred risk. For anything other than a 1.0 score, the project manager summarizes the lessons learned of the risk event and prepares an improvement recommendation to prevent or reduce the likelihood of future occurences of the risk plan defect. This high level metric or "grade" is more focused on identification and correction of the risk plan output defects than a specific score. Hope this helps. Nice post, I would like to hear and learn from others on this. Cheers. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
