Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Lynda Bourne
Influencing Senior Project Managers
Categories:
Stakeholder Management
Categories: Stakeholder Management
| How do you change a stubborn senior manager's mind? For example, he or she might claim your project only needs six weeks to complete, even though you have a carefully researched and resource-loaded schedule that proves 10 weeks is needed. Arguing won't work. In fact, given the power structure, arguing will simply put you in a worse position. Doing nothing simply delays the problem and you will eventually be held accountable for your perceived failure to meet the stakeholder's unrealistic expectations. To change a senior manager's mind, you need to change the manager's expectations. Though you may battle a heavy overlay of skepticism, use of effective communication and a planned strategy should do the trick. Effective communication requires that at least two of the following three elements be present: • You're known as a technical expert. • You're credible: People know you provide reliable and accurate information. • The information you're communicating is relevant to the receiver. Influencing a skeptical senior manager requires you to boost all three facets. You cannot do this alone. Some options to consider include: Co-present your case with a trusted source. You increase your chances of success by sharing the stage with someone the executive trusts. Build the value of your ideas on the credibility the co-presenter has established with the executive. Demonstrate endorsements to build power. Ask others in positions of power to let the executive know they support your idea. Stroke egos and use the executive's credibility. Authentically move ownership of "the" idea -- not "your" idea -- into his space. You can do this by using phrases such as "You've probably seen this data already," or "I'm sure your analysis has shown similar results." These approaches need organizing and take time but are essential if you are going to effectively advise upward. How do you influence your senior managers? Read more on stakeholder management. |
Your Project Stakeholders are Biased!
| 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
| 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
| 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
| 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? |