One of the first things salespeople learn is that perceptions are reality. And the same goes for project managers.

Your perceptions and your reality may differ, but if you want to communicate effectively with someone you need to understand their version of the truth.

Perceptions are also closely aligned with expectations. If a stakeholder perceives an organization as unresponsive and inefficient they will expect bad service. From this starting point, the stakeholder will readily accept as true every experience that contradicts their view of the world. A good experience can be written off as "the exception that proves the rule."

This presents a distinct challenge to project managers who are developing a communication plan. Your stakeholder's perceptions of project management will be based on prior experience with other projects in other times and even other organizations.

This is neither fair nor reasonable but it is a fact!

The situation is made worse by another trait: our tendency to feel and remember bad experiences more strongly than good ones.

Where negative attitudes occur, your solution is basically hard work. You need to assess the current attitude of your key stakeholders, determine the optimum attitude and then work to improve the stakeholder's perceptions of your project.

There are three key elements to consider when working to change poor perceptions. 

1. Build rapport and open communication channels that will be effective. You may need help from supportive stakeholders to achieve this.

2. Build your credibility by providing accurate, timely and useful information that precisely meets the needs of the stakeholder. Help them to be successful.

3. Whenever possible, differentiate your current project from the person's previous negative experiences.

The bad news is one slip and you immediately reinforce the old perceptions. So stay focused and ensure every communication, authentic and credible.

I like coffee. The smell of the freshly brewed morning cup of coffee invigorates me. Just this morning I met with my mentor and I prepared as usual by getting to the cafeteria early with my cup of coffee in hand.

Our conversations usually range from project war stories to best practices and lessons learned. This time around, the discussion centered on a "must-win" proposal effort. You feel confident about the current proposal, but the day before the submission, you're called into the executive office and told the final cost must be reduced by another 20 percent.

Thoughts swirl through your head. Given that you're the project manager, you'll have to update the basis of the estimation so it supports this new, lower cost.

Many times a must-win proposal means being the lowest bidder, hoping to make up the difference from future change requests. If this is the case, then the direction from the executive office borders on unethical conduct.

Why? Because within defense contracting, a firm fixed price contract is the preferred choice for the government because any overrun would come out of the contractors' profit margin. Imagine that you know it would really take you US$100 to do the job but you bid US$80 knowing that you're the lowest bidder in order to win the contract in the first place. Once you are awarded the contract, you employ various strategies to bring to light that the customer really needs additional "enhancements" in order to fully execute their missions. Magically, the total cost of the enhancements seem to add up to another US$20, plus additional margin.

All bids must provide basis of estimation (BOE) to justify the dollar amount. On the day before the proposal submission if you are directed to lower the final bid number by 20 percent and there is no way you can revise the basis of estimation in time and you signature is on the proposal, then you are lying to get the business.

So what do you do? 

I think that if the original basis is sound and was validated through independent review, then it's the job of the project manager to say no and explain why that can't be done without compromising the integrity of the submission.

Before I could for a response, my mentor said it was okay not to have an answer right then. When that day comes, my action will be rooted in principle and on doing what's right.

Does the end justify the means?

On a personal note, I'll be taking December off in anticipation of a new addition to our family. Best wishes to you for the various holidays coming up.

I received an intriguing question at a recent webinar I led: "How does Six Sigma training address or include the concept of acknowledgment?"

That question was actually a new one for me! So I turned to my colleague, Anne Foley, director of Six Sigma for International Institute of Learning Inc. Apart from the usual reasons why you need to acknowledge a team member, I asked what role she sees acknowledgment playing in Six Sigma training?

She said the training discusses the kind of culture you establish if you only acknowledge those who put fires out, without acknowledging those who actually prevent the fires.

"Fire prevention is critically important to business success but often goes without notice. If you want to change the culture, you must change the way you acknowledge, celebrate and reward employees by honoring those who prevent fires as much (if not more) than those who put them out."

Anne talked about how one of her green belt students discovered his company had a defective inventory management count. Finances showed the company had spent a certain dollar amount on inventory--and that did not match the amount of inventory in the system, which did not match the physical count.

He investigated and found that the inventory-entry process was broken, which could have left the company without critical inventory to run its business had the problem not been discovered. He found it, fixed it and his boss was so happy he wrote it up in an internal company newsletter and gave his employee a whole week off--with pay.

At several companies where Anne has conducted training, managers are trying so hard to acknowledge and encourage fire prevention that they actually run competitions among those who prevent errors--and the awards are big--from free dinners to stock options.

Sincere and heartfelt acknowledgment always makes a profound difference to people. But did you know it also prevents fires? What an awesome tool!

So thanks to the student who brought this question to my attention. I learned something important and hope you did, too!

It's finally time to expose the biggest myth as I close out my taking-on-the-myths series, hopefully generating plenty of lively responses.

Myth 2: Comparing your project's budget to actual costs is a natural way of assessing cost performance.

Truth: Comparing budgets to actuals is not only useless, it's misleading.

To back up this little piece of iconoclasm, I will invoke the widget example I use when teaching the subject of cost performance measurement.

Imagine you are a project management assigned to a project to make 2,000 widgets in two months with a budget of US$2,000.

You time-phase your budget US$1,000 in month one and US$1,000 in month two.

At the end of the month one your accountant tell you that you've spent US$1,100. How are you doing?

If you said "poorly" based on the fact that you have spent US$100 more than you budget, go to the back of the class.

If you said, "It depends on how many widgets you've made," go to the front of the class.

Because if you've made 1,300 widgets, and each widget is worth US$1, then the proper comparison is obviously the US$1,300 in earned value against the US$1,100 it took to make them.

A very simple example, I grant you, but it starkly supports my assertion.

The Biggest (in my opinion) Myth: Agile and scrum are novel improvements to traditional project management, tailored for the software industry.

Truth: Agile and scrum were developed to allow IT projects to indulge in all the scope creep they wanted.

My take is that the most lethal practice to project health is to allow informal changes to the technical baseline without changing the cost of schedule baselines--a practice commonly known as scope creep.

The IT industry is particularly susceptible to this, since changing the size of a building or the speed of a ship is hard to miss and affect. But changing the look, feel and capability of a software package may require little more than adding a few lines of code--and how hard that can be.

What started happening within the IT industry, on a common and costly basis, was that seemingly small changes in the various code modules created a configuration management nightmare.

So, we see the introduction of tactics that "max out" project team communications, including co-location and employee roles that define the nature of their interactions with their colleagues, customers, and the technical agenda.

But I have to ask: If the technical baseline was thoroughly and clearly defined at the project's start, and only changed formally, would any of this really be necessary.

So what do you think? Myth or reality?

Editor's note: PMI members who are interested in agile should check out PMI's new Agile Community of Practice.

Project management may not be all about document management, but it's a necessary and important part of the job. And it all starts with the project definition documents created in the planning phase.

As the name implies, these documents outline the details of a given project, such as business goals and requirements, scope, budget and project management plan.

Project definition documents should include:

Basic project data: Goals, objectives and any business issues to be resolved

Project execution parameters: Definitions of project boundaries, key policies and procedures that are specific to the organization and that must be followed to integrate the project work and its result into the organization during and after the product delivery

Required project management methodology: Governs how the project is planned, how each phase is executed and what's required to move from one phase to another

And don't forget any other information that might be helpful to anyone who wants to know about the project.

What's great about A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is that it offers project managers an idea of what should be included in the project management plan. Project managers can then create various project definition documents that best the the project at hand.

What tips do you have for putting together project definition documents? Are there certain processes you always follow?

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) is developed by hundreds of volunteers to represent generally accepted good practices in project management. But is this enough?

There are already extensions to the PMBOK^®Guide for the construction industry and government that expand the basic framework to meet the needs of these sectors. Is there a need for extensions to meet the needs of different cultures?

The value of diversity and the challenges of managing culturally diverse teams was the focus of Tom Sullivan's feature article "Common Ground" in the October issue of PM Network^®. My column in the November edition of PM Network, "Culture Shock," highlights some contractual issues that impacted a major mine development. As projects and teams become more global, managing appropriately within and across cultural boundaries is a key project management skill.

Although there's no right or wrong in culture, different societies resolve challenges in different ways and use very different structures to communicate information within businesses and projects.

As PMI moves toward the start of the next PMBOK^® Guide update project, I would like to take the opportunity to discuss issues and challenges of managing projects in a cultural context. Do we need cultural extensions to the PMBOK^® Guide or is there more value in retaining it as a core definition of good practices that apply worldwide?

I've had my say in PM Network, now it's your turn to weigh in. Over to you!