Stakeholders who fear bad project outcomes are tough to manage. It’s important to address these fears. Left unmanaged, your project could be delayed or even cancelled. Here are a few approaches to manage project fears.

• Listen to fearful stakeholders. Their past experiences may have tainted their perceptions. You need to understand their concerns. Actively listen to these people: make eye contact, ask questions, paraphrase their points, use the terminology they use. Stakeholders will feel heard when you refer to the business implications at the source of their fears. When stakeholders feel their concerns have been heard and are taken seriously (that is, the project team is committed to addressing their concerns), their comfort level with the project increases.
• Share your plans. Your project plan talks about how you will accomplish things and what you do to ensure obstacles don’t prevent you from achieving project objectives. Stakeholders become concerned when there is a lack of communication, unexplained changes, or drawn-out decision-making. So don’t be shy about communicating how your project plan will help avoid obstacles to successful project delivery.
• Add risk items to your plan that directly address stakeholder fears. Add items to your risk management plan related to your stakeholders’ fears. Ask them to help look for trigger events and implement risk responses. This way, the project team will partner with these stakeholders to ensure their fears don’t come to fruition. Even if the risks occur, they will be addressed directly with pre-determined actions the fearful stakeholders have already agreed to.
• Address areas of concern in status reports. In your status reports, address the status of stakeholder’s concerns. This reinforces that the stakeholders were heard and that the team is focusing on those concerns as the project progresses.
• Highlight quick wins. Identify and communicate completed milestones as the project unfolds. Celebrating these wins helps stakeholders visualize progress and builds confidence in the project’s ultimate success.
• ALWAYS support views with data. Trying to reassure fearful stakeholders with past experiences doesn’t work. They don’t relate to projects they weren’t involved in.  Objectives information is more reassuring than subjective opinions. Support your assertions and decisions with data, metrics, and evidence from industry best practices and actual progress with the current project. Stakeholders are more likely to feel reassured.

Have someone with a concern about your project? Of course you do! Take 15 minutes to plan how you will use these approaches to address their concern. And then, try it! Let us know how it goes in the comments section.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 71,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Validating the assumptions included in the project justification is key to minimizing project risk. Sometimes, straightforward research is enough. For assumptions that aren’t easily validated, here are other approaches to validate or, at least, reduce the probability of an assumption being wrong.  

• Consult experts. Reach outside your organization. Seek the opinions of LinkedIn contacts, peers in project management associations, or prominent individuals in industry bodies. Ideally, get multiple perspectives so you can analyze the results to identify project situations that could render an assumption invalid. If you get differing opinions, use the Delphi approach. Send the differing opinions to your expert panel and ask them to comment on the rationale for dissenting views. Use the results of that exercise to figure out if the assumptions present a significant risk to the project.
• Perform an audit. Find situations where you can directly test the validity of the assumption. Then, test the assumption via a manual process, querying a customer, or performing any other action that might provide a “sample result” you can use for validation purposes. For example, altering the directions you provide to clients to solve a product issue, publishing an advertisement with a different angle to a small set of clients, or changing the parameters of a system function to see if the subsequent system or user action is expected. Note: this approach has risks. You don’t want to frustrate a client or have an advertisement yield an adverse reaction to your product. To minimize risk of adverse outcomes, select the clients and situations carefully, and if feasible, alert a trusted client that you are trying something new.
• Build a prototype. Designing a prototype process or I/T system is an effective way of validating assumptions. When it works, it triggers enthusiasm for the project and its potential business results. Depending on the situation, the prototype can be a small, standalone project or a set of features in an agile project environment. With this approach, be prepared for the project to take an unanticipated direction — your stakeholders might create additional requirements. No worries, the result is often more effective than the original plan, so keep an open mind.
• Conduct a survey. Query individuals who aren’t familiar with the project’s justification and current assumptions. Why? Because stakeholders who know the assumptions can answer the survey questions to confirm or invalidate them based on their views about the project. Also, don’t make the mistake of taking a casual approach to designing survey questions. Use people with experience designing survey questions: the wording of survey questions is vital to ensure you get valid results.

Have you come up with other approaches for validating assumptions? Or have tips for managing the nagging feeling that you haven’t even identified all the assumptions? If so, share with us in the comments section.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 70,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

People who think they’re stakeholders but aren’t waste your time and distract your project team. Early on, you need to address these pseudo-stakeholders, so they don’t eat up your time and resources. This Project Pointer provides approaches to identify them and reduce their impact on your project.

• Hold public consultations. After meeting with identified stakeholders, it’s time to hold open-to-the-public meetings to discuss the project’s scope and objectives. People who think they have something to lose or gain from the project can share their thoughts and concerns at this meeting. By addressing these concerns early, you save time later on (from minimizing distractions from pseudo-stakeholders) that more than makes up for the time it takes to plan and deliver a public consultation session.
• Draft out-of-scope statements. Project charters typically focus on defining scope. An underused aspect of project charters is identifying what is out of scope. By clearly defining what is and is not in scope, you can help prevent pseudo-stakeholders from delaying the project with needless debates.  
• Build a deliverables map. This is a visual representation of the deliverables produced in a project, showing the prerequisite deliverables that must be completed to produce the project’s final deliverables. This comprehensive overview of every item the project will produce can highlight the areas of the organization that will and won’t be affected by project deliverables—and from that, you can demonstrate who actual stakeholders are. Anyone else is a pseudo-stakeholder.
• Focus on organizational politics. Be aware of internal politics, power struggles, or turf wars that might lead individuals to think they are stakeholders. You can proactively address people’s concerns when you understand who challenges scope statements or demands more for their business area. Politics will alert you to managers (beyond your project sponsor) who you need to work with to prevent pseudo-stakeholder objections.

Try these approaches with your current project to see if you have pseudo-stakeholders dragging your project down. If you do, it’s time to address them politely, firmly, and with your reasoning.

For more about stakeholders, check out Natasha Kasimtseva’s Managing Project Stakeholders course.

______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 69,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

A project manager doesn’t have to be an expert in a project’s domain area to serve as PM. But they must possess some domain knowledge to be effective. Here is the general domain knowledge needed to manage a project.

• Processes and regulations. Domain areas have specific approaches to work and standards that must be understood. For example, in the drug industry, processes for introducing new medicines are rigid. These must be understood to deliver project outcomes.  In construction, one must know the laws that restrict a building’s design. Without this, the building could become unusable without expensive modifications. In healthcare, managing and sharing data requires both health and technology process knowledge. Without this vital domain knowledge, project managers have reduced foresight. And they are unlikely to gain the respect of their project teams which makes it difficult to succeed.

• Sources of risk. Effective risk management involves understanding the challenges that may present themselves. The project manager must know enough about the domain area to anticipate possibilities. They also should understand the probability of them coming to fruition. While having an expert team member as a management partner can help, it isn’t enough. The project manager needs to interact with key stakeholders without deferring to others. They must also react to situations that occur daily. Having to constantly refer to an expert partner impacts the project manager’s perceived authority. It also brings their abilities into question, reducing effectiveness.

• Ability to assess business value. Projects are all about creating business value. Sometimes that value is obvious, like creating a new drug that cures a disease. Other times, value propositions are more subtle, requiring industry expertise to understand them. For example, the value of a great website is that it is easy to maintain after delivery to a client. So, website construction techniques are important. The project manager should participate in construction decisions to ensure maintenance is straightforward. This requires an understanding of the capabilities of modern coding languages. Knowledge about AI tools and search engine optimization is also useful. Unless the PM has some level of experience in these areas, they could overlook critical project activities.

• Management practices and cultural expectations.  Domain areas have varying norms around how decisions are made. The expertise that is most valued, and how clients and their vendors work together also vary between domains. Industry trends might not be easy to identify without domain experience. Understanding these nuances are vital for a project manager to succeed. These can be learned on the job if knowledge gaps aren’t extensive, but that must be done quickly so project success isn’t impacted.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 67,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Quality management is about ensuring your deliverables meet the expectations of stakeholders: meeting standards, performance and reliability business needs. But quality management delivers extra benefits you don’t often hear about: 

• Enhanced stakeholder buy-in. Quality management requires a deeper grasp of stakeholder needs and expectations. That understanding comes from better conversations and learning about stakeholder’s challenges and hopes. These stakeholder interactions boost buy-in to the project and also improve the stakeholder/project team relationship.
• Expanded risk management. Understanding quality standards and performance expectations leads to a better understanding of product requirements. That understanding broadens your view of what must go right and what might go wrong with the project’s products.
• Increased innovation. Quality management encourages continuous improvement and expands problem-solving. A quality mindset fosters innovation. It also increases the capability of the project team and stakeholders. Project team capabilities increase through new and better ways to meet quality standards. Stakeholder capabilities are increased through enhanced requirements definition. This also improves outcomes by improving stakeholder’s interactions with project teams.
• Increased product knowledge. Quality assurance activities, such as reviews, inspections, and testing, produce learning moments. They expand the understanding of the product’s strengths and weaknesses. And they also help identify potential areas for future development. So, you get better outcomes now and new pathways to improve your business in the future!

As you work on quality aspects of your projects, look for ways to use these added benefits.

For more about project quality management, check out Daniel Stanton’s Project Management Foundations: Quality course.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 66,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________