How to Handle Fearful Stakeholders

/in /by

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.

_______________________________________

Project methodology considerations

/in /by

Choosing the right methodology for your project is crucial for success. Agile methods are effective when iterative development is suitable for the product, capable technical team members are available, and access to client stakeholders is assured. But other considerations may affect which methodology you choose.

  • Do specific milestones have to be met? Consider a project’s date-driven key process indicators (KPIs) when selecting a methodology. The flexibility and adaptability of Agile projects is meant to support iterative KPIs to measure progress, focusing on incremental improvements. On the other hand, structured waterfall projects are more suitable for milestone-based KPIs, when an agreed set of pre-defined objectives must be achieved by a specific date. Agile can be used to deliver milestone-based KPIs. However, when specific and detailed requirements are in place, stakeholders are less likely to want to participate in project development to the degree that agile requires. If stakeholders aren’t committed, waterfall is the best approach, especially in larger organizations that often are reluctant to assign key operational personnel to longer-term projects. Waterfall methodology is also a better approach for industries or projects that have specific regulatory or compliance milestone requirements that require a more structured and documented approach. 
  • Is the project complex? Complex projects benefit from a waterfall approach, especially those with interdependencies between numerous internal groups or external entities. Planning interactions and timeframe commitments must be carefully structured and agreed upon beforehand. The fluid nature of agile can make these inter-organizational interactions challenging. Less complex projects, with few internal interactions, are more suited to agile, given its flexibility and short-term delivery mindset.
  • Are there many assumptions associated with the project? Project justifications that rely on many assumptions — or assumptions tied to crucial aspects of the business –are more suitable for agile because it promotes learning and iterative improvement. Risks are reduced via quick prototype features built to validate assumptions, diminish risks, and confirm suitability for business processes and outcome generation. A waterfall approach when many assumptions go into a project justification introduces risks that aren’t likely to be resolved in the short-term.
  • Is the project aligned with strategic or shorter team goals? Projects aligned with long-term strategic plans might favor a waterfall approach, because they must produce more extensive, non-flexible objectives. In contrast, agile is ideal for addressing shorter-term changing market conditions and achieving quick wins from a cost or productivity standpoint.

 

Have you used other considerations to choose between methodologies? What happens if the company wants to force a methodology that doesn’t suit your project? Share your experiences with us in the comments section.

For more about methodologies, check out my Project Management Foundations course.

_______________________________________

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.

_______________________________________

How to prepare a project idea for primetime

/in /by

Project ideas are what support careers in project management — and present possibilities for moving your organization forward. Sometimes, project ideas need more work before they should or would be accepted. Here are indicators that a project idea isn’t ready and how to improve it:

  • The sponsorship prospects aren’t clear. A great question about a project idea is, “Who would be an appropriate sponsor for this initiative?” If the answer isn’t clear or several sponsors might be needed to fulfill sponsorship responsibilities, that’s a problem. A project is doomed without sponsor commitment. The fix: restructure the project idea to align with a potential sponsor’s scope of responsibility. 
  • Unclear benefits. For a valid project idea, 1 – who will benefit? and 2 – how will those benefits be realized and measured? If you can’t answer those questions, the idea might still be valid, but more work is needed before proceeding. Look for benefits resulting from changes to business processes, technology solutions, or customer support approaches. Then, document the answers to the questions above.
  • Unclear funding sources. For every project idea, it’s essential to ask, “How will we pay for this?” If the answer is not clear, more work is needed to determine where the project’s benefits will be realized. Analyze the project benefits to identify the business area that will benefit from improvements – that’s your candidate for funding.
  • Technology challenges exist. Some valid project ideas face technology platforms that struggle to handle change. Either the systems are too old or fragile, or the backlog of changes for the technology team is too large. In this case, you can consider two approaches. First, can benefits be obtained without extensive technology changes. Alternatively, if the benefits are large enough, consider contracting specialized technical or supplementary resources to address the technological changes needed to implement the project idea.
  • Lack of strategic alignment. Resources and/or funding shortages often constrain organizations. Project ideas that don’t support the organization’s strategic direction aren’t a good idea. If necessary, restructure the project idea to support the organization’s strategy — or dismiss it as one that doesn’t fit current business priorities.

If you’re a project manager who doesn’t hear about project ideas early on, the points in this article are great topics to discuss as you finalize your project charter. If the project rushes ahead before the points are resolved, incorporate them as risks in your project planning. That way, you can discuss risk response activities with your key stakeholders.

_______________________________________

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.

_______________________________________

How to Validate Project Assumptions

/in /by

 

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.

_______________________________________