Glen, World class. Classic. thanks.

Clark, I also feel stung. Cool. What did you change to change back? What menu?

"It didn't work for me, so it can't work for you." I like that. So right.

JR I recently had the unexpected pleasure of completing a four-day PRINCE2 course. I say unexpected as I never was impressed with PRINCE2 having seen it implemented. PRINCE2, as you know, is often used in software projects. At least that's how it was in the very-large-financial-institution in which I was involved in software/technology projects/programmes. They also told me how EVM was not appropriate and did not work. I didn't have the political clout to change their view. They had PRINCE2, though, and PRINCE2 didn't have any form/document which prescribed EVM. Thus, since would never work anyway, and because there was no form, spreadsheet, or PowerPoint project control document which required it, they did not have anything close to EVM. They also had projects that did not come close to getting done, much less within budget, schedule, or quality. I mentioned PRINCE2 and the courase I took. To late to help with the above institution. But I learned the framework/basis of PRINCE2, which I was pleased to learn fit in quite nicely with the framework/basis of EVM. Both PRINCE2 and EVM will work on software/technology projects; but only if the people on those projects allow it.

Yes, you have been travelling too much! :-) Where's "da Vinci Code in that list?" (Full disclosure: I'm going to find the two risk references for reading on my upcoming trip to USA)

Understand. "Virtual Communication Channel" is an oxymoron.

I'm choking on a small after lunch glass of wine ... I support the idea that great tools are at the heart (amongst other components) of great communication. Tools are essential (but, truth be told, probably not necessarily the tools that I understood are advocated by PM 2.0).

@Chart, I fully support this idea. Tools are at the heart of the communication process. Often we debate Methodology vs. Tools--which I think absurd debate, but it is a debate none-the-less--but it really is that the methodologies require/expect communication and tools facilitate that.

Glen, First, I don't work there anymore. It was a "very large but now crashed and shrinking" international financial institution. Left before the crash, but saw it coming. Got tired of the mediocrity. : internal projects : cap is on spending and schedule. Cost and schedule achievement is essential. : sadly, yes it's the company's resources they spend : key planning tool is PowerPoint supplemented with Excel (with lots of these files sent around in email). The visible deliverables are of course delivered on time and on schedule. I over simplify, of course; but scope for technology and internal process projects can be shed easily when compared to aircraft, highways, petrochemical, dams, etc. Think of that character from Peanuts comic strip, Pig-Pen, who walked around with dust following him. That's what unfinished projects look like.

PM 2.0 people tend to have experience/careers in industries and on projects where scope is fungible. Careers based on project success where the political trick is to shed scope to remain on budget/schedule are then self-replicating. (I fondly remember the day I figured this out, at least from my perspective. Worked really hard to get a good (not great due to time pressures) plan/schedule together for a new employer. Heading for a major presentation with a very senior executive who had lots of project experience. We didn't have time to do much more than provide summary screen shots from Microsoft Project for the overall schedule including the cost estimates. Second phrase out of the executive's mouth was "You apparently used Microsoft Project--I hate Microsoft Project". It and the project went downhill from there.)

FYI, the whole chapter published in London Sunday Times last weekend ... so its "out there".

Glen, Not yet read it, but will. Agree combining the two is a risk. Everything in live is a perturbation! (Like I said ... I'm just happy when when we can disentangle reality from probabilities). after that my brain hurts.

Glen, As always, thanks for this. I'm going to say that I like the idea of risks and opportunities being considered at the same time. My experience is that it is not IT-centric--in fact the IT people I tried to get to consider this way of thinking repelled the idea. I like the idea for a few reasons: : Unlike Issues, both risks and opportunities are "probabilistic". They only "might" happen and won't happen unless something is done to make them happen. : Accordingly, it takes the same way of thinking about "possibilities" to identify them, e.g. brainstorming. Further, it probably takes the same management process to figure out what to do and then do it. : Often lurking behind a risk is an opportunity. Often, what at first glance is "bad" could be "good". Further, for a single event, it just depends on which side of the fence you are on as to whether the the event coming true is good or bad. [For example, think of something which could happen could result in extra cost ... but the people receiving that money have an opportunity.] If I have a battle to fight, I would put priority on making Issues and Risks separate and distinct. But risks and opportunities ... I like they are mushed together a bit.

Glen: terrific post. I have a classic story where I was helping a project "in distress". It was in a bureaucratic organisation who required submission of "issues and risks" every week to the Program Office. The PM focused on this of course (you get what you measure). As time passed, for various reasons, about 75% of their time was being spent on "fixing risks". Risks were anything that were on the list. Deliverables had been forgotten. But Issues and Risks were under control. I did two things (which took a long time to get agreement by the PM): 1. Killed the weekly submission of issues and risks by spreadsheet attachments to the PMO and got them on SharePoint. Funny enough, the three columns Josh was at the heart of the new new risk reporting. 2. I made it a rule that they were not allowed to talk about Risks and Issues in the sentence, same meeting, same day. Mondays were for focusing on Issues (and work them during the week), and Fridays were for thinking about risks and thinking about which ones we would actually do something about (and to "do" something required a CR and funding). The Friday conversations in time became discussions at the pub. Made all the difference. Project still late. They never could recover the time lost. But they did agree they became more productive and stopped wasting a lot of time.

Glen, Terrific post. I'm going to be able to use that in my discussions with a potential client who is working with no plan (far as I can tell) and feel they don't need one. Spending more than $20 million on in resource exploration. Their view is putting deadlines into a spreadsheet which gets pasted into PowerPoint is sufficient to direct the large organization spending the money. Thanks for reminding me of the PERTChart Expert as I suspect that might interest them. --rms

Glen, Terrific observation about how risk gets mixed with with issues. The root causes are 1. The collective noun "Risks-and-Issues" roles off everyone's tongue so smoothly in meetings. Management/executive potential is recognised by those who drive their teams towards "risks and issues". 2. Issues are easy to work. Risks take a bit of innovative thinking. Innovation is hard. 3. People think they can indeed *manage* risks.. since there is a profession and sometimes departments called "Risk Management". 4. Because risks are perceived to be manageable, they are fodder for the other bureaucraticly required object called "Risk Register". Careers are protected by putting enough on the list to look like you are managing risks, but it's important to *manage" things off the list so that we can forget about the risk since we *managed* so that it can't possibly happen, or if it did happen it would have absolutely no impact. ... I could go on. I once worked with a project team who was so focused on risk and issues and for the reasons above about the time they were 1 year into a 2 year programme, 60% of their work was being spent on "risks" and little attention was being placed on the promised deliverables. You can imagine (they couldn't) the *risk* to their programme. We had to seperate risks and issues. While it took a while to get agreement to do this, we made a rule that in the Monday morning mgmt meeting they took "risks" off the agenda. Discuss only "issues"--real things. We put risks (imagined things) only on the Friday mgmt meeting, with a rule that issues were not to be discussed until Monday. It worked. Avoid Knee-jerk decisions about what they were going to ACTUALLY do about risks and issues by defering decisions on each until the next meeting.

Nice post. (It's ExxonMobil, not ExxonMobile.)