Voices on Project Management

> Back to Voices Home

More posts in Stakeholder

Problems, Conflicts and Decisions

| | Comments (0)

While frequently treated as separate topics, conflict management, problem-solving and decision-making are interrelated and all are focused on achieving the best possible outcome.

In an ideal world, there would always be sufficient information and rational maturity to allow you to treat everything as a problem and apply the following problem-solving steps to reach the optimum solution:

  1. Investigate the problem.
  2. Define the problem; the way it is defined will influence the solution.
  3. Identify the root cause.
  4. Define the "solution space" -- the potential range of acceptable methods and solutions the options have to conform to.
  5. Generate options. This can include: group creative processes such as brainstorming, negotiation between parties, facilitated processes, and reflection and other individual processes.
  6. Decide on the solution that solves the root cause in the simplest way. 
  7. Implement the solution effectively.
  8. Review the implementation.

The trouble with this process is that problem-solving assumes there is a best answer -- that the information needed to determine the answer is available and that the people involved in the process are acting rationally. These circumstances are relatively rare!

Many of the problems that require solving are rooted in emotions. At its center, every conflict has people acting (or reacting) emotionally, and conflict management is focused on reducing the effect of emotions to allow the people in conflict to start acting rationally. Any effective solution to a conflict involves defining the problem, defining a solution space (e.g., a formal mediation), understanding the options, choosing a solution and then implementing the solution. The only difference is how these steps are implemented or imposed. The standard solution options are:

  • Forcing/Directing: The solution is imposed by a manager with adequate power or a tribunal (i.e., a judge, arbitrator or adjudicator).
  • Smoothing/Accommodating: Emphasizes agreement, minimizes the issues in dispute and allows time for emotions to cool and any residual issues to be resolved through a rational decision-making process.
  • Compromising/Reconciling: Both sides give something up to resolve the problem. Option generation is limited by the level of conflict.
  • Problem-solving/Collaborating: Also referred to as "confronting." A joint approach to the problem -- collaborative decision-making -- is used to find a mutually acceptable solution (that is, a win-win).
  • Withdrawing/Avoiding/Accepting: Allows time for emotions to cool but may not resolve the issue.
Different conflict-management processes are appropriate at different times. The primary focus is on reducing or managing the level of conflict, but eventually someone has to decide on the solution to the underlying problems.

Problem-solving and decision-making are also closely aligned. But the weakness of the problem-solving concept is the assumption that there is sufficient data to make the "right decision." Unfortunately, many decisions are not that simple!

The types of decisions you will be required to make range from "simple problems" through to "wicked problems":

  • Wicked problems are those that keep changing and involve the stakeholder's emotions and complexity. You can never really define the problem that needs a decision but still have to decide something. And every decision changes the problem -- an iterative, one-step-at-a-time approach is usually best.
  • Dilemmas have no right answer. You have to use your intuition and choose the lesser of two evils. Not making a decision is almost always worse than either of the options.
  • Conundrums are intricate and difficult questions that only have a conjectural answer.
  • Puzzles and mysteries lack adequate information to resolve, requiring your best decision based on the assessed probabilities at the given time. You almost never have enough time to get all of the information and skills you need to reduce these decisions to simple problems, but you can use processes to a point.
  • Problems just require hard work and the application of the problem-solving process described above to get to the best decision.
The challenge of decision-making is to understand and balance the following:

  • The characteristics of the problem you have to make a decision about
  • The levels of emotion and conflict in the people affected by the decision
  • The characteristics of the different types of decisions you will have to make
The last step is to have the courage to make the best decision you can, in the circumstances as you understand them at that point in time. 
Ultimately, good decision-making is firstly getting most decisions reasonably correct (luck plays a part) and then continually reviewing the consequences of your decisions to adapt, adjust and correct the suboptimal ones as quickly as possible. Generally, any considered decision made in the appropriate time frame is better than no decision or an unnecessarily delayed one.

How do you make your decisions when confronted with a problem?

From Lab to Hospital, More Lessons Learned

| | Comments (0)
Voices_Vivek_Customer Service 2.png

In my last post, I discussed my experience at the lab and insurance desk at a hospital. Now I'd like to share the remainder of the story and my analysis on the lessons learned from the hospital stay. 

A nurse on my first evening in the hospital asked me to sign some papers. As I read the papers, there was a note that said I should not sign if the paperwork was not explained to my satisfaction. I looked at the nurse and said, "No one has explained anything to me. How can I sign?" The nurse looked at me and asked me to hold on for a moment. After some time, a doctor came, explained the process and situations that could arise during the operation. I asked some more questions that he answered, and I signed the papers. 

Thursday morning, the operation was completed successfully, with follow-up visits by the doctor and nurse. On Friday, the process continued. A group of three senior staffers came in the room, introducing themselves as administrators, and asked if the air conditioning, food and other services were okay. In the evening, the doctor visited again and told me all was well and he would discharge me the following day. He said he would start the process in the morning and requested my patience as the billing and insurance-approval process might take many hours, even perhaps the whole day.

On Saturday morning, the administration staff visited again and asked if all was well. At noon, the staff took my signature on the bill and asked me to wait for approval. I sat around and inquired about the approval few times, but no luck. I finally got approval by 7 p.m. -- but by that point I had had dinner at the hospital and afterward moved to my house. 


My experience at the lab and at the hospital were quite opposite. At the lab, the work at hand was minor, but it escalated. However, at the hospital the work at hand was greater and there were more opportunities for issues to arise, yet all went well. I think it was the hospital's well-defined process and disciplined execution that allowed for a smooth experience.

Takeaway 1: Words Have No Meaning, Only Action Works

At the lab, the manager was trying to defuse a situation by promising and explaining, but actions were missing, and therefore the matter became heated. At the hospital, when I was asked to sign papers without explanation, I raised the concern -- and the nurse and doctor both handled it well by doing what was expected without uttering a single word to the contrary. 

Takeaway 2: Keep the Ego Under Control

The manager at the lab appeared to possess a big ego. First, he did not accept the problem; moreover, he defended his and his team's actions. Second, as he was also a doctor, he could have collected the blood himself but chose not to, perhaps because it wasn't in his job description. He missed the opportunity to win over customers and set an example for his staff. 

Takeaway 3: Set Expectations

If the hospital staff had not set expectations that it would take two hours for approval on the estimated cost and a whole day for approval on the final bill, I would have waited impatiently and probably fought with the staff over the delays. But setting expectations in advance helped them control customer reactions and achieve satisfaction.

Takeaway 4: Have a Process, Maintain Discipline and Re-evaluate

The most interesting thing I found is that the administration staff visited my room twice and personally asked if all was going well. They were monitoring that discipline was being maintained and if anything in the process needed to be fixed. I think this was critical in ensuring foolproof processes and disciplined staff. 

What's the top customer service lesson you've learned from an unlikely source?

Eliminate the Fear Factor

| | Comments (2)
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and most modern management texts emphasize leadership and motivation over directive control. 

Yet if employee surveys are to be believed, around 70 percent of managers still operate in command-and-control mode. These managers rely on authority, discipline and fear to drive performance. And their team's commitment to the organization and performance suffer accordingly. 

It's simply futile to tell people they must come up with a bright idea within the next 30 minutes or sanctions will be applied! Fear damages creativity and destroys openness; frightened people cannot work effectively in a knowledge economy.

If people are scared of being blamed, the last thing they'll do is pass on accurate information about an issue or a problem. And effective management decision-making depends on the open transmission of bad news. Project controls staff must know what's really happening and need honest estimates of future consequences to provide planning advice.

To understand how serious this problem can be, consider that one of the causes of the up to ₤425 million loss so far on the ₤2.4 billion U.K. Universal Credit program -- ultimately credited to "weak management, ineffective control and poor governance" -- was that no one in the development team felt able to highlight their problems to senior management. Fear of being blamed kept the knowledge of the problem from the people who needed to know. 

Trusting and empowering your team, open communication, leadership and motivation are all closely interlinked and in combination create high-performance teams. 

This is not a new concept. At the beginning of the 19th century, the Prussian military developed auftragstaktik (or mission command) under the core tenet of bounded initiative. The leader's role is to clearly outline his/her intentions and rationale. Assuming people have proper training and the organizational culture is strong, subordinates can then formulate their own plan of action based on their understanding of the actual situation. 

What do these ideas mean for project managers?

  • Move from a position of telling to asking. 
  • Work to build open and trusting communication; don't blame.
  • Instead of using control tools such as schedules as a target to measure, use them as a means to collaborate.
  • Be prepared to forgive mistakes -- encouraging creativity always has the possibility of the idea not working.
How do you eliminate the "fear factor" from within your team? 

Customer Service Lessons -- From a Hospital?

| | Comments (4)

Recently, my doctor advised me to go in for a minor surgery, so I had the opportunity to visit a clinical lab and stay at the hospital for three days -- an unlikely place to learn some customer service lessons. 

Before the surgery, I had to undergo blood tests. There was only one attendant at the blood collection center and a long queue. A woman at the back began complaining about the queue until a nurse came out, took that woman to a room and drew her blood sample. This upset others in line and led to more complaining. The manager came out from his office and asked people to calm down. But after time passed with the queue remaining as long and the manager offering another assurance, people became agitated again. This time, the manager told some people they were unnecessarily raising their voices while he was trying his best. This continued until another staff member (possibly late to his shift) came in.

This experience made me think: Do mere assurances work all the time? Don't we need to apologize for unfair treatment and take action to correct the wrongdoing? Perhaps our egos do not allow us to do all this. So what does it take to control our ego?

After finally getting my test, I scheduled the surgery. The hospital suggested I come in beforehand to complete the formalities of cost estimation and approval from my insurance (a procedure in India for cashless treatment at a hospital). 

When I arrived at the hospital's insurance counter, the attendant in charge took me to a room, asked me to fill out a form and told me that a few people are involved in the process, so it might take up to two hours. I filled out the form in a couple of minutes and waited for 30 minutes for a doctor to appear. He asked me a couple of questions, filled out the remaining form and gave it to the attendant. She asked me to wait for another half hour while she conducted some office formalities. Half an hour passed and I became restless. I approached the woman, and she promptly explained, "I said it would take around two hours. Hold on for some more time." After half an hour, she appeared, took my signature on a form and asked me to leave. 

My experience at the insurance desk taught me a simple lesson. If I don't set expectations (as the attendant did), a customer is free to expect anything based on his or her own experience. For better customer service and satisfaction, it is important to set expectations at the beginning and then exceed those expectations.

In my next post, I'll discuss the lessons I learned from my hospital stay, and how those could be applied to project management. What customer service lessons have you learned when you least expected it, and how have you applied them in your projects?

Fight or Flight?

| | Comments (0)
Most points of difference can be resolved through negotiation, discussion or input from a third party. But other times, circumstances quickly descend into acrimony.

Bear in mind when a "fight" breaks out, it's always personal and emotional. If you can remove those two elements, all that remains is a difference or disagreement that can be resolved. 

Unfortunately, emotions kick in quick and are far more powerful than rational thought. Fight or flight is one of the most basic of survival strategies. As soon as a trigger matching the learned pattern of a perceived threat is sensed, the fight reaction cuts in. Some time later -- a few seconds or a few hours later -- rational thought may override the need to fight, but it always lags the instantaneous emotional reaction. 

The easiest of the conflicts to manage is where a stereotype is involved. You simply have to distinguish the specific person from the overall stereotype. For example, if a team member has an issue with the project management office (PMO), you can say: "Yes, everyone from the PMO is an interfering bureaucrat focused on wasting time by gathering excessive detail. But Mary from the PMO is different; she's really a 'project manager' and can make your job easy." In this scenario, you simply highlight Mary's positives and distance her from the PMO stereotype. 

When the fight response is more personal, you should still try to remove the emotion, but your task is much harder. Remember, emotions are instinctive, and factors such as fatigue, stress and emotional events can all shift the balance of power toward the fight instinct. 

Taking time out to cool down allows rational thinking to seep in, provided the emotions aren't triggered again as soon as the other person returns. This process can be encouraged by diversionary tactics, such as changing the focus or place of discussion, or doing something completely different. It's a good time to go down to the pub...

Mediators use a number of tactics to start a rational negotiation. One is to encourage each of the parties to let it all out and vent their anger in a controlled environment. Once a person has done this, it's very difficult to maintain the rage. Another is to hold one-on-one discussions and carry messages back and forth between the parties. This removes the trigger for fighting and allows messages to be heard. If there's any common ground, rational debate can start and, with luck and good management, continue once the parties are face to face.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) advocates keeping disagreements professional and based on rational discussions of information. While this is desirable, we're all people with emotions and sometimes those emotions will take over. A good manager recognizes this and allows time for emotions to settle before using more proactive negotiating tactics to bring rational debate back into play. 

How do you deal with conflict?

Stakeholder Victory, Without Battle

| | Comments (0)
Chinese military general Sun Tzu wrote The Art of War nearly 2,500 years ago. But his ideas still hold value on the art of stakeholder engagement. After all he did say: "The greatest victory is that which requires no battle," which should be the ultimate aim of every stakeholder engagement process.

One of the clearest messages from The Art of War is the supremacy of strategy over tactics and tactics over reaction. Yet project teams spend most of their time reacting to stakeholders with a few tactical activities, such as report distribution and progress meetings. This approach gives the initiative to the stakeholders. And, as we all know, not every stakeholder has the project's best interests at heart, and those who are supportive rarely have a deep understanding of your project's real needs.

Sun Tzu states that success is driven by strategy: "All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." Planning your stakeholder engagement should involve far more than simply deciding who needs what information.

The starting point for a good strategy is good intelligence. "If you know the enemy and know yourself, you need not fear the results of a hundred battles." Project practitioners and their teams need to understand who's important and why; what their attitude to the work is (and why); what you need from them (if anything); and what those people want from you.

After this analysis, key questions for the team include: 
  • How reliable is our information?
  • What changes do we need to create in the stakeholder community?
  • Where are the risks and threats within the community?
  • How can we make the changes we need?
  • How can we minimize any opposition and damage? 
Now you're in a position to develop a pragmatic strategy to proactively engage with your stakeholder community, focusing on those people who matter. But beware: "Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." You and your team need to first understand your strategic intent and then develop appropriate tactics to implement the strategy. 

You could, for example, produce the standard monthly report containing data on your project's environmental protection activities. Or, if you know that several senior stakeholders you need as allies are concerned about your organization's reputation, you could highlight the team's successful environmental efforts with a photo on the cover. No senior manager ever reads a report (particularly all of the boring data on environmental monitoring in the appendix). But they can't miss a cover photo -- or how you're helping them achieve one of their organizational objectives. Smart tactics, minimal effort, and now you now have some powerful friends. Similar approaches can be used to minimize the impact of stakeholders opposed to the project if you understand what's important to them. 

Sun Tzu clearly shows that engaging with stakeholders requires more than reactive responses. The good news is a well-thought-out strategy -- implemented through nimble and effective tactics -- can virtually eliminate the need for reactive responses and crisis management, resulting in an overall saving of effort. "Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win." 

Does your stakeholder-management strategy let you "win first" and then deliver an outcome that benefits your stakeholder community? What other stakeholder wisdom have you picked up from Sun Tzu?

Adjusting to Team Time Warps

| | Comments (1)

Have you ever wondered why one person is always late for meetings while another one is always early?

Chances are you're dealing with people who see time differently. For some, time flows from the future into the present and on to the past at a steady rate of 60 minutes every hour. Others see time as a river carrying them forward to an uncertain future. And while everyone is aware of the three elements of time -- the past, the present and the future -- cultures see these in different ways.

Western European cultures tend to have a strong future focus -- what's happening in the present is focused on securing a good future outcome. The past is relatively unimportant, since "you can't change history."

Cultures with a present focus let go of the past, don't worry about the future and fully enjoy the experience of the present. This focus can be a wonderfully relaxing experience, but it can also lead to the need for immediate gratification and short-term payoffs -- traits of many "youth" cultures. 

More traditional societies -- for example, those found in Africa, Asia and southern Europe -- tend to have a past focus, looking to preserve their history and respect family and society elders. For them, the present is a continuation of the past, and there's not much point in doing too much planning for an uncertain future. In these societies, the Western view of time as a strictly linear function of seconds, minutes, hours and days is seen as very limiting.

Understanding these different perspectives can help you in a project environment. For example, someone with a strong present focus will see the discussion they're currently engaged in as important and consider it inappropriate to cut it off just to be on time for a meeting. But if that meeting is organized by a forward-looking person with a strong time focus, there will be problems.

One way to decipher where you and your team members are in the "time warp" is to use U.S. psychologist Thomas J. Cottle's Circle Test. Grab a sheet of paper and draw three circles on the page, arranging them in the way that best shows how you feel about the relationship between the past, present and future. Use different size circles to indicate relative importance and separate or overlap the circles depending on how much influence each one has on the others. 

Here are two examples that illustrate the different ways people view time:


The purple circles represent a strong future focus with the present feeding into achieving future outcomes. There's little connection to the past. This is typical for a lot of time-conscious project managers focused on planning their projects (a future focus) and then implementing the plans (a present focus).

The blue circles show a strong present focus firmly grounded in past experiences and traditions. The present is a bit more important than the past, but the future is not really connected to the present and of lesser importance. Don't expect someone with this perspective to be very interested in planning for an uncertain future or being on time for meetings. Their view of success is built on the strength of existing relationships and systems. 

The Western/project management focus on time can be effective, but it can also be dangerous, particularly in cross-cultural teams and when dealing with clients with a different time focus. The stress of missing an impending deadline can affect people's health, cause then to sacrifice their relationships and lead to shortcuts in quality and missed opportunities. Is it really worth destroying value by de-scoping a project just to achieve a deadline (especially if it's artificial)? A more balanced view may be that while the deadline is missed, there are opportunities to deliver 100 percent of the scope, identify additional hidden value, and maintain a healthier and happier project team. The optimum answer depends on the circumstances of the project and the time focus of key stakeholders.

What's your time orientation and how does it fit with the rest of your team and other stakeholders?

Harnessing the Law of Reciprocity

| | Comments (0)
I have become an ardent advocate for "the law of reciprocity" -- the principle that when you do a favor for someone, he or she will have a deep-rooted psychological urge to do something nice in return. And I believe it should be consciously practiced within the work culture. 

Reciprocating to a goodwill gesture is one of the universal rules of good manners. It is a principle that comes naturally to many of us despite our culture. Organizations and businesses are now capitalizing on this principle to build relationships internally with their employees and externally with clients and customers. Reciprocity exists in many different ways, such as: 

  • Information or good advice that is of value to the receiver 
  • Help or a kind gesture 
  • Recognizing and appreciating a person's contribution
  • Remembering events that are of importance to others
  • Rewards, celebrating personal or group achievements and successes
  • Sharing job opportunities or networking leads
  • Creating convenient services for employees, such as complimentary or subsidized meals for workers or on-site child care 
  • Free services for clients and customers
  • Thank-you messages
  • Public acknowledgment or mentions of good work 

So how can a culture of reciprocity help projects and those who work on them? 

Employee psychology surveys and studies have found a positive relationship between supportive organizations and employee commitment to the organization. These employees often also showed willingness to help the organization reach its goals. What's significant from these findings is that as reciprocity as a whole increased, so did employee obligation.  

Commitment and obligation to pursue project goals is ideal for project managers and project-orientated organizations. Therefore, creating a reciprocating project environment can only deepen individual and team commitment and ownership of tasks and concern for the project. It can also help increase individual satisfaction and team motivation as individuals feel supported, valued and connected. 

Project leaders can utilize the law of reciprocity by engaging and encouraging feedback from team members, and then using the information to create well-defined and simple processes or provide the means to make their work efficient. By removing unnecessary obstacles and demonstrating an active interest in wanting to help, leaders send a clear message to the team that its time and views are respected and valued. In return, team members may feel more obliged to reciprocate these efforts and show willingness to support the project and the manager during difficult circumstances. 

Reciprocity with project sponsors and executives can pay dividends for a project manager as well. A sponsor may become more willing to support the project manager in pivotal matters, such as acquiring resources and approval processes. And being in a reciprocal relationship allows project staff to say no to requests without angering or offending stakeholders -- with good relationships, there is more understanding and forgiveness for when things go wrong. 

Beyond project teams and stakeholders, reciprocity should be exercised with clients, customers and vendors. This is good for projects as it helps develop robust, long-term relationships rather than one-time engagements. And these relationships are especially useful when negotiating for resources, contracts, deadlines and finance-related matters.

But beware of how you approach reciprocity. It should be informal and without expectation of return in a specific situation or by a specific date -- otherwise it becomes a bribe, something negative and undesirable. Reciprocation should be carried out with sincerity, generosity and integrity. 

Can you think of a time when you used reciprocation to help with project work?

Determining the Value of Value

| | Comments (0)
What exactly is value? A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fifth Edition suggests value is a concept unique to each organization and encompasses the total sum of all tangible and intangible value elements. 

Determining the tangible ones is relatively straightforward and can easily be reduced to a financial return. More difficult is understanding the intangible value elements the project can create -- and identifying low-cost options with the potential to create massive intangible value by creating favorable outcomes in the minds of stakeholders.

One simple example is the practice of cutting small viewing windows in construction site fences. The cost is minimal, but the practice delivers value through improved safety because passers-by don't need to stand near the gate to see what's going on. There's also the public relations value of letting the public see the actual progress of the work. 

The challenge is finding and tracking these valuable intangibles, bearing in mind most of the value will be created in the minds of various stakeholders. One useful tool is consultant Edward de Bono's Six Value Medals: 

  • Gold Medal: Covers the things that matter directly to people, including pride, achievement, praise or humiliation.
  • Silver Medal: Centers on the purpose and mission of the organization and what matters to the overall business. It considers what will help or hinder us in pursuit of our goals. Examples might include profits, market share or brand image.
  • Steel Medal: Considers the effects on the quality or fitness for purpose of what we're doing, either positive or negative.
  • Glass Medal: Looks at impacts on our ability to innovate and change to do things in a new or improved way.
  • Wood Medal: Draws attention to the environment in the broadest sense, describing positive or negative effects of our decisions or actions on the world around us.
  • Brass Medal: Asks whether there's any resulting change in the way we and others perceive or are perceived.
Based on those, we can perform a "value scan" when determining courses of action within the project and prioritize actions to achieve the values that matter most.

Take a simple example. The last office refit covered up a duct in the wall of the CEO's new office. Now your project has to rip the sidewall out to access the duct and upgrade the cabling. Where's the extra value? Some possible medal ideas include:

  • Gold: Issue an internal news item showing the CEO cooperating with the project despite the inconvenience.
  • Steel: Make sure the duct is accessible in future without demolition work.
  • Glass: Use the repairs to offer an opportunity to update the CEO's office color scheme incorporating her preferences. 
There are probably other possibilities as well depending on the actual project. How do you assess the value of your project to your stakeholder community?

Dealing with Difficult People

| | Comments (0)
Your ability to contribute to a project team depends a lot on your ability to relate to people -- your team members, stakeholders, managers. While positive and supportive relationships can propel you to success, dysfunctional relationships can destroy you. 

If you mismanage a dysfunctional relationship with a difficult person, the fallout will affect your productivity and, quite possibly, the fate of your project. 

The first step is to identify whether you're in a toxic professional relationship. Here are some signs to look for in the other person; he/she:

  1. Stifles your talent and limits your opportunities for advancement 
  2. Twists circumstances and conversations to their benefit 
  3. Punishes you for a mistake rather than help you correct it 
  4. Reminds you constantly or publicly of a disappointing experience or unmet expectation 
  5. Takes credit or withholds recognition for new ideas and extra effort 
  6. Focuses solely on meeting their goals and does so at your expense 
  7. Fails to respect your need for personal space and time 
To successfully manage difficult people, you need to set boundaries that encourage mutual respect and keep the focus on productivity. Boundaries remind people of what's acceptable to you and what's reasonable to expect from you, and prevent difficult people from taking up too much of your time and energy. Failure to set these boundaries simply allows a toxic relationship to develop.

Establishing boundaries isn't easy, however. Difficult people don't like boundaries. They want to shift responsibilities according to their mood and create work environments that mirror their personal environments. 

Here are some ways you can set boundaries:

  1. Manage your time. Set a limit on the amount of time you spend beyond the hours needed to complete the project work. For example, you should politely but firmly decline an invitation to a peripheral meeting.
  2. Express yourself. Reveal aspects of your personality that reinforce your values. Sometimes it's a matter of letting people in a little bit to help keep your boundaries intact. If aggressive behavior offends you, say so (in a firm, but non-aggressive way), but you also need to consistently act in an assertive (rather than aggressive) way.   
  3. Build your reputation, and do it carefully and consistently. Everyone plays a role at work. Your co-workers should know what you stand for and what to expect from you. Then, don't waiver. Authenticity is the key -- behave in the way you expect others to treat you.
  4. Change the conversation. Stay focused on the project and away from nonproductive behavior.  Avoid gossip, criticism and other negative conversations by simply stating: "I don't really have time to discuss that just now, but I really do need your input on this project issue." If the attack is on you personally, ask to "take the conversation off line and focus on this important project matter now."

Effective relationship management is not for the faint-hearted. But when you know how to handle difficult relationships appropriately, you'll be in a much stronger position to achieve your objectives and succeed.

How do you manage difficult people? What advice would you give for establishing boundaries?

No Need to Know It All

| | Comments (0)
Many project managers feel they need to be the expert who has every answer to every question to maintain their authority. They think it's a sign of weakness to ask for help or admit they don't know something. 

The fact is that if you don't know something and waste time and energy trying to find the answer yourself — or worse, make an expensive mistake based on false knowledge — no one benefits, least of all you. Once your bluff has been exposed, your credibility is destroyed, and with it, your ability to lead effectively.

Strangely, most people seem happy to offer help when someone asks for it, but are too embarrassed to ask for help themselves. But strong leaders, managers and team members overcome this "shyness" and take the time to clearly understand what they don't know. Then, they seek aid to build their knowledge. 

The key is asking the "right questions" — this makes you a better leader and also shows your team that it's okay for them to ask for help. Everyone wins by asking for assistance when needed. The energy wasted on struggling to solve the problem can be used for positive purposes.

The power of "not knowing" will also open up two-way communication within the team and generate all sorts of efficiencies. Here are a couple of examples on how to put the power of not knowing to work:

  • Delegating. Some tasks are simply better delegated to an expert who knows how to do the job well and quickly. I'm sure everyone could learn to use pivot tables in Excel. But is it worth several hours of struggle when a knowledgeable expert — even if it's the most junior team member — can solve the issue in a few minutes?
  • Engaging team members. Ask a team member to talk you through a challenge he or she is working on. You'll get the lowdown on the task at hand, and good insights into how he or she works.
By encouraging your team to ask questions, it reduces errors, frees up communication and enhances the information flow in a positive way. It seems obvious, but it won't happen without a push in the right direction.

Things you can do as a leader to be open to not knowing are:
  1. Stop talking to yourself and decide that you are going to talk to someone else. 
  2. Decide who that will be. 
  3. Craft the conversation. Write down what you are going to ask them and how you hope they will respond.
  4. Schedule a meeting with the person and promise yourself you'll ask him or her for help and be open to his or her suggestions. 
  5. Tell someone else of your intentions; someone who will hold you accountable for having the meeting and asking for help. 
It really is okay to know what you don't know and seek help. The skill is asking effective questions that get the right answers, and then having the knowledge on how to use the resulting information.

How do you turn a lack of knowledge as a barrier to success into a catalyst for positive outcomes?

What's the Story? Stakeholders Want to Know

| | Comments (0)
There is nothing like a good story to connect with project stakeholders and team members. Storytelling has been used to communicate sophisticated ideas for millennia, ranging from the parables in the Bible to the morals found in fairy tales. 

Done right, storytelling is a captivating way to explain why your project (or a decision within the project) was initiated, what it will become and the benefits that will follow. 

Creating a good story requires skill, and while you may never become the next J.K. Rowling, applying some effective development techniques can help you hone your own storytelling style.

The "story spine," a tool created by U.S. playwright Kenn Adams, helps project professionals craft well-structured stories. The outline is a series of sentence fragments that prompt the narrative elements of your story. You can even use it in a group setting -- perhaps during an exercise in which you ask team members to craft a story to explain the technical decisions made by team.

The template is as follows, with a project management example in italics on securing buy-in to solve an emerging risk issue:

The Platform introduces the issue or topic.

  • Once upon a time...
  • Example: The project risk register identified...

The Catalyst explains why this is important today.

  • But one day, something changed...
  • Example: The recent findings have escalated this risk significantly by...

The Consequences explains the journey and the "problem."

  • Because of that... (This is repeated as many times as you wish.)
  • Example: Because of this, we have had to change...

  • And then _____ occurred.
  • Example: This change caused...

The Climax is the turning point that leads to the proposed solution.

  • Until finally...
  • Example: Which means the project must...

The Resolution is the final -- and positive -- solution to problem. 

  • And the moral of the story is...
  • Example: And we need your approval to implement these recommendations.

So next time you need to sell an idea to management or to your project team, why not try a good story? 

Have you ever tried telling a story to gain buy-in from stakeholders? What technique did you find helpful? 

Tailoring Communication for Top Stakeholders

| | Comments (1)
Given the amount of work involved, most of your project communication efforts should focus on the stakeholders crucial to the success of your project. And this requires answering two key questions: Who are the most important stakeholders, and why are they important? 

Determining who's important is usually straightforward, based on an assessment of the stakeholder's power and involvement in the project. Understanding why each "important stakeholder" is important helps you define the type of relationship you need to develop for effective communication.

Enter the mutuality matrix, a useful project communications tool that starts with two dimensions:

  • Each stakeholder needs something from the project to further his or her interests, or alternatively, needs nothing from the project. 
  • The project requires the active support (assistance or resources) of the important stakeholders, or alternatively, requires nothing from the stakeholder.

These assumptions create four quadrants for categorizing each of the important stakeholders:

  • Project needs nothing/stakeholder needs nothing: Stakeholders in this quadrant are usually protesters. In this case, you have two communication options: You may be able to defuse their opposition by providing better information, but this only works if the protesting is based on false assumptions. Otherwise, you may choose to limit communication with the stakeholder whilst keeping the communication channels open. 
  • Project needs nothing/stakeholder needs something: The stakeholders in this quadrant are the easiest to manage from a communication perspective. You are already providing their requirements as part of the project deliverables. All that's required is to provide reassurance that their needs will be fulfilled. If their requirements are outside of the project's scope, the stakeholder should initiate a change request.
  • Project needs something/stakeholder needs something: This group needs active management. Project communication must clearly link the stakeholder's support or resources to how the project fulfills his or her requirements. Take the time needed to develop robust relationships to facilitate cooperation.
  • Project needs something/stakeholder needs nothing: Stakeholders in this quadrant are a major risk. They're typically regulatory authorities, or people who have to inspect or approve the project's work as part of their business. Carefully build a proper professional relationship that respects the integrity of the stakeholder's position while at the same time ensuring your communications are received and acted upon.

Once you understand the mutuality matrix, the way you communicate with each of the important stakeholders can be adjusted to ensure both parties achieve a satisfactory outcome. For example, the time and effort saved by minimizing communication with intractable objectors can be invested in building relationships with your key suppliers.

Keep in mind that each stakeholder will also be either supportive of or opposed to the project. Important stakeholders against the project — typically competitors and objectors — usually need nothing from the project and your communication should be focused on minimizing the objections. Similarly, important stakeholders who need something from the project are usually either passive or supportive, and your communication should be focused on building robust relationships.

How do you identify and communicate with important stakeholders?

5 Communication Tips for Better Stakeholder Management

| | Comments (5)
Over the past few years, I have written numerous posts looking at different aspects of stakeholder management. But what really matters and what is just useful to know? 

Here are my top five things to know to achieve effective stakeholder management:

1. Know who really matters. Make sure that the majority of your limited resources are being used to communicate with the stakeholders who really matter. They might not always be the bosses, either. The most important stakeholders will almost certainly change from month to month, so you need to regularly re-assess who is a top influencer at any given time. 

2. Know why those stakeholders matter and what they need or want. Mutuality is important. If you need something from the stakeholder, you need to be able to link your needs with their requirements. Trading is far more effective and realistic than relying on charity or altruism. 

3. One size fits no one. If you want your communication to be effective and deliver the outcome you need, you must understand the stakeholder with whom you're communicating. If you want your communication to have its intended effect, you need to have the right information for the receiver, in the proper format and delivered through the channel he or she prefers. 

4. Attitudes change constantly. People change their minds all of the time. What you knew about your stakeholder's attitude toward your project last month is probably out of date. To compensate for a shift in focus, constantly re-assess the important stakeholder's attitudes and adjust your communication plan to deal with the current situation.

5. Everyone is biased (including you). When managing stakeholders, rational objectivity is nearly impossible to achieve. You are using your perception of your stakeholder's perception of your project to plan and manage your stakeholder communication effort. But perceptions are not real -- they are simply a person's understanding of what they believe to be real, filtered through their innate and acquired biases. 

To be successful, you need to be pragmatic, design the best communication plan you can with the resources available to you, and then see what happens. 

Knowing these five basic concepts and adapting as the situation changes won't guarantee success, but it will at last give you a fighting chance. Your project will always be better off if you spend time thinking about the best way to manage your stakeholder's needs and expectations. 

Why 'What's In It For Me?' Works in Projects

| | Comments (0)
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?

Lessons Learned with External Teams

| | Comments (4)
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?

Can Modern Executives Learn from the Romans?

| | Comments (0)
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? 

Create Program Visibility

| | Comments (3)
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.

Buddist.jpgPlanning 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.

Buddhist2.jpgAlthough 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.

Executive Sponsorship: Benefits of Advising Upward

| | Comments (1)
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.

Finding the 'Flaw' in Projects

| | Comments (0)
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.

There's No 'Root Cause' in Project Failure

| | Comments (1)
"Complex problems have simple, easy to understand, wrong answers."
-- H. L. Mencken

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.

What Does a Project Sponsor Really Do?

| | Comments (6)
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. 

Project Change Challenges

| | Comments (10)
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.

Ask Good Questions to Ensure Project Governance

| | Comments (2)
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?

View more posts on stakeholder management.

Persuade Stakeholders for Effective Project Governance

| | Comments (1)
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?   

Beyond Stakeholder Management

| | Comments (6)
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?

Win-Wins Can Build Your Project Team's Brand -- and Your Profession

| | Comments (0) | TrackBacks (0)
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?

"Requirements" for Managing Your Project and Team

| | Comments (2) | TrackBacks (0)

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?

How to Manage Key Stakeholder Expectations

| | Comments (2) | TrackBacks (0)
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.

Mitigating Risk with Project Advocacy Consultants

| | Comments (4) | TrackBacks (0)
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.

Different Perceptions of Risk on Projects

| | Comments (4) | TrackBacks (0)
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.

Influencing Senior Project Managers

| | Comments (1) | TrackBacks (0)
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.

Your Project Stakeholders are Biased!

| | Comments (0) | TrackBacks (0)
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.

Project Communications: A Visual Understanding

| | Comments (2) | TrackBacks (0)
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.

The Value of Project Team Rituals

| | Comments (6) | TrackBacks (0)
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.

How Arguments with Stakeholders Hinder Project Managers

| | Comments (2) | TrackBacks (0)

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:

A farmer died and left his herd of 17 camels to his three sons. In his will, he left half of the camels to his eldest son, one third of the camels to the second son and one ninth of the camels to his youngest son.

The three brothers were having great difficulty working out a fair way of implementing their father's will and could not agree on who would have more and who would have less than the amount willed. Before their relationship became too stained, the brothers went to visit a wise old woman who lived in their village to seek advice.

She told them she could not solve their problem but would give them her only camel if it would help.

The brothers thanked her and took the camel back with them. With a herd of 18 the problem simply disappeared; the first brother took 9 camels, the second six and the youngest two.

But, 9 + 6 + 2 = 17, so they gave the spare camel back to the wise old lady with their thanks.

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?

Project Delivery Teams are Stakeholders, Too

| | Comments (1) | TrackBacks (0)
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?

Communicating Project Perceptions with Stakeholders

| | Comments (0) | TrackBacks (0)
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?

The Project Management Stakeholder Web

| | Comments (0) | TrackBacks (0)

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?

Using Expert Stakeholders Wisely

| | Comments (2) | TrackBacks (0)
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? 

Pragmatic Leadership in Stakeholder Management

| | Comments (3) | TrackBacks (0)
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?

Valuing Your Employee Stakeholders

| | Comments (4) | TrackBacks (0)
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?

What Elevators Can Teach Us About Project Management

| | Comments (0) | TrackBacks (0)
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?

Implementing Difficult Decisions

| | Comments (1) | TrackBacks (0)
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.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll