Have you ever wondered why many executives don't turn up for your steering committee meeting and those who do are usually on their smartphones?

Chances are that the only information the executives received about your meeting was the agenda and the briefing notes, which focus on the project's status and technical performance. This is abstract data that takes time to read and understand. As a consequence, it becomes paperwork that is put aside to read later, buried under other paperwork and eventually forgotten.

To be successful in attracting the attention of busy executives, focus on a 30-second 'wake-up call' that will cut through the thousands of other messages circulating in your organization and get the executives attention. You cannot communicate unless you get the other person's attention first; so your 'call' must persuade each member of the committee to be both physically and mentally present for your meeting. Only then will your more complex messages be heard and possibly acted upon.

The solution is 'What's In It For Me' (WIFM).

WIFM appeals directly to the attention and decision-making functions of the human brain. The amygdala, a part of the brain, rules much of our actions and behavior.

The amygdala determines in a fraction of a second what we pay attention to. It will pay no attention at all unless it can immediately see WIFM. To cut through each executive's communication overload, your 30-second 'wake-up call' needs to be direct and simple and appeal to the person's emotions. Pleasure and fear are equally effective emotions, so the call should worry the executive--or make him or her feel good. It should not focus on a third party, such as you or your project.

The amygdala is expert at screening everything that doesn't directly interest it, including things that are abstract, complex or about someone else. Uninteresting or confusing messages are rejected in the blink of an eye, before the rational and analytical areas of the brain have a chance to begin the thinking process.

Only after you have gained the executive's attention can you engage with the person and deal with the substance of the meeting. Strong messages start this process, but the real work of the meeting will require the use of more highly crafted forms of communication built around the concept of effectively 'advising upwards.'

Ask yourself: 'Are we getting the attention of those most important to us?' If you are getting attention, are you keeping it and building it? And if you don't know, what can you do to find out?

Many companies only have internal projects, and therefore conduct lessons learned sessions with the same people. But what if you have an external project and you collaborate with team members outside of your organization?  

Should the project manager of the lead organization invite the outside project team to the closing project's lessons learned session?

Here are three tips project managers can use to incorporate external project teams into their lessons learned:

1. Be discreet about company information, but target improvement. Before working on the project, there was likely some type of agreement with regard to proprietary information. This agreement should still be in effect for the lessons learned session. Before you host the lessons learned meeting, talk openly about the processes with the external team to help ensure your discussions are protected.

2. Stay focused on the project. Even during lessons learned sessions for internal project teams, attendees can veer off topic. Try not to argue about which organization was responsible for the mishaps or which company fell short on delivery. Focus on the issues: How can you better prepare project plans with outside parties? How can you review risk and issue lists together? What different criteria should be included in the scorecard that will bring value to monitoring the project and measuring the vendor relationship?

3. Build camaraderie. The two organizations may want to collaborate on a future project or enhancements to this closing project. Prepare questions that will allow the groups to work as one in the future. For example, how did the quality standards benefit evaluating the finished product? If the project relied heavily on documentation, is there any additional information that could be helpful? What communication methods may need to be revisited for the two companies to reach a decision in a timelier manner?
 
If the third-party is holding separate post reviews on the same project, chances are valuable lessons from one group or the other are being missed. It is not uncommon for the lead organization to have an exclusive session in addition to a combined session. Having both groups present can be a favorable collaborative effort toward building vendor management best practices or improving the next project, the future vendor relationship or just a similar project situation.

Does your organization include the external team in its lessons learned sessions?

In September 2011, Project Management Journal published an article comparing similarities between public works management in the Roman era and similar projects today.

The only significant difference that was noted from the last 2,000 years is the proliferation of formal tools and techniques we now use compared to the 'seat of the pants' (or should that be toga?) approach used by Roman managers.

However, in my opinion, the authors, Derek Walker and Christopher Dart could have added a few more differences.

For example, the simpler social structures of the Roman era provided a direct link between project initiator and the manager responsible for the work. For major works, the emperor would frequently be the person directly funding the project. He would also appoint the manager. Another way projects were launched: To enhance his or her prestige, a benefactor funded other projects.

The appointed manager bore personal responsibility for the project's success. Interestingly, he also had to lobby for the unpaid appointment. The manager's prestige and the standing of his family for generations to come could be influenced by success or failure of a significant project.

Most of the actual work was contracted to commercial organizations on similar terms. The contractor was obliged to complete the work for the price agreed upon by both parties. Failure could literally have fatal consequences for the contractor and serious consequences for his descendants.

Probably the most significant difference between the Romans and today's project professionals was the overall commitment to success demonstrated by the Romans. There were direct lines of accountability from the benefactor funding the project to the contractors delivering the work. Everyone's prestige was at stake.

Today, the complexity of modern organizations and multiple competing objectives tends to obscure the link between a project and the organization's overall strategy.

Most project managers are committed to the success of their projects. But this commitment is not necessarily reflected in the higher levels of the organization, as evidenced by the number of articles on 'selling' the benefits of a project to organizational management.  

When there is a clarity of purpose, such as building the London Olympics, remarkable results can still be achieved. Unfortunately, within the matrix structures common in most organizations, in my opinion, one of the real challenges is finding a 21st century way to recapture the Roman's top to bottom commitment to the success of each project.

How do you think this level of stakeholder alignment could be achieved in your organization? 

Many organizations have a vision statement focused on long-term goals. In my experience, project professionals tend to dislike such vague objectives because they lack detail on how the goals should be achieved. This is program or project work: We want to turn a sponsor's idea or goal into actual plans.

But in reality, vision statements in a project or program can be very impactful, as they lend themselves to collaboration among stakeholders.

As an example, let's look at the Buddha Memorial Center in Kaohsiung, Taiwan.
At the heart of this religious center is a relic of the Buddha that avoided destruction when it was snuck out of the country during the 1960s Cultural Revolution. Three decades later, Buddhist monks in India felt the relic should return to Taiwan. For Taiwanese citizens and politicians, as well as Buddhists worldwide, there was a wish to do full justice to the relic and its religion.

Planning for the Buddha Memorial Center began in 1998 when the relic arrived in Taiwan. Construction launched in 2003 and was completed in 2011. During that time, the design for the center changed more than 114 times, growing from 20 to more than 100 hectares (247 acres). Even when construction finished in 2011, the world's largest copper Buddha statue, at 108 meters (354 feet) high, was added to the center in the spring of 2012.

Although it's in every project professional's nature to keep as close to plans as possible, and keep change to a minimum, change management was a key factor to success with the Buddhist Memorial Center project.

The project managers had to be flexible and communicate. Traditional tools and techniques such as 'rolling-wave' and 'fast-track' planning allowed constant change to be embraced.

Program visibility was also important. 'Program visibility' refers to making sure everyone involved is aware of objectives and strategy risks, and that everyone feels involved in the management and its outcome. (Program Management Standard, p14. Doman IV: Stakeholder Management.) In this case, regular meetings were held for all the major stakeholders. The meetings were often open to the public and media, which helped generate even more support.

Meetings are as much about reaching consensus as sharing information. Program visibility also ensures that all stakeholders, from sponsors to workers, share a sense of purpose and commitment.

The lesson learned from building the Buddhist Memorial Center shows how important it is to share your vision for a project or program. Doing so can allow you to create a lasting impact.

How have you made your project or program more visible?

Editor's Note: Photographs taken by Liang Ching Chih.

The purpose of a project or program is to have its deliverables create value. But this value can only be realized if the new process or artifact 'delivered' by the project is actually used to achieve the intended improvements.

Executives have a central role in this process. There is a direct link between the decision to make an investment in a project and the need for the organization to make effective use of the deliverables to generate the intended benefits. In turn, this creates a valuable ROI.

According to PMI's 2012 Pulse of the Profession, in organizations where senior management has at least a moderate understanding of project and program management, 59 percent of the projects successfully meet or exceed the anticipated ROI. This is compared to just 51 percent of the projects in organizations where the senior management has a limited comprehension of project and program management.

This is where a project sponsor comes in.

An effective sponsor is the direct link between the executive and the project or program. The sponsor is crucial to ensuring top-level management support for the project contributes to the project's success and is critical to achieving the ultimate goal of generating an ROI.

According to Pulse, 75 percent of high-performing organizations have active sponsors on 80 percent or more of their projects.

If your project has an effective sponsor, make full use of his or her support. The challenge facing the rest of us is persuading less effective sponsors to improve their level of support.

To impart project knowledge into other areas of the business, the team needs to be able to 'advise upward.' Here are three tips to do so:

1. Create a conversation about value with other project managers and teams within your organization. This is a very different proposition to being simply on time, scope and budget. It's about the ultimate value to the organization created by using the outputs from its projects and programs. The key phrase is "How we can help make our organization better?"

2. Use the right evidence. Benchmarking your organization against its competitors is a good start, as is understanding what high-performing organizations do.
 
3. Link the information you bring into the conversation with the needs of the organization. Show your organization's executive how this can provide direct benefits.

In most parts of the world, organizations need to do more with less to stay competitive. Developing the skills of project sponsors so they are active is one proven way to achieve a significant improvement with minimal cost.

In fact, if projects are supported more effectively, there may be cost savings and increased value at the same time. And what's in it for us as project managers? We have a much-improved working environment. Everyone wins.

Do you have an active sponsor on your project? Do you think active sponsors improve project success? How involved are the executives in your organization?

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

See more on the Pulse of the Profession.


The next time your boss asks you for a number, a deadline date or another fixed value, remember anything you say will be wrong. The reason is 'the flaw of averages.'

Discussed in a book of the same name by Sam L. Savage, the flaw of averages basically explains why everything is behind schedule, beyond budget and below projection.

For example, you're developing two software modules. Both are expected to take between eight and 12 weeks to complete. When both modules are finished, your organization can start a new process, which requires four additional staff.

Your boss asks you for a completion date so the additional people can be brought 'on-board' and the new profitable line of business started. You say, "Eight to 12 weeks," and your boss replies, "Give me a date!" You estimate that a safe date would be 10 weeks, the average of eight and 12 weeks.

Everyone is happy. But should they be? Let's look at the flaw of the average:

Based on your projected date, your boss works out his profit forecast for the next quarter based on an estimated profit of US$1,000 per week. You take the first seven weeks developing the application, and the new team uses the application for the remaining five weeks.

This sounds sensible, but the estimate of US$5,000 profit is the best that can be achieved. If you finish early, there is no upside. The new people will not be available.

If you finish late, however, sales will be lost. The cost of the unproductive new staff will be an added expense until both modules are working. On average, the profits achieved are likely to be significantly less than US$5,000.

Plus, you're more likely to be late than early. The probability of finishing each of the modules in 10 weeks or less is 50 percent.  It's like tossing a coin - there is always a 50 percent chance of it landing on 'heads.'   

Since two modules need to be finished in 10 weeks or less, think of the options when you toss two coins:

Tails + Tails
Tails + Heads
Heads + Tails
Heads + Heads

There is only a one in four chance of you achieving the 'average.' That 25 percent probability means there is a 75 percent probability of being late. Therefore, on average, you can expect to be late.

All you did was assess a reasonable number based on your expected average time to complete each module. The problem is not your estimate, but the way it is being used. This is the flaw of average.

The next time you are asked for a 'number,' use your skills in managing upward to build flexibility into the conversation.

For example, offer your boss a safe date with an option for improvement. "We will definitely be finished in 12 weeks, and there is a possibility of finishing sooner." Point out the cost risks of being early and late. Keep the boss updated as you work through the project.

Or, do some serious analysis. Offer your boss a range of dates with different levels of probability. You need tools for this, but you want a target date with an 80 percent probability of achieving.

Effective stakeholder management needs more than simply complying with a request -- however reasonable it may appear on the surface.

When a relationship with a key stakeholder breaks down, or there is some other failure in your project, it's tempting to assume there is a 'root cause.' We think that by finding and fixing this key factor, the problem will be resolved.

Many tools help find the root cause and these tools work for simple problems. However, they are dangerous to use in complex systems.

The '5-Whys' approach assumes that each presenting symptom has only one sufficient cause. By asking 'why?' five times, you can drill down to the root cause.

For example, say that your boss complains that her computer is not working. You see the plug is out of the wall socket. You replace the plug and solve the problem, right? Well, the answer depends on how you define the problem:

Problem: Lack of power. Solution: Replace the plug.
Problem: Lack of training or knowledge. Solution: Teach your boss about the plug.
Problem: Poor joinery design. Solution: Put the power points on the desktop instead of on the floor.

The '5-Whys' approach requires the right definition of the problem to start digging for a root cause. Even then, the approach only follows one line of thinking, which limits its ability to identify complex interactions.

When considering problems in socio-technical systems, such as stakeholder relationships, the assumption that there is a single event that triggers a chain of events that lead to a problem is false.

Most problems have multiple contributing causes. Each element is necessary but only when all of the elements are combined 'correctly' is there sufficient impetus to create the breakdown. When trying to understand failures in complex systems, like relationships, a different paradigm is useful.

For example, let's say you used a range of motivational techniques to help your team perform that have worked well in the past. This time, however, the team disintegrated, and productivity dropped. Chances are that the problem emerged from a confluence of conditions often associated with the pursuit of success. But in this specific combination, there was "trigger failure;" each item was necessary, but on its own or in a different combination could be more beneficial.

These unexpected outcomes are encountered because complex systems, like relationships in and around a project team, have emergent behaviors, not resultant ones.

Complex causes require subtle management. You need to be continually prepared for nonlinear behaviors where small problems can result in large and cascading failures.

Rather then resolutely applying your standard approaches, look, listen and 'tune-in' to your team. When a complex system reaches the tipping point and collapses into failure, it is too late. You need to feel the issues emerging and adapt to the changing situation.  

How do you detect failures in stakeholder management?

Read more about stakeholder management.

A recent commenter suggested I write a post to help clarify the project sponsor's role.

Your project sponsor is the key link between the project management team and the organization's executive management. An effective sponsor "owns" the project and has the ultimate responsibility for seeing that the intended benefits are realized to create the value forecast in the business case.

A good project sponsor will not interfere in the day-to-day running of the project -- that's the role of the project manager. But, the sponsor should help the project manager facilitate the necessary organizational support needed to make strategic decisions and create a successful project.

With respect to the project, effective sponsors should:

• Create alignment. The sponsor helps keep the project aligned with business and cultural goals.
• Communicate on behalf of the project, particularly with other stakeholder groups in senior management. The sponsor also communicates his or her personal commitment to the project's success on multiple occasions.
• Gain commitment. The sponsor is a key advocate for the project. He or she "walks the talk" and gains commitment from other key stakeholders.
• Arrange resources. The sponsor ensures the project's benefits are fully realized by arranging the resources necessary to initiate and sustain the change within the organization.
• Facilitate problem solving. The sponsor ensures issues escalated from the project are solved effectively at the organizational level. This includes decisions on changes, risks, conflicting objectives and any other issue that is outside of the project manager's designated authority.
• Support the project manager. The sponsor offers mentoring, coaching and leadership when dealing with business and operational matters.
• Build durability. The sponsor ensures that the project's outputs will be sustained by ensuring that people and processes are in place to maintain it once the project completes its handover.

If you have a good sponsor, look after him or her. If your sponsor does not understand the role or is unwilling to fulfill the role, however, you need to speak up. Carrying on without an effective sponsor raises the probability of project failure and you as the project manager will be held accountable for that failing.

It's important to flag the lack of effective sponsorship as a key risk to the project. It may not make you popular, but you have an ethical responsibility to clearly define risks that need management attention.

Ultimately the organization's executive management is responsible for training and appointing effective sponsors. If this has not happened, as project managers, all we can do is help those sponsors who are willing to be helped and flag a risk or issue for those that are missing or unwilling to support "their project."

Read more about project sponsors. 

Who should lead the change challenge: organization management or project management?

The project team probably has a better idea of the technical aspects of the changes required. But, the organization's management initiates the project and has overall responsibility for achieving the intended benefits after the project is complete.

In my opinion, change management is an organizational responsibility. The role of project management is to focus on creating the deliverable effectively and supporting the organizational change effort.  

In short, the project management team works for the organizational change management team. However, I have seen many situations where managing the change is treated as a project responsibility.  

For those project teams undertaking change management, the change challenge is getting the necessary buy-in from organizational stakeholders who have to make effective use of the project's deliverables to get the expected value from the project.  

There is no point in the project team being happy with its work if no one uses it. The way the organization works has to change if the deliverable is going to be used effectively to create value for the organization and generate a ROI on the investment in the project.

Effective communication with the affected stakeholders is a must when addressing the change challenge. These communications follow a fairly standard pattern:

• Explain the reason for the change needs so they are understood.
• Define, communicate and support the actual changes to work practices and behaviors though training or other skills development activities.
• Provide ongoing support to embed the new practices into the operating culture of the organization.

Do you think change management is an organizational or project responsibility? Which option do you think is best for effectively engaging with the affected stakeholders? Which option best facilitates the overall change in behaviors needed to generate a successful project outcome?

See more posts from Lynda.
See more on stakeholder management.

Effective project management governance is becoming an important topic at all levels of many organizations. Project governance focuses on making sure the whole of an organization's project management system is effectively supporting its strategy.

Good governance requires that the governing board sets the strategy and provides direction -- and not become involved in the day-to-day management of the organization. It's up to the organization's managers to implement the strategy and provide the board with the necessary assurances, information and advice needed to support the governance process.

Good governance and optimum performance should be synonymous. And developing an efficient structure to ensure both is a subtle art.

The directors need to ask their executive managers the right questions and the managers need to develop efficient systems that deliver the right answers. Paul A. Samuelson, an American economist said, "Good questions outrank easy answers."

In other words, if you don't ask the right questions, you are unlikely to get the information you need to make good decisions. The governance processes need to focus on the aspects of project delivery that really matter.

Some key questions to ask include:

 - Are we doing the right projects?
 -  Do we have the optimum risk profile?
 -  Do we have the resources and capability to accomplish the selected projects?
 -  Are we properly supporting our project teams to encourage success?

The challenge we face as project professionals is that most directors and senior executives have had limited exposure to effective project management systems. Concepts such as project portfolio management are relatively new and are still evolving. PMI is providing strong leadership in developing these concepts, but I find that execution of the work is largely occurring at operational management levels.

The challenge we face as project management experts is educating our senior executives and directors to ask the right questions in order to help move the organization forward. We must encourage them to invest in developing the ability to effectively manage the organization's project management so the executives and directors can get meaningful answers.

Effective project governance structure provides the optimum environment to allow project and program managers to deliver successful outcomes, so encouraging its development is in everyone's interest.

How can you and your colleagues work to encourage the "right questions" in your organization?

One of the biggest challenges faced by all sectors of the project management profession is persuading senior executives to focus on implementing effective project governance.

Governance is a "top-down" process. Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed.

Effective project management delivers a realistic and achievable outcome efficiently. If the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation from deteriorating further. Failure is guaranteed.

Wishful thinking is not an effective substitute for effective project governance. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not have a miracle process that will magically transform an impossible set of objectives into an achievable set of objectives.

The organization's executives need to balance risks, rewards and capabilities to set realistic objectives and then use effective governance systems to oversee the delivery.

The only way to achieve meaningful change is by communicating to affect a change in the understanding of stakeholders. When senior executives require effective project governance, we can better assist them in establishing effective and robust systems.

If you're lucky enough to work in an organization with effective project governance, broadcast the benefits. If you work in an organization that could improve its governance, use your skills to advise upwards. If your organization is on the road toward effective governance, keep helping it along.  

If we are successful in making effective project governance the normal way organizations operate, the rate of project success will increase, as will the standing of our profession.

What can you do to help create the climate for better governance?   

My mentor in this field -- Julio Matus Nakamura, a project manager -- once told me, "In any organization, there aren't just processes, projects, strategies or tools. What really matters is people."

That lesson, learned long ago, taught me that no matter a person's position, he or she is a human being first. It's very important to build trust among human beings in order to believe in each other. When I realized that, I vowed to establish that type of relationship with my stakeholders -- to build that trust and try to create a more personal relationship with them.

In my opinion, in some cases it's more important to have a good relationship with the sponsor or customer than the results of the project.

I'm not suggesting you forget about your project's results or even the contract. Just that you should put the same emphasis in building a deeper relationship with your key stakeholders as you put in delivering good results and caring about contract issues.

Here are some simple tips that I have used for a while. I hope it may help you when building a relationship with your stakeholders:

1. Use basic manners: Always say hello, goodbye, thanks, please, well done, good job and I'm sorry. These are powerful little words that can make a big difference.

2. Show respect: Often when we are in a conversation with someone, we are not 100 percent in the conversation. You must be present. No excuses. When talking with someone, pay all of your attention to what the person is saying. Avoid thinking about your response when the other party talks; just listen carefully to what's being said.

3. Learn to read body language: We communicate more with our body than with our words. Learn to "listen" to the body of your counterpart and learn to speak with your body. For example, don't cross your arms during a conversation, as this can seem standoffish. Make eye contact during conversation and always face the person to whom you're talking.

4. Share something personal: Find affinities with your stakeholder wherever possible. This could be the university where you studied, the town where you grew up, vacations you've taken, books you've read, or your favorite team and sport. Make sure to find the appropriate moment to share these commonalities.

5. Break the ice: Read the environment around your stakeholder and discover his or her interests. At the first opportunity, bring those interests into the conversation.

What about you? What tools or techniques do you use to build trust with your stakeholders?

The recent Qantas Airways network shutdown was a good example of an industry taking a long-term view of what is best for the industry. Rather than overtly exploiting the problems and passenger discomfort caused by the disruption, Qantas' competitors scheduled additional capacity and cooperated to minimize the overall inconvenience to the flying public.

An obvious consequence to this is that passengers may discover they like the rival airline and keep flying it. But overall, the airline industry worked to minimize the damage to the air travel category. Everyone recognized the collective overall need to keep the flying public flying and returning to repeat the experience.

This win-win approach is a stark contrast to the situation where a competitor's primary aim is to score a short-term win, regardless of the damage caused to the sector. If Qantas' competitors had resorted to negative advertising pointing out how bad the Qantas service was, for example, there would have been damage done to the overall perception of flying.

Now, consider your next argument with one of your project's stakeholders, either internal or external. While your stakeholders may not be competitors, it may benefit you to use the same "win-win" approach.

You have a clear choice: You can work collaboratively to build your project team brand and even enhance the larger project management profession. Or, you can go all out to win -- and if you lose, make sure your competitor can't win.

The latter approach always causes long-term problems.

If the customer loses, the relationship will be damaged and they'll be looking for an opportunity to get even. You also permanently damage your long-term opportunities. If you lose, you're no longer part of the solution. You've effectively negotiated yourself out of a role.

The alternative is a collaborative approach where you seek to build the best outcome with as many of your needs, wants and ideas embedded in the final solution as possible. This collaborative solution will, of course, include some of your stakeholder's wants and ideas, but may result in an overall better outcome for everyone by transforming the problem into a win-win solution.

In this scenario, you may have made some compromises, but you're still in the game and can influence the outcome. The relationship is maintained and you have helped maintained the image of the team and the project management profession.

What do you think? Short-term "wins" may feel good. But if the consequence damages the customer's perception of you and your project, is the short-term gain worth the long-term pain?

Editor's note: The title of this post was changed on 9 December 2011.

Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?

It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.

For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.

When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.

When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.

Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.

Take time as the project manager to set your requirements for running the project. And do so as a high priority.

What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?

Successful projects meet or exceed key stakeholder expectations and requirements. How can this be done when working with the client, sponsor, senior management and users of the project's deliverables?

The need to effectively manage stakeholder expectations is a consistent theme in the PMBOK^® Guide. This goes beyond the simple delivery of specified requirements -- it covers all aspects of a project's work and the manner in which it's accomplished.

The first element is to ensure the project's deliverables will actually meet the requirements of the project. Failure to do so means an unsuccessful project. Take the time to ask the right people the right questions -- after all, they expect your deliverables to work.

The next step in building success is to map the expectations of the key stakeholders. Do you really understand what they expect from the project?  

Accurately mapping expectations requires skillful listening and the ability to decipher what's meant, not just what's said. Don't be afraid to enlist senior management to ask questions on your behalf. As you begin to understand your stakeholders' expectations, they will fall into two groups: realistic and unrealistic.

Realistic expectations still need managing. Make sure you can fulfil them -- then make sure the stakeholder knows you are meeting them. Your communication plan must present the right information to the right stakeholder in the right manner.

Unrealistic expectations are more difficult to manage. They are unlikely to be met, and when you fail to achieve the "impossible," the project will be deemed a failure. Fortunately, expectations are not fixed, but exist in a person's mind and can be influenced or changed.

The key to shifting stakeholders' expectations is to provide new and better information.

Developing a communication strategy that brings the right information to the stakeholder's attention in a believable fashion is a subtle art. This is particularly tricky when advising upward with the goal of changing senior managers' expectations. (I'll write more on this in my next post.)

What challenges have you faced in managing key stakeholders' expectations? How have you found success in managing and meeting those expectations?

See more posts from Lynda.
See more posts on stakeholder management.

Besides scope, time and budget, the core of project management success is stakeholder acceptance of project deliverables. As such, the risk of stakeholders rejecting deliverables should be identified and mitigated in a project's early stages.
 
For example, stakeholders in infrastructural development projects, like members of a surrounding community, make certain choices about project execution, such as location, quality and schedule. But, this doesn't always happen. If residents, say, are denied vehicular access to their homes because of an ongoing road re-construction, it's clear there was no stakeholder representative during the execution planning of the project.

African governments often rely on public private partnerships (PPPs) for utility and infrastructure projects. But most proponents of PPPs settle for a design-bid-build business arrangement, in which a single vendor may win concessionary bids to develop, operate and transfer utility infrastructure schemes. In this instance, a concessionary bid is a solicitation process for PPP projects.
 
This kind of business arrangement increases the risk of eroding the values and interest of that community. Sponsors and vendors could decide to satisfy themselves to the detriment of the residents or other project beneficiaries.
 
One way to mitigate the risk of communities rejecting infrastructure projects could be to use project advocacy consultancies, which are composed of community and government representatives. The committees ensure that infrastructure projects address the needs of the communities and are accepted by them.
 
In Africa, it would be a major stride in project management if stakeholders approved of the deliverables of PPP infrastructure projects. Of course, projects would be more widely accepted if communities were involved during the planning and execution of deliverables.

In my opinion, highly leveraged infrastructure projects that are initiated under concessional business arrangements and executed without the involvement of the would-be users should be discouraged. In turn, profits made by promoters and vendors from infrastructure projects could be better justified vis-à-vis community acceptance of the deliverables.

If communities approve of infrastructure projects, post-project operations and facilities management, it would benefit everyone. Promoters would smile at the projected cash flows, vendors would satisfy both contractual and project obligations, and ultimately, the project would be successfully completed.
 
Do you think involving stakeholders at the outset eliminates project risks? If so, how? What do you think about using a project advocacy consultant?

Read related posts:

"Different Perceptions of Risk on Projects" from Lynda Bourne.

"Use Project Management Tools in the Right Context" from Saira Karim.

The July Project Management Journal includes an interesting paper highlighting two approaches to understanding risk:
 
1. Risks as facts: Risks are treated as objective, technical, neutral events that can be managed based on the knowledge produced by objective analysis using probabilities and expected values. The outcome is rational decision making.

2. Risks as subjective constructions with multiple dimensions: Risk managers choose the context and perspective they adopt. This allows multiple rationalities to coexist, depending on the values and perspectives of the observers. (This explains why some people find jumping out of an aircraft fun.)

From a project perspective, risks are uncertainties that matter. All estimates about future project outcomes incorporate a degree of uncertainty. This includes the three key dimensions of project management: timing, cost and quality of future project deliverables.
 
The project manager cannot be certain that the estimates that make up the project schedule or cost plan will prove to be correct, or that the project team will create deliverables to the appropriate quality standards. The rational management approach is to assess the risk factors and develop appropriate time and cost contingencies, backed by appropriate reviews and tests to ensure optimum quality. This approach is highly objective and rational.

However, you cannot rely on your stakeholders having the same view as you. If a stakeholder sees your project in a different context, their perspective on risk will be different.
 
For example, if you created a contingency plan using a Monte Carlo analysis, an executive may interpret the plan as a sign you don't understand the project because he or she expects a single definitive result. From this stakeholder's perspective, the precise calculation of a critical path method schedule offers certainty and minimum risk.

The authors of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) have a different perspective, which understands the benefits of 'three-point estimating.' You cannot assume your stakeholder will have the same view.
 
The challenge is to accept that a range of stakeholder perspectives will occur. Stakeholders may derive completely different opinions from the same data.
 
You should anticipate this possibility and adjust the way you package your project information to communicate more effectively and ensure both you and your key stakeholders have a common understanding of the risks and issues confronting you project.

How do you deal with the challenge of managing different stakeholder perspectives on risk?

Read more on risk management.
Read more on stakeholder management.

How do you change a stubborn senior manager's mind? For example, he or she might claim your project only needs six weeks to complete, even though you have a carefully researched and resource-loaded schedule that proves 10 weeks is needed.

Arguing won't work. In fact, given the power structure, arguing will simply put you in a worse position. Doing nothing simply delays the problem and you will eventually be held accountable for your perceived failure to meet the stakeholder's unrealistic expectations.

To change a senior manager's mind, you need to change the manager's expectations. Though you may battle a heavy overlay of skepticism, use of effective communication and a planned strategy should do the trick.

Effective communication requires that at least two of the following three elements be present:

•    You're known as a technical expert.
•    You're credible: People know you provide reliable and accurate information.
•    The information you're communicating is relevant to the receiver.

Influencing a skeptical senior manager requires you to boost all three facets. You cannot do this alone. Some options to consider include:

Co-present your case with a trusted source. You increase your chances of success by sharing the stage with someone the executive trusts. Build the value of your ideas on the credibility the co-presenter has established with the executive.

Demonstrate endorsements to build power. Ask others in positions of power to let the executive know they support your idea.

Stroke egos and use the executive's credibility. Authentically move ownership of "the" idea -- not "your" idea -- into his space. You can do this by using phrases such as "You've probably seen this data already," or "I'm sure your analysis has shown similar results."

These approaches need organizing and take time but are essential if you are going to effectively advise upward.  

How do you influence your senior managers?

Read more on stakeholder management.

Have you ever wondered why communication with senior stakeholders so often breaks down? It's because of the deeply embedded cognitive biases innate to all of us.

Research by behavioral economists has demonstrated people are naturally irrational. The challenge is to accept people as they are and then work rationally within our innate biases.

When your project has an issue that has already caused a cost overrun and needs more expenditure in the short term to potentially recover some of the losses later, you and your stakeholders may experience a bias called loss aversion. Most people will make risky decisions to avoid a loss, but are reluctant to make a decision of exactly equal to achieve an exactly equal gain. And most people also tend to prefer short-term gratification to long-term benefits.

Therefore our natural instinct is a strong bias towards not losing more money -- even if the short-term loss is significantly outweighed by a longer-term gain. The best antidote is a credible communication process that outlines the issues and risks, supported with additional reference materials such as the PMBOK^® Guide.

Proximity bias is to prefer our own creations to other people's creations. This tendency is reinforced by what behavioral economists call the "IKEA Effect." The more labor we expend on a project, the more we love the result -- regardless of its quality.
 
Before your manager expends too much effort on her own solution the problem, you should communicate in a way that allows a jointly crafted solution to develop.

When communicating with senior stakeholders, try to help them resist these biases while working to avoid them yourself. Rather than provide your solution, offer a range of ideas that allows stakeholders to own the solution (with your help). Aim to shift their thinking to a viable benefits-focused solution.
 
How do you cope with biases among stakeholders?

Read more from Lynda.

Read more on stakeholder management.

The purpose of communicating with any stakeholder is to build his or her understanding of a project. But there is a huge gap between looking at a written message and understanding its contents.

The PMBOK^® Guide differentiates between the:

•    Message -- what you want to communicate
•    Medium -- the way you send the message and
•    Noise -- things that interfere with comprehension.

The concept of noise disrupting communication is easy to appreciate when you are talking with a stakeholder, either face-to-face or on the phone. But what many project managers fail to realize is that the same principles apply to written communication.

A significant body of research suggests a well-designed document can communicate up to 80 percent more information to your stakeholder than one that is poorly designed.

Consider these elements when designing your next project document:

Page layout: In most cases, the eye starts naturally at the top left of a page and flows down to the bottom right. Ignoring this flow disrupts the natural reading pattern and reduces comprehension.  

Clutter: Multiple fonts, font sizes and colors may create a great visual impression but fail the communication test. The best combination for text color is a black font on white background.

I find that serif fonts, like Times New Roman, are easiest to read in the body of a document. Sans serif fonts like Ariel look cleaner in headlines. Use one of each with minimal embellishment to reduce noise.

Page design: Leave plenty of white space at the margins, between paragraphs and around images. Place key messages in headlines, use diagrams wisely and caption them effectively.

Designing an effective document layout is an art -- you need to balance creating an attractive document with making the information inside easy to read and understand.

Do you think document design can impact your project's communications with your stakeholders? Why or why not? Tell us about your experience.

Read more posts from Lynda.

Read more posts about project communications.

A couple of small projects happening in my neighborhood of South Melbourne, Australia have me wondering about the value of many of the trappings and rituals we use in our projects. Do they contribute value to the stakeholder community or not?

One project involved resurfacing a small section of road. The crew turned up with their trucks and road-making equipment, finished the job and left. For the two days needed to complete the job, the workers brought their own lunches or went to a local café.

On the next corner, a production company was doing a shoot for a segment of a TV cop show. They spent a day setting up tents, canteens and support vehicles. They brought a cast of hundreds, including security and canteen staff. Over two days, the cast and crew rehearsed and shot the segment.

The difference between the two worksites had far more to do with ritual-based traditions and stakeholder expectations than actual needs. The facilities provided for road crew were lean. By comparison, the facilities provided for the TV crew were luxurious but possibly necessary to attract the right "talent."

Rituals can certainly be very powerful ways to build identity and cohesiveness in a team. Many rituals, however, may have simply become time-consuming habits.

A good example is the monthly executive review of all projects that has never resulted in a single canceled a project. Another is the Thursday morning team meeting that is called for no other reason than because it's Thursday.

Take a look at the rituals associated with your projects and ask how many of the meetings and processes add real value to the stakeholders involved.

How many should be refined, redefined or altogether abandoned?

What are the most valuable rituals for you and your stakeholders?

See more posts from Lynda Bourne.

See more posts on project teams.

Arguing with your stakeholders is never good.

The basis of an argument is to defend your position while defeating the other person's in the process. It's easy to suggest using active listening to understand the other person's viewpoint, but this advice overlooks the inevitable build up of emotions inherent in any argument.

Asking the help of a third party to mediate an argument with a stakeholder can be very useful. First, the presence of an observer helps contain excessive emotions. Secondly, a third-party observer can bring fresh insights to help move the argument to a constructive discussion and, ultimately, a solution.

Transitioning from a sides-based argument to an "us"-based solution does not require the third-party observer to necessarily solve the problem. Rather, the mediator should help those arguing to develop a solution.

An ancient legend demonstrates this concept beautifully:

The point of the story, from a project management perspective, is that belaboring arguments with stakeholders will only succeed in delaying the project. For the sake of keeping the project within the triple constraints, it's best to resolve arguments promptly and for the good of the project.

In your projects, how have you handled arguments? Do you seek help before positions become entrenched?

We talk a lot about stakeholders. But we often forget that people who actually do the work within an organization's project portfolio and programs are stakeholders, too. And if they're to be effectively supported and motivated to help the organization's project delivery system succeed, you must recognize their needs and aspirations.

Here are four broad stakeholder groups that every organization should be paying attention to:

Team members: There should be clear direction and support to help project team members accomplish their work and earn the opportunity to grow into a leadership role.

Project manager: Success for project managers lies in planning and managing the overall project he or she is responsible for. Organizations can foster their success by providing a supportive environment with effective governance and access to project management skills development.

Program managers or project directors: This is a role focused on achieving organizational objectives through the work of other managers. Successful program managers will deliver organizational change and benefits that correlate with stakeholder and sponsor needs and expectations. Organizational support for these senior roles should focus on creating an environment where the managers can create value for the organization.

Portfolio management and project management offices (PMOs) support organizational governance structures. These management roles are focused on providing strategic advice to the executive. Portfolio managers assess current and planned projects and programs on a routine basis to recommend the optimum mix for future resourcing.  

The PMO manager provides input to the portfolio management process based on the performance of current projects. Additionally, he or she provides input to the organization's overall governance structure.

Success in the roles of portfolio and PMO managers is being a 'trusted advisor' to the executives in the organization. From an organizational perspective, effective stakeholder management focuses on supporting the managers and helping them support the business.

Recognizing the needs and aspirations of each of these groups of stakeholders is important if they are to be effectively motivated and supported so they can help the organization be successful.

Do you feel these brief descriptions fit the roles in your organization?

Do you consider members of project delivery teams as stakeholders?

When you deliver a message to a stakeholder, the impact that it has on him or her can vary depending on the individual. The same person can react quite differently to similar messages at different times.

For example, let's say you need to advise two senior managers about a US$50,000 reversal in an expected project outcome. One manager had no idea there was a problem in the first place. The other manager heard through the grapevine that your project was facing a US$500,000 reversal.

For the manager who thought that everything was OK, US$50,000 is bad news. But since the other manager's perception was that a major disaster was looming, US$50,000 seems like good news.

There are several factors at play in this situation. One is certain peoples' perception of the work you are doing. The perception may be unrealistic, but it's real to the person holding it.

Where your message falls in the stream of information the person is dealing with also plays a role. If yours is the one bit of good news in a bad day, for instance, you may get a much warmer response than if your bit of good news is swamped by other spectacular events in other parts of the business.

The challenge of communicating with stakeholders is not knowing the perceptions they currently hold of you and your project. You also have no control over the other news he or she receives in a given day. The only solution is to listen carefully to the feedback from the stakeholder. Then try to put your message and the feedback in context and adjust accordingly.

It helps if you are in regular two-way communication with your key stakeholders and if you are tapped into their grapevine as well. By being connected you will be able to understand a little of the "ambient temperature." You can adjust the way you communicate and the timing of the communication to increase the chance of a successful outcome. Then expect the unexpected.

How much time do you spend thinking about the impact of key communications? What are some of the ways you've found success in communicating with stakeholders?

Web 2.0 is changing the way stakeholders interact and work together within the project team and in the wider community around the project and the organization. Social networking, instant messaging and collaboration tools are overwhelming traditional organization charts, hierarchies and management structures.

Here are a few examples of how things might change:

Building and maintaining relationships will change. People add their uniquely human value in non-routine processes and creativity and organizations will increasingly use automation or "self-service" systems for the majority of routine activities. There will need to be a balance between pure efficiency (which is often appreciated) and developing meaningful relationships with stakeholders through human interaction.

Weak links and extended networks let people pick up information from people who know the people they know. Project managers will need to learn to navigate their personal, professional and social networks to exploit these strong and weak links for the benefit of their project.

Work swarming is characterized by a flurry of collective activity by anyone available and able to add value. Using weak links, swarms form quickly, attack a problem or opportunity, and then dissipate. The phenomenon is powerful but not controllable in any traditional sense.

Informal groups outside the direct control of the organization often use social media to impact the success or failure of a project. Smart project managers will learn how to live in a social environment they can only partially influence.

Virtual environments will become the workplace. People will interact with each other and the virtual environment to reshape the world they're looking at through simulation and experimentation.

The challenge facing organizations and project managers is adapting to this environment to obtain the potential benefits for the project, the team and the organization. They must simultaneously maintain appropriate levels of governance and remain focused on the project objectives.

Individuals will also need support to manage the complexity created by overlapping demands. Forcing individuals to operate in an over-stimulated state will be detrimental to the person and their performance on the project team.

How is Web 2.0 affecting your stakeholder management?

One group of stakeholders whose input is critical to most projects are experts -- subject matter experts, risk experts, quality experts. Project managers must know how to make effective use of these experts' knowledge.

The advantage of using an expert is of course his or her depth of knowledge. But not all experts are created equal and too many people simply accept an expert's views as a profound truth. Project managers may misunderstand the expert's area of expertise, for example. Or they fail to grasp the danger of 'group think,' which is a version of common sense held by a particular group of experts.

Instead, project managers need to be more engaged and understand the basis of the expert's opinion. What makes sense to the expert may not make sense to you or may not be the optimum solution to your problem.

One technique you can use to make sure the expertise is useful and applied effectively is asking the expert to explain his or her ideas in simple language. Then dig into the assumptions, evidence and methodology used to reach his or her opinion.

It also helps if you can make space for managed dissent. Allowing divergent views opens up alternatives that may allow new insights into the problem. By combining different ideas with more traditional tactics, you're likely to generate a wider range of options. And that often leads to a better solution than simply accepting a single expert opinion.

Experts confident in their knowledge are unlikely to be challenged by this approach. Instead, they will use the opportunity to learn new things and enhance their expertise.
 
How do you make use of an expert stakeholder's knowledge? 

One of the key roles of a successful project manager is to provide effective leadership to a range of stakeholders, including the project team, suppliers and contractors. But leadership is not as simple as having a position in the organization chart and managing processes.

Pragmatic leadership is a choice you make to influence other people's thinking to act in the interests of the project and the organization. Pragmatic leadership adds the power of directed motivation and a commitment to success that significantly improves routine operations within the project and becomes essential when problems are encountered.

It's a balance between managing and leading. Management skills and technical knowledge are important in determining the appropriate work, but leadership generates the motivation that translates into willingness to do the work.

The art of leadership in project management is developing commitment from your stakeholders -- making the successful completion of your project important to each individual. This needs more than effective management processes.

Effective management defines schedules, work assignments and performance criteria. It's about compliance and procedures to ensure quality, safety and other key requirements are met. Management is largely taught and focuses on process skills.

Leadership is about creating commitment to the work. A great leader understands the task and inspires the team. Leadership is a more complex process derived from combinations of self-esteem, confidence, credibility, the ability to communicate clearly and a willingness to listen and engage with people.

Leadership skills can be learned, but they have to be based within a leader's inherent personal characteristics to be authentic.  

Leadership adds the power of directed motivation and a commitment to success that significantly improves routine operations within the project and becomes essential when problems are encountered. The bigger the disaster, the more important it becomes to have a committed team-- to survive a major setback, each individual needs to be willing to do what's necessary.

How do you see your pragmatic leadership skills developing?

Rewarding good performance helps keep employee stakeholders motivated during projects. But there's a difference between the methods many businesses use to motivate people and what actually works.

Simple financial incentives and other "carrot and stick" methods have been shown to be largely ineffective motivators, especially for employees on your team. And these incentives can be totally inappropriate if applied to stakeholders outside of the organization.

Instead, rewards should address our deep need for:

Autonomy: The desire to direct our own lives
Mastery: The urge to get better at our work and be successful
Purpose: The yearning to work in the service of something larger than ourselves

Rewards don't need to be huge, but they should be visible to the entire team. They can be as simple as acknowledging a job well done in a daily stand-up meeting. Or it can be more substantive, such as granting greater autonomy or responsibility.

As a leader, you must allow employee stakeholders the freedom to define their work within appropriate boundaries. Provide opportunities for them to develop new skills and link your team's work to the objectives of the organization or a larger social benefit, where possible.

So where can you start?

Rather than instructing the team member receiving the award on what to do and when to finish, offer a little bounded autonomy by asking how he or she can best achieve the objective of the task and how quickly it can be accomplished.

If the stakeholder is a senior manager, create a sense of purpose by linking your request for help to the manager's goals for the organization. You may be surprised at the positive reaction.

What do you think? Can autonomy, mastery and purpose be motivational rewards?

People in elevators fall into two broad groups: One group walks into the car, pushes the button and waits for the control system to do its job. The second group has what I call Advanced Button Pushing Syndrome (ABPS). They believe that the more they push the buttons, the faster the elevator will move.

Of course, second and subsequent button pushes add no value at all, but when an elevator arrives after someone pushed the button six times, they truly believe it made a difference. Some people need to feel in control, even if they aren't.

ABPS can be found in the workplace, too.

When a project is running behind schedule or over budget, it's the equivalent of a slow responding elevator.

Project managers with ABPS may demand additional meetings or more frequent reports from the project team. Time and money could be better spent working on the project deliverables, but these resources are diverted to placate the manager's need for control --to the detriment of the project.  

Unfortunately, when the project is eventually delivered, the project manager believes all of the extra reports and meetings helped achieve the outcome. But correlation is not the same as causation. Unfortunately, there is no easy way of measuring how much sooner the project would have finished if the resources had not been diverted by the manager's ABPS.

This isn't a clear-cut situation. It's easy to go from requesting useful information that will help inform decisions to a situation where the requested reports and meetings are actually counterproductive.

The next time you are considering requesting more reports or extra meetings, think about ABPS. Will the diversion from the project's work be constructive or detrimental?

Do you know of project managers who suffer from ABPS in the workplace? How did it affect the project outcome?

In my last post, I asked what you would do as a project manager if, hypothetically, two key team members could no longer work together after ending their romantic relationship.

Some suggested avoiding the issue, but while that may buy you some time, it doesn't get to the root cause.

Others suggested confronting the problem. Using a proactive problem-solving approach reframes the issues, engages others in the solution and creates opportunities for an all-around positive outcome. Yet unfortunately some conflicts are virtually unsolvable and an important part of a problem solver's role is to recognize this.

I can't tell you what to do, but I can suggest how to handle this. Most dilemmas involve deciding which is the least damaging of the alternatives. But the nasty thing with dilemmas is that making no decision is almost always worse than the most terrible outcome from any of the other options. You have to decide something to minimize the overall damage.

So first, make a call and then seek support of your decision from your senior managers. When you're "advising upward," you must succinctly lay out the facts, your interpretation of the facts and the steps leading to the decision. Then your managers can make an informed decision to support you or to suggest alternatives.

After gaining the necessary support, you have to implement the decision. It will be unpleasant and stressful, but such is the nature of the situation. As an ethical leader, you need to take responsibility for the bad and the good in your project.  

If you handle a situation like this decisively, but also with empathy and consideration for others, you'll find your team's respect and support for you as a leader will be enhanced.