Recently I had the opportunity to put together a "sales pitch" presentation to inform a potential customer about a latest and greatest widget. The audience included a vice president, a manager, some end users and a finance analyst. Since this presentation could potentially bring in a sizable amount of work for our team, I was nervous from the start.

Throughout the briefing, there were a healthy amount of discussions going back and forth between our team and our potential customer. Momentum was high after I concluded a few live demonstrations.

However, toward the end of the presentation, the infamous question came up, "How much is this going to cost?" My manager was the intended receiver of the question. There were some initial unintelligible hums followed by a long pause.

Then I interjected and started to describe a comparably scoped project that we'd done and how much resourcing it took to complete. I pointed out the similarities and proceeded to work with the audience in flushing out a detailed project scope. We concluded the briefing with a favorable impression and an agreement to continue our engagement.

As we traveled back to our office, I realized in answering for my manager that I'd decided to act on the notion that it's easier to ask forgiveness than to request permission. I am curious to know what my fellow project managers thing of this idea ...

In my case, my manger made a comment later that he would need to add "Pitch Man" to my current title. To my relief, he was smiling.  

Part four of my taking-on-the-myths series will challenge our statistically minded segments: the risk managers.
 
Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted.
 
Truth: Monte Carlo simulations are needlessly complex and shouldn't be used.
 
Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust.
 
But is it really?
 
Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs.
 
This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly.
 
But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding.
 
Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle.
 
Truth: After the baseline is set, formal risk management is pretty useless.
 
This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying?
 
Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success.

Effectively planning a project timeline starts with gathering the appropriate inputs to develop schedule process. And spending the time to carefully plan the activities, sequence them, define durations by gathering this data from performing resources, build resource calendars and get estimates is critical to the project.

It ensures a great start, good data and estimates that are better than just an educated guess.

But, I often find many holes in the scheduling exercise.

You have to deal with a lot of details about the activities being planned, the maintenance windows, resource availability (or unavailability), the timing and sequencing of activities, the amount of detail we have vs. the amount we actually need, etc.

I find it helpful to map out key activities on a wall, with the critical path being set and clear. Then I break the activities down and put the similar chunks of information together.

You don't always get a complete picture of the schedule--it's a progressive process. And you sometimes you miss some things when you don't visualize all the steps that you have to go through. But it fleshes out the dependencies and the risks.

Of course a lot depends on the project itself, how much information is already available and how much knowledge the person who does scheduling has about the technical side of the project itself.

Many project managers tend to bypass this process or minimize it and leave it to the day-to-day "figuring out" process, rather than planning the scheduling sessions with the team. That reduces the quality of the overall plan and forces the project to go through more changes than it has to.

Controlling the project schedule is a process that is done a lot easier when the upfront
work is done. Coupled with accurate reporting on project status, the schedule
can be easily adjusted and kept up to date and relevant, without constantly
re-baselining the schedule.

I had the honor of presenting on the power of acknowledgement at PMI Global Congress 2009--North America in Orlando, Florida, USA last week. Whether it was a long presentation or a booth demo, people told me they were inspired into action.

I got into a deep conversation on acknowledgement with Efrain Pacheco, a senior project manager at the U.S. Department of Justice and assistant vice president of the Chapter-to-Chapter Outreach Program for the PMI Washington, D.C. chapter.

Efrain shared something poignant. He told me he's humble by nature and this is the way he was brought up in Ecuador. And as a result, he has difficulty accepting acknowledgements.

At the Executive Office for Immigration Review where he worked as project manager for the information systems and IT support, for example, Efrain was given an award for turning around project.

It was given to him in from of his whole office. So he smiled, but he told me he couldn't say anything or even let himself feel anything because he felt so strongly that his entire team should have received the award.

Efrain's story brings up two important issues: the need to accept acknowledgments with grace and appreciation, and the positive value of wanting to share the glory with one's team members. I am going to focus on the first now and address the other in a future post.

Here's the deal, folks. When we don't accept an acknowledgment graciously, it's as if that person gave you a gift, and you said, "No thanks. I don't want or need that. I don't even like it."

That's what an acknowledger is left with when the acknowledgee says, "Oh, it was nothing" or "It was no big deal." Or as in Efrain's case, when he just smiled but didn't express his appreciation and allow himself to feel the joy that comes naturally with being acknowledged. He just couldn't let it in. Instead, he kept a wall around himself.

When I told him he was rejecting a gift, he was shocked. He had never thought of it that way. He is now committed to working on accepting the precious gifts of acknowledgment.

Remember, someone who acknowledges another in a heartfelt and authentic way is making himself or herself vulnerable. They are trusting that the person will fully receive their gift.

Don't disappoint them.

Stakeholders must be important. A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)--Fourth Edition has over 380 separate references to the word "stakeholder."

But the thousands of managers struggling today to meet stakeholder expectations may be interested to know that only a few years ago no one bothered. The whole concept of business or project stakeholders is a relatively new phenomenon.

The legal concept of a stakeholder is not new. Neither is the concept of "having a stake" in something.

One must also presume the concept of delivering a quality product to meet the needs of the end user, customer or client is not new.

In fact, many 19th century businesses had enviable reputations for customer service. Which leads to the question: What changed?

The origin of a business stakeholder in management literature can be traced back to 1963, when the word appeared in an international memorandum at the Stanford Research Institute. Stakeholders were defined as "those groups without whose support the organization would cease to exist."

The concept of business stakeholders was also a core part of the work on systems analysis in organizations conducted by researchers at the Tavistock Institute in London, England in the late 1960s and early 1970s. The concept has since grown from those beginnings.

During the last 30 years, the people and organizations covered by the term "stakeholder" have continued to expand and evolve. Stakeholder theory now includes the concepts of corporate social responsibility, organizational theory, systems theory, customer relationship management and governance.

And in the last few years, stakeholders have come to encompass anyone with an interest in or who is affected by the work of an organization or its deliverables, or as someone who contributes to the work or its outcome.

Now that the idea of a stakeholder has come of age in the project world, the new challenge is stakeholder relationship management maturity. Organizations that develop this capability quickly are likely to have a significant competitive advantage--at least until their competitors catch up.

Project managers are in for some big changes. Coming in on schedule and within budget is all well and good--but it's not enough.

That's been the running mantra for a while now, but it seems to be gaining even more traction as Harold Kerzner, PhD, explained in the first-ever closing session at a PMI global congress in North America.

"Time and cost used to drive all decisions," said Dr. Kerzner, senior executive director, project management at the International Institute for Learning Inc. "Now we're saying, 'Wait a minute, are we providing value?'"

Without that, the project will be axed.

"If management doesn't see how a project will deliver a value, that project will be canceled even if it's meeting time and budget constraints," he said.

Not all constraints have equal value, Dr. Kerzner said.

That's quite a mind shift for project managers--and it's going to take a whole new skill set.

Indeed, Dr. Kerzner boldly predicted earned value management will be "obsolete very shortly," upstaged by value measurement methodologies that consider intangibles such as goodwill or reputation.

And while a mastery of technical knowledge use to suffice, that's now considered "old school."

"Project managers must understand business," he told the crowd.

They will also need an understanding of politics, culture/religion, stakeholders and people. And Dr. Kerzner predicted a new wave of certifications in complex projects, virtual teams, cultural differences and morality and ethics.

Project managers who go in armed with those skills will find a receptive audience in the executive crowd.

"The biggest change in the last several years has been in senior management support of project management," he said. "Senior management no longer views project management as a career path. It is now viewed as a strategic competence necessary for survival of the company."

Do you agree with Dr. Kerzner? Are you seeing increased demand for business understanding--or should project managers stick to what they do best?

In my last post challenging project management myths, one responder noted that I was unclear about what part described the myth and what part described the challenge statement. Here are numbers 5 and 6 on the hit parade, with the parts a bit better defined.

Myth 6: Complete and detailed procedures are an essential part of a successful project control system implementation.

Truth: Writing procedures are generally a waste of time and they don't help advance project management maturity.

Think about it, is there anything in the universe easier to ignore than a document? But the myth persists that procedures by themselves can advance an organization's project management capability.

Usually these procedures are signed by  a high-ranking member of the organization, who is attempting to compel obedience or participation in the project control system.

But unless the organization has authorized someone to actually  fire or demote others for failure to comply with the document--which happens rarely if ever--then the procedures themselves won't help.

Myth 5: If a schedule based on the critical path method isn't available, a good interim step to manage a project's schedule is to create a list of milestones or action items and meet to review them on a regular basis.

Truth: Action item lists and milestone databases are essentially polls and have no place in legitimate management information systems.

I once worked on a major program in which participants entered project data into a milestone database and provided monthly updates to those milestones.

At the beginning of the year, all of the milestones were scored "green," meaning the milestone would be met on time.

Byabout the ninth month, a few "yellows" would show up in the status column, indicating a possible delay.

More yellows would show up in month 10, followed by even more in month 11 along with a few "reds," indicating the milestone would be missed for that fiscal year.

By the last month, easily half of the milestones were either red or yellow. Lots of scolding and badgering would then ensue, followed by a new "baseline" for the next fiscal year, and-- shazaam!--all the milestones would be green again.

Asking participants what they think of their performance is not a performance management system -- it's a poll. And polls are not substitute for real management information systems.

I look forward to your responses because I know a whole bunch of people are going to disagree with these two.

I've been discussing stakeholders and communication for some time now without focusing on the key question: Why do stakeholders matter? Well, on most projects, stakeholders equate to risks.

There are a few risks that don't involve people--inclement weather, for example--but 90 percent of the risks on most projects are caused by one or more people:

•    Quality risks  almost always occur because people do not follow or not understand processes.

•    Design risks are usually the result of people not communicating.

•    Time and cost risks typically tie back to the performance of people doing the work.

•    Even inclement weather is influenced by people's perceptions--what's deemed "too wet to work" in a temperate climate may be seen as okay in a tropical monsoon climate.

People also determine if a risk is acceptable or not. Whether a risk is perceived as acceptable or not is 100 percent inside a person's mind.

As project managers, our job is to reduce risks to a level that gives the project the best overall chance of success. Yet extreme risk aversion will kill a project more effectively than a gung-ho attitude.

Of course, what constitutes a sensible level of risk is totally dependent on the perceptions and risk attitude of your key stakeholders.

That's why a central part of effective stakeholder management is ascertaining the risk attitude of your stakeholders. And then you must either adapt the project to fit within these parameters or provide the necessary information to help the stakeholder change his or her perceptions of what is acceptable.

The more that people feel they understand a situation, the more willing they are to accept risks.

Similarly, if you have a trusting relationship with someone, you're more likely to rely on their capability to safely manage risks on your behalf.

The most useful risk management strategy you can use on your project is effective stakeholder management supported by good communication. What has your experience been?