Dealing with wanna-be stakeholders

Wanna-be stakeholders are secondary or out of scope stakeholders who are trying to push their way into your project to get their concerns addressed. They can generate scope creep, drag out decision making and stall your project.

Here’s how to deal with wanna-be stakeholders.

  • Define out of scope items by business area. That way you can uninvite wanna-be stakeholders from your meetings. This allows you to focus on items the project is intended to serve, making it easier to manage. You can take requests from the wanna-be stakeholders for a future phase of the project.
  • Designate business area representatives. Stakeholders within a business area may propose different requirements. This can create conflict and confusion within your project. Designated representatives from each business area are responsible for aligning requirements before conflicts reach your project team.
  • Define observer only meeting attendees. Excluding interested stakeholders from meetings can violate transparency norms. With observer only attendees (people who can listen, but not comment or ask questions), you can keep project discussions focused, efficient and transparent.
  • Distribute project newsletters. Frequent status updates to your broader stakeholder set is often all that’s needed to satisfy wanna-be stakeholders. While you may get questions to answer, that takes less time than defending your project from challenges presented due to a lack of information.

#projectpointers #projectmanagement

For more on managing stakeholders, watch the Analyze Stakeholders movie in my Project Management Foundations course.

Do you build a WBS Top down or bottom up? The answer is YES!

Some people think from the top down and consider the high-level deliverables or activities required to accomplish project objectives. Others take a bottom-up approach, focusing on details that must be completed. When building a work breakdown structure (WBS), use these differences to your advantage.

Here’s how to leverage top down and bottom up thinking when building a WBS:

  1. Sketch a high-level set of activities or deliverables. A WBS is built by grouping similar activities or deliverables. The key is to be consistent and not mix the two constructs. Use your best top-down thinkers to create a high-level grouping for your project. Give your team time to consider major items that fall into each group. These major items can be broken down further as appropriate.
  2. Review and align with your team. Develop a common understanding of the work that the WBS represents and ensure there is no duplication of the major items captured in this initial version of the WBS. (Senior team members confer to determine whether there is duplication.) Determine how much detail is required to complete the WBS and determine the best individuals to add the necessary detail.
  3. Draft the detailed tasks for each major item. Now is the time for your bottom-up thinkers to shine! Bring your team together and brainstorm the tasks that must be completed to deliver your project. Allocate those tasks to the appropriate major items. Identify and resolve activity overlaps or duplications that may surface. Note: Your team doesn’t have to worry about sequencing your tasks at this point. Sequencing will be done later during schedule development.
  4. Finalize the WBS. Gather your team and review the final, detailed draft of the WBS. Talk with your top-down thinkers to ensure the overall approach is sound. Your bottom-up thinkers should be confident all the details are covered. If everyone is happy, you’re done!

Note: For more complicated projects or if significant questions arise, you can repeat steps 2 and 3.

For more about project management, check out my LinkedIn Learning Project Management Foundations course.

Realistic agile selection

Not every project is suitable for agile. To succeed with agile be sure to use sound criteria to qualify your projects as good agile candidates. Here are things to consider when establishing your agile qualification criteria:   

  • Project priority to obtain the right staff. Having the appropriate technical and business team members dedicated to the project is crucial. Agile produces results quickly and it’s time-intensive for participants. Agile requires critical business and technical team members who are vital to your business operations. So it’s important to prioritize their time so they can contribute to the project. Accepting the difficult tradeoffs between project work and operational considerations is key.
  • Appropriate breadth of knowledge. In-depth knowledge of the business and technical areas touched by the project is crucial. Business experts working closely with expert technical team members is the heart of the agile approach. The primary characteristic that makes agile methodologies agile is the method’s responsiveness to evolving needs. Knowledgeable technical and business people need to consistently reassess the project’s product, the business’s needs at a macro and micro-level, and the priority of the functions needed by the end customer. Without knowledge and availability for those assessments, the premise of agile methods crumbles.
  • Sponsor with an agile mindset. The sponsor must be willing to participate in frequent reviews of the evolving product, which are fundamental to the agile approach.  On the other hand, a sponsor who wants a linear, methodical set of objectives delivered to a pre-conceived schedule will struggle with agile project deliverables. Agile responsiveness to changing business conditions and its learning environment are very different from traditional project methods. Sponsors who resist evolutionary nature of agile create difficulties that can sink a project.
  • Ability to co-locate or simulate co-location. Agile involves deep, interactive, and sometimes challenging dialog, which produces superior outcomes. Getting the most from that dialog requires the richest environment you can create. Co-locate your project team members if possible. If you can’t, simulate co-location with the best video and audio tools you can obtain. Trying to facilitate agile dialog with sub-par communication tools is like trying to tow a big camper trailer with a lawn tractor. It just doesn’t make sense.
  • Business and technical team member synergy.  Agile methodologies require dedication from business and technical experts open to supporting new ideas and each other as individuals. You need an agile coach who understands and can manage human dynamics, and who can foster an environment where team members readily share their ideas and concerns. An agile team has to get along well to be successful.
  • A product that can be built iteratively. Agile’s best qualities come from delivering solutions in pieces while learning from each iteration. In addition to software products, other products can be produced this way as well. With a bit of creativity, facility moves, new process implementations, and even some construction projects can utilize agile methods. If you think of a way that your outcome can be produced in iterative steps, the project may be a candidate for agile (given the other items listed here, of course!)

For more about project management, see my Project Management Foundations course.

Assess your change approval criteria

Successfully managing project scope depends on robust change management that examines the merits of each proposed scope change. Sound change management requires good change approval criteria.

Typically, change approval criteria evaluates:

  • How scope will change
  • Project costs added or deleted
  • How the schedule will change

For small projects or for very minor changes, these evaluations are enough. For more significant scope changes, consider assessing additional topics to strengthen your project’s change approval criteria.

Does the change add risk to the project? Change-related risk can vary. Adding new technology, tightening your deadlines, or forcing the business to deploy multiple changes at one time can challenge your business. Examine the risk each change brings to your project and the business.

Will more stakeholders be added? Adding stakeholders to an existing project can trigger replanning, alter success criteria, or create requirement prioritization issues. These can be very disruptive and should be carefully evaluated before approving a change.

Is additional integration involved? Increased integration of technical tools, business processes or both will add complexity to your project and expand your need for testing. This can also require additional specialized personnel on your project. Evaluate new integrations carefully.

Will multiple vendors be required? Requiring multiple vendors adds contract management time. Having vendors work together can add complexity and conflict, as vendor expectations and agendas may differ. Examining your history when working with vendors is a critical part of assessing the merit and impacts of a change.

Does the proposed change support the spirit of the project’s original scope? Ambitious or creative stakeholders can recommend project scope changes that won’t enhance or expand the original intent and business case for your project. Evaluating changes against the initial project purpose helps ensure your projects remain focused and stay within triple constraint expectations.

For more about project and change management, check out my Project Management Foundations course.

When does scope creep mean you need to redefine your project?

Bob McGannon and I talk about when project scope changes might trigger the need to revise your project definition.

Creating a positive project environment

You’ve probably heard “the leader sets the tone.” This tone is all about the environment you create for your project team. Here are things you can do – TODAY – to make your project environment a positive one.

Promote the sharing of news, good and bad. Task completions, delays, stakeholder conversations, new ideas, and conflicts are all changes in status – and you’ll hear about all of them if you support your teams. Whether updates are positive or negative, thank people who share status information. That way, you can respond to project issues, rather than react without time to think.

Build a team. Even for a short project. Come up with a team name — not the project business name. (Nobody wants to work on the Amalgamated Velcro Production and Efficiency Management Project…but they might enjoy being on the “Better Rip and Stick” team!). Act as if YOU are part of the team and promote teamwork to get tasks accomplished. Share accountability and celebrate little victories. You’ll get dedicated team members who will want to work with you…now and in the future.

Ensure team members know the business relevance of their tasks. A WBS doesn’t convey the relevance of tasks to your team members. Ensure they understand how their deliverables fit into the big picture and will improve the business. You’ll get better deliverables and more dedication from your team.

Help team members feel like they belong. Having a diverse team is good, but that’s only step one. Include all your team members in decision-making and planning your project. Beyond that, help every team member feel they belong by caring about them.

Share the business’s impressions of your project. Often, the best thing you can do is shield your project team from business stakeholders, especially when business pressures cause wild reactions to status changes or preliminary project change ideas. However, you should share how the business views the project and how its outcomes will be put to use. This helps the team understand the project and builds motivation to produce results on a difficult project.

For more on building your project team, watch the Manage Team Resources movie in my Project Management Foundations course.

Make projects goals achievable

Want to make project goals achievable? Make sure they’re clearly articulated, supported by key stakeholders and involve available skills. That’s no guarantee though, because other conditions can impact their achievability. Here are items to help ensure your project goals are reasonable and motivate your project team.

  • A fully understood product approach. Goals become achievable when team members understand what is expected of them. Team members are more confident when they use familiar approaches to produce  project deliverables. But businesses must innovate to remain competitive and that introduces unfamiliar approaches that team members must embrace. This requires time and specialized resources to develop and practice new approaches. To support innovation and achievable goals, include funding and time in your project to help the team assimilate new approaches.
  • The tool to measure success is understood. Project goals are achievable when management and the team understand how success will be measured. There are two aspects to this. First, with clear measures of success, the team can identify incremental improvements. Second, understanding metrics supports innovation, because measurement can highlight improvements that help achieve project goals.
  • Applicability to business processes is understood. Project staff is more likely to understand project goals when they’re specifically tied to existing business processes. That understanding helps them focus their project effort and improves the chance that project goals will be achieved. What if new products or processes aren’t associated with existing processes? To help the team understand these items, draw parallels between existing processes and the new product and processes. Where that isn’t possible, early work to develop new processes helps teams understand the direction they need to take to achieve defined goals.
  • Practical timelines. Project team members are more likely to support practical, non-arbitrary deadlines. A practical deadline means the timeframe reflects durations like those for prior projects. However, a tight deadline due to a legitimate need for the business can be reasonable, as long as management gives the team permission to use new approaches to meet the deadline. Review the rationale for proposed timelines with team members to make aggressive deadlines believable to motivated teams. (Think Apollo 11 landing on the moon prior to the end of the decade!)

To learn more, check out my Project Management Foundations course

Where’s my team anyway? Managing Projects Remotely

Managing projects is challenging but managing a remote (virtual) team includes some nuances.  Surprisingly, you can use these to your advantage.  Here are techniques you can leverage to help your remote resources work as part of a productive team.

  1. Have frequent short meetings. Bring your remote team members together. Hold regularly scheduled meetings 3 times a week for just 15 minutes.  This provides a quick opportunity to understand the “pulse” of what’s happening.  These are like water-cooler conversations you have when you’re co-located with your team members.  During these meetings you can discuss work-related items or check on how your team members are doing.  This is time well spent!  These discussions identify problems early so remote team members don’t get stuck trying to solve problems on their own.  These meetings can be with small groups or 1-on-1 depending on the number of people you have and their role on your project.
  2. Celebrate wins together.  If you’re celebrating onsite, do something to acknowledge remote team members.  Send them a gift package or tickets to a local event. They’ll feel included and motivated.
  3. Insist on good video conference capabilities.  Phone calls are good, but video conference meetings are better…when the technology works.  Seeing someone gives you a better understanding of how meetings are going and enables you to connect with remote team members.  This approach recognizes that non-verbal cues are just as important as your discussions.  If you can’t access video conference capabilities, make sure your speaker phones work properly.  Nothing is worse than being remote and not hearing discussions or being unable to contribute because you can’t be heard.
  4. Give analytical assignments to remote team members. Sometimes your remote team members can be more productive as they have fewer distractions. Giving remote members assignments that benefit from quiet, uninterrupted work time can enhance your productivity.  
  5. Schedule meetings at different times.  Consider the time zones and schedules of your remote team members. Impacting your local team on occasion is worth the inconvenience to demonstrate consideration for your remote team members.  This sends the message that everyone’s time is valuable and remote team members shouldn’t always be the ones attending meetings outside business hours.

Because many projects have remote team members, these techniques will enable all of your team members to be productive and work together effectively.  Leverage remote members to your team’s advantage – there’s no reason for remote workers to be a disadvantage to your project!

Defining Proper Project Objectives

Initial project objectives can vary from precise to vague. It’s important to ensure objectives meet the sponsor’s expectations and fit the needs of the business and key stakeholders.

Many project managers use SMART objectives, which stand for: Specific, Measurable, Achievable, Realistic and Time-constrained. But SMART objectives are only the beginning. Here are other considerations for appropriate project objectives:

  • Aligned with strategy. Strategy is implemented through business change projects, but that doesn’t mean all projects are strategic. You can ensure that your project is viable and its project objectives are appropriate by understanding your organization’s strategy and by making sure that your project’s objectives and the way you achieve them don’t detract from that strategy. For example, don’t fall into the trap of using old, “reliable” technology to implement a project when the strategic direction is to use more powerful, future-proofed tools. While it may take longer, supporting the organization’s strategy is probably more important in the long run.
  • Scheduled mindfully. While SMART objectives address achievability, that doesn’t mean the objective is appropriate given the current workload your critical project team members are handling. Other projects and operational responsibilities may create excessive expectations for team members. To determine what is truly achievable, you need to identify the current demand for critical team members along with the demands your project will place on them.
  • The right approach. As project objectives can vary, the approach for achieving them varies as well. Having well-defined requirements that are unlikely to change and needing to support specific milestones indicate a waterfall approach is more appropriate. Conversely, loosely-defined requirements and tight deadlines indicate that agile approaches may be best. Ensure your project objectives are realistic by creating plans to deliver your project based on available staff, required timeframes and the nature of your requirements.
  • Mindful of change management. While businesses need to move fast, people are limited in the magnitude of change they can successfully manage, procedurally and emotionally. Monitor the degree of change you are expecting of your business to ensure your objectives are realistic and achievable.