In the children's story, The Emperor's New Clothes, a vain emperor hires two people who promise to make him a new suit of clothes that will be invisible to anyone who is unfit for his position.

The emperor cannot see the clothing himself, but pretends he can so as not to appear unfit for his position. Instead of questioning or pointing out the truth, his subordinates do the same, choosing to consciously deny a truth, praising and congratulating the emperor.

In this story, the emperor's men displayed a common behavior -- denial -- that stems from the human need to protect oneself. I believe that this behavior exists in today's project environments, too.

Often in project environments, for example, there is frustration over meetings and discussions that fail to address or acknowledge the proverbial "elephant in the room."

These are the unproductive meetings that review irrelevancies, repetitive issues and problems, but never the actual root cause. Participants stay silent and indirectly endorse the status quo, but then proceed to gather in "safe" groups to discuss real problems and sentiments away from the ears of managers and leaders.

Failing to challenge, speak up or change a situation are all behaviors stemming from denial. Project professionals may choose to deny something out of fear of consequence or feeling embarrassed if deemed wrong. Sometimes it's out of self-preservation because it's easier to be a "yes" person than to challenge the status quo.

Behaviors stemming from denial can also result from over-optimism -- especially when it comes to risk identification. Overly optimistic people tend to deny anything is wrong or can go wrong. Denial can also cause negative consequences for individuals, teams and projects. If left unchecked, denial can become part of an organization's culture.

Project leaders must recognize and reform denial behaviors. Doing so can uncover deficiencies, eliminate blind spots and help an organization become more efficient and competitive. By removing the root causes for denial, individuals will align their interests and act in favor of the team, project and organization.

In my opinion, the best way to do this on your project team is to lead by example.

Set standards by being decisive in day-to-day management. Implement and insist on good, documented work processes. Listen and understand colleagues, and work with the differences and opinions. Individuals on the project team should know what is expected of them and be made to feel valued, secure and included.

Tell the truth about a situation, even if it is bad news. This encourages others reporting to you to do the same. Create a culture that encourages and rewards team members to flag issues and ask questions because problems that are visible stand a better chance of getting resolved.

Do you agree that denial behavior can be a problem in the project environment? How do you root out the negative effects of denial behavior?
 

The months of July and August have a few events that can put kinks in your project plans in the Gulf Cooperation Council (GCC) countries.

During the summer, for example, temperatures can reach as high as 122 degrees Fahrenheit (50 degrees Celsius).

Project managers working with or in the Muslim world also need to plan for Ramadan, when the majority of the population fasts between sunrise and sunset. Then there's Eid al-Fitr, a national holiday that marks the end of Ramadan. Its importance is similar in scale to Christmas or Yom Kippur.

These combined events mean project managers must plan meticulously to ensure minimum disruption to their project schedules.
 
During this one month, the expected impact on the construction sector alone is a reduction of productivity by 40 to 60 percent. The main causes are heat and a fasting workforce that is unable to work at full capacity.

Additionally, project managers in construction face government constraints, which forbid laborers to work more than six-hour shifts in the day. They must stop working at noon and wait until it gets cooler to start again.

To keep project schedules moving during the very hot weather and major holiday, the key is to plan, plan -- and plan some more. These planning best practices can help:

1. Begin planning for special events about three months prior. The project manger should meet with the customer, contractors and suppliers to agree on expectations, tasks and deadlines.
2. Determine activities that can be moved up or delayed to compensate for risks during the special event, such as climate, absent staff and lower productivity.
3.  Employ more staff to compensate for loss of productivity. 
4. Keep a sharp eye on daily logs. Doing so will minimize risk -- especially in cases where work hours or the calendar have been altered and extra resources have been employed.
5. Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
6. Ensure health and safety of employees in the work place. In the case of heat, plan for generators to cool work sites, for example. Provide plenty of water, appropriate clothing and equipment.
   

How do you plan for special events in your project calendar?
 

Risk management as a best practice is critical to project success. It forces the team to consider the deal breakers on a project, and to proactively prepare and implement solutions.

PMI's recent 2012 Pulse of the Profession report found that more than 70 percent of respondents always or often use risk management techniques to manage their projects and programs and these practices lead to higher success rates.

Here's an example of how risk management could have saved a project:

A project manager oversees an electrical team that is responsible for installing electrical and audio-visual equipment. The construction and civil engineering teams hand over the completed and decorated site, ready for the final phase of the project. To the project manager's dismay, the projectors do not align with the screens, rendering them not fit for the purpose.

What went wrong?

The civil and construction teams had altered the dimensions of the rooms; the customer failed to communicate the changes to the electrical team. Assuming the project was executed according to plan, the project manger planned and submitted the electrical drawings based on the original dimensions of the room. These plans were made redundant when the room dimensions changed, which upset the equipment's position.

To correct the situation, the project manager drew and submitted new electrical drawings. The site's walls and ceilings had to be reopened to accommodate the changes, which caused delays and increased cost, rework -- and frustration.  

Had there been a robust risk identification and implementation plan, they would not be in this situation. Too many assumptions were left unchallenged and risks pertaining to the many external dependencies were overlooked.

As part of this risk management, proactive communication with the customer and other teams should have been planned. For example, the project manager should have considered and asked questions about how the contractors and sites would be monitored and controlled. What would the frequency and type of communication be like with stakeholders?

There should have been an assessment of 'what if' scenarios. What happens if the deliverables are not as expected? What are the risks if there are problems with contractors? What is the impact of not having dedicated resources on the team?

These types of discussions and questioning would have alerted the project manager and team to proactively plan to manage the quality of contractor work and employ the necessary resource on the project team.

Do you practice risk management? How does risk management planning make your projects successful?

To discuss Pulse of the Profession on Twitter, please use #pmipulse.

See more on the Pulse of the Profession.

Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project.

Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.

However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.

Why?

Here are some reasons a charter is left out, based on my experience:

1. Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
2. At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
3. The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
4. Requirements and other changes to the project deemed the existing project charter obsolete.
5. The project has been initiated or is continuing without real executive commitment. 
6. The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.' 
7. A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
8. Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
   

However, without a charter, a project is headed for problems including:

Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.

Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.

Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.

Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.

Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.

Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.

Do you know of any other reasons why a project charter would not be created? How can the lack of a charter plague a project?

The increase of international projects has made working and communicating with people of different cultures and languages more common. Preparing and understanding another person's culture, mind set, sensitivities and communication styles can maximize the chances for successful outcomes.

Some of the most common problems of cross-cultural working arise from three main misconceptions:

1. Assuming your way is the correct way
In my experience working in the West, it's generally considered a positive trait to be able to communicate assertively, directly and voice an opinion.

But for Far East and Arab cultures, communicating in this manner is largely considered rude and aggressive. Emphasis is placed more on honor, pride, politeness and relationship building as a means for successful collaboration.

2. Assuming everybody understands your language
When I began working in the Middle East, I wrongly assumed that my strong British accent and articulation of the English language was clear for everyone. But just because I spoke clearly did not automatically mean that everyone understood me.

In fact, politeness prevented people from telling me truthfully that they didn't understand what I was saying. Though English is spoken around the world, it is still a second or third language for others. Allow time for others to process what is being said.

Additionally, the word "no" does not exist in some cultures. These cultures breed an optimistic disposition, and the answer to everything is a nod of the head, whether it's impossible deadlines or difficult requirements. If left unchecked, the end results will lead to frustration, misunderstandings and differences in quality expectations.

3. Selecting organizations or individuals on language abilities
When selecting suppliers, implementation teams or project staff, it seems more reassuring to recruit based on English language skills. The assumption is that communications will be easier and mitigate risks associated with translation.

This can actually backfire as the ability to communicate in English does not necessarily mean a person or organization is suitable for the job.

Based on personal experiences and lessons learned, here are my suggestions for good practices for project managers who work across cultures on projects:

• Begin conversations with a warm and engaging welcome. If you can learn the greeting in the local language, this immediately breaks the ice and leaves a good impression.
• When speaking English, speak slowly and use simple words.
• Limit professional jargon and unfamiliar terms until you are sure they are understood.
• Ask questions and politely request the other party to share their understanding.
• Never show frustration at having to explain something more than once.
• Insist on an opinion or clarification if one is required.
• Listen to everyone's opinion. It may be the person who is not speaking or is not the most articulate has the most valuable input.
• Be patient and tolerant in accommodating others' styles of making a point.
• Be astute as to what is being said and why.
• Follow up meetings with appropriate written communications to confirm times, dates, costs, and any other agreements or actions. Insist on a reply confirmation.
• Ask, request and check for constant feedback
• Smiling, relaxing and showing personality helps build relationships faster.
• Deliver on your commitments. This builds trust and respect. It sets a standard and makes it easier to hold others accountable.
• Employ multilingual people who can advise on cultural norms.
• Spend time building communication networks.
• Consider cultural training, guidebooks or manuals for all team members working on cross-cultural projects.

What advice or experiences of interacting with other cultures can you share?

Read more posts on risk.
Read more posts on best practices.

The revolutions and demonstrations last year in the Middle East and North Africa, dubbed the Arab Spring of 2011, was a trying time for project managers in the region. As we near the first year anniversary of these historic events, we face more uncertainty.

We have witnessed the evacuation of expatriate staff, the relocation of operations, and an unmotivated local workforce. Project managers still see strikes, riots, civil disobedience and tension.  

Some projects have been derailed, failed to meet their objectives or are late. Customers have faced contractors, suppliers and developers absolving themselves of their contractual responsibilities by pleading "force majeure."

"Force majeure" is a common contractual clause that frees parties, bound by a contract, from liability or obligation if an "act of god" happens. Unless these acts are clearly defined, they are assumed to be extraordinary events with an extremely low likelihood of occurring.  

If used, force majeure clauses shift risk allocation from project contractors to their customers or other contractual stakeholders.

Organizations with projects in regions where force majeure events have taken place should prepare for ongoing conditions. To reduce the potential for conflict and ambiguity, organizations should add more contractual detail and definition to force majeure provisions in existing and new contracts. It eases tension and increases the prospect of sharing the responsibilities of cost and impact from these events.

Project managers can follow these good practices to add detail and definition to force majeure clauses in the following way:

Define what circumstances and events constitute a force majeure.

What constitutes force majeure in my region seems to be open to interpretation. My advice to project professionals is to provide as much clarity to this clause as feasibly possible by listing examples and inclusions.

Depending on the project's nature and location, the list might highlight political unrest, riot, war, invasion, terrorism, civil war, rebellion, revolution or insurrection. Other events could be radiation leaks, nuclear accidents, toxic explosions and natural disasters.

Define what constitutes the end of a force majeure.

A demonstration or strike would have a start and end time, for example. However, this event may have ongoing implications that could disrupt project work. This may include changed work conditions, reduced resource and productivity, or loss of utilities, materials and equipment.

The force majeure clause should detail whether these impacts are the reasons for non-performance and non-liability for damages.

Agree on a formal process in the event of a force majeure.

There should be additions to the clause on:

• Formal notice time
• Method of notification of a force majeure event
• Process for executing mitigation responses
• Agreement on a neutral country where arbitration can be held

Identify risk planning and mitigation responsibilities.

Project managers should identify risks and responses associated with continuing the project work such as:

• Renegotiation of contracts reflecting any changes or cost increases in the market
• Force majeure insurances, associated guarantees and contingency funds
• Clarity on when to reasonably employ mitigation responsibilities, the costs and time period of mitigation efforts, and whether these efforts should be shared or incurred and for how long
• Revision of schedules or extensions for projects with fixed completion dates
• Recovery of agreed costs  
• Eventual termination of the contract

What advice can you give project managers in force majeure situations?

Read more posts from Saira.

In order to survive, project-driven organizations must compete on many levels. Delivering on time, to cost and with quality is always important -- but so is the interaction and customer experience they provide during the project.

Project-driven organizations must consider customer satisfaction as a critical success factor. Organizations that deliver projects that disregard customer needs create negative experiences and ultimately cause huge problems for the organization.

Typically, project teams that fail to capture what the customer actually needs or wants end up getting the product or service wrong. This can happen because:  

1. A project manager blindly follows process and doesn't consider human compassion or understanding. Customer engagement seems like a formality or box-ticking exercise to him or her.
2. Teams are rewarded on task completion and resolved issues -- not on the number of satisfied customers.
3. Projects exist within organizations that don't create opportunities for customers to engage or provide feedback. Therefore, there's no information to improve processes. 
4. There is lack of support and resources to actively engage and respond to customers. This results in poor employee morale and commitment. 
5. Collaboration between teams and departments favoring the customer don't exist. Hence there is no sharing of insights and improvements.
6. The overall culture and attitude within the organization is not customer centric, so there will be gaps in expectation and delivery.
   

I believe project managers and organizations should build in a best-practice approach to fulfil customer expectations.

In my experience, organizations with project management practices that deliver positive experiences are customer-focused and have proactive, sound processes in place. They also have dedicated, responsive teams who are flexible and able to satisfy customer needs.

I believe the following practices can help deliver a positive customer experience:

• Prevent confrontation and problems by balancing your company's customer service expectations with your customers' needs.

• Focus efforts on fulfilling requirements -- but remember to show compassion in the process.

• Bridge gaps between customer requirements and what can actually be delivered through structured communications mechanisms.

• Measure customer satisfaction and gather feedback to continuously improve processes.
• Make "satisfied customers" a measure for success in a project -- in addition to quality, time and budget. 

• Report, communicate and ensure project documents are updated and reflect the truth of the project. 

• Have processes that inform and include the customers when making changes.

• Capture the "voice of the customer." Make these a part of the organization's project management training.

• Develop and use customer engagement models throughout the project life cycle.  This could be in the form of benchmarks and metrics that the customer scores and provides feedback on, for example. Or, contracts could have mutually agreed upon customer satisfaction orientated rewards and penalties.  
  

How do you create customer experiences when delivering your projects? What tools and best practices do you use to engage customers?

See more posts from Saira Karim.
See Taralyn R. Frasqueri-Molina's post on The Benefits of a Change Control Board.

Last week I attended my first formal networking how-to event. I was curious to learn about the differences and similarities between general networking and networking for project success.

What interested me the most was a slide detailing three types of networks: operational, personal and strategic.

In the project environment, networking for operational, personal and strategic goals is a core competency for project managers and team members. In all my training sessions, I always repeat the statement "90 percent of a project management job is communication."

In fact, I go as far as to say networking is a skill that can lead to project success. For example, networking comes in handy in the following areas:

With stakeholders:
On projects we talk to all our internal and external stakeholders on a regular basis. Therefore, we have to network.

We network to acquire and manage resources, vendors and contractors, and also to ascertain and explore risks, strengths and opportunities for the project.

Our personal objectives can be met because well managed, informed and engaged stakeholders equals a happier project manager.

In project communications planning:
Project objectives should be SMART (specific, measurable, achievable, realistic and time bound). Similarly, project-networking activities should be smart too.

Networking activities should:

• Assess the quality of working relationships
• dentify where better relationships are required in order to complete the project
• Develop a wide support network
• Follow up on tasks or commitments
• Build and maintain relationships to get the job done
• Focus and pursue the right networks understand where they fit in and how to communicate with them effectively, know their likes and dislikes and what motivates them.

Within the project team:
Project managers must have networking skills to successfully engage, lead and build the team. These skills will enable the project manager to be a mentor and leader of the team.

Project managers should network with their teams to delegate, collaborate, motivate and ensure they work together.

With interpersonal skills:
Networking can help project managers build self-confidence, and devote time and strategy to build and reciprocate through meaningful networks. Plus, meeting others and finding common ground and mutual areas of benefit and collaboration is always helpful to a project manager.

I can confidently assume that since the history of projects, good project managers have been networking out of necessity or risk project failure.

Certainly in my own case, I have been naturally 'networking' without really knowing that I was doing it. The difference now is that I am more aware.

What do you think is a networking best practice? Is project success dependent on a project manager's networking abilities? What benefits has networking brought to your projects? What role has networking played in your projects?

Project Management Centers of Excellence (PMCOE) are becoming increasingly popular as a solution for organizations to streamline their processes while increasing efficiency, profit and competitiveness.

Generally, a Center Of Excellence (COE) is a business unit that has organization-wide authority. It coordinates continuous improvement initiatives, ensures that value is achieved in all areas, and fulfils the role of organizational thought-leader or consultant.

COEs are also created to capture an organization's best practices, standards and industry benchmarks. The COE facilitates the approval, transfer and integration of these best practices across the organization. For example, in a global manufacturing company, the COE may identify a best practice used in its European plant, tweak it, and implement the practice in its Saudi plant, too.  

There seems to be confusion between the roles of a Project Management Office (PMO) and a PMCOE. Some argue that the PMO sufficiently leads the organization to project management excellence. So, why would an organization with a well-structured PMO need a PMCOE?

In his book, Advanced Project Management: Best Practices on Implementation, Second Edition, project management expert Dr. Harold Kerzner states:

"The definition of project management excellence must extend well beyond experience and success ... Success is measured by having achieved performance that is in the best interest of the whole company, as well as having completed a specific project."

PMOs and COEs are only successful when they achieve the objectives for which they are created. Leaders in the profession note that the number of projects or years an organization has been delivering projects can't define project management excellence. Neither can the methodology it follows.

Larger, complex organizations may need a PMO and a PMCOE -- but their roles should be clearly defined.

A PMO is an important central hub with a mandate to coordinate and deliver all project activities as determined by the organization's needs.

PMCOE executives would operate as part of the business decision-making process. These individuals would report on the organization's project portfolio as a whole and provide the organization with project consultancy.

The PMCOE also supports the PMO through research, innovation and leadership initiatives and bridges the gap between PMO teams and business units within the organization.

What do you think? Are PMO's and COE's the same? Is a PMCOE just a glorified PMO? Have you come across a PMO and PMCOE in the same organization? Is there clear role differentiation?

Recently I came across an ad for a project management technology application. It was a picture of seven robots in a group, which symbolized humans. The slogan read, "If your team looked like this, any PPM solution would work."

It made me wonder how many organizations actually believe that technology applications do the work and produce results -- not humans.

How many organizations and project managers sufficiently analyze their project needs and the compatibility of new technology to their organizations' existing set-up and processes?

Companies often buy expensive project management applications and then force teams to conform and adapt to the application rather than customize the application to the needs of the people and project.

But buying applications because other organizations use them does not by default mean you, too, will become a leader.

Like with best practices, experience has taught me that technology and tools are valuable -- but only if they fill gaps and needs effectively.

Technology is important and can increase efficiency, but in the correct setting and context. Projects are planned and executed by people -- therefore technology must complement and be understood by the humans who use it.

Before investing in new project management applications, you must consider things like training, costs and your team members' willingness to use the tools. Otherwise it could amount to an expensive burden.

What experiences can you share of failing to engage stakeholders before investing in technology?

What factors should be considered before investing in new applications?

Best practices in project management are tried and tested processes collected from experiences and lessons learned. They've been repeated and improved to produce consistent outcomes. They are documented as examples, baselines and measures.

Project managers who favor best practices and processes believe it's unnecessary to "reinvent the wheel." They believe using best practices in projects has many advantages:

1. Project managers have access to tools, techniques, metrics and templates to use on their projects at any time.
2. Best practices provide consistency of expectation, activities and communication for the team.
3. They're generally driven by values and results, and can improve customer confidence.
4. Construction, infrastructure and power projects have best practices as industry norms to standardize quality, safety and other requirements.
   

Not everyone agrees with using best practices, however. Some argue against the blanket use of best practices because, frankly -- times change.

Best practices for projects from 10 to 20 years ago are outdated as technology and real time communications continue to evolve, for instance. More customers are aware of project management, resulting in changed expectations. And definitions of acceptability, constraints and assumptions may differ from the environment where these best practices originated.

I agree that we shouldn't reinvent the wheel. However, I do stress that the wheel should fit properly in order to fulfill its purpose.  

Best practices are excellent if there is cooperation and consistency in an organization from top to bottom. Rigidly imposed processes that are unwanted and misunderstood cause problems and restrict new thinking.

Project managers should use best practices but they should build, fine-tune and improve them to fit an organization. Should best practices become better practices or best-fit practices so they become molded, enhanced and understood by the organization and the people who will benefit from them?

How do you enhance best practices for your projects? Do you think best practices are near perfect? Do you agree or disagree that extra effort should be applied to mold best practices?