Posts

I have trouble getting a remote team member to attend meetings. What can I do to fix this other than complaining to their manager?

/in /by

First, find out if higher priority items interfere with the person’s attendance. If so, work with your sponsor to revise schedules or re-prioritize work. Or you can try to find an available replacement for that person.

Also, make sure meetings stay focused and provide project team members with information they need. (This helps makes ALL team members more likely to attend.)

Finally, confirm that your remote team member understands the information they’ll receive and why it’s important.

Should a Project Manager Justify a Project?

/in /by

Q: My sponsor asked me to prepare the justification for a project. Is that appropriate or should my sponsor do this work?

A: The Project Management Institute (PMI) holds the sponsor responsible for project justification. However, sponsors can delegate project-related responsibilities to the project manager. So a PM justifying a project is appropriate as long as the sponsor provides appropriate support. In that case, you should consider the request a compliment regarding your PM skills and trust in your abilities.

Dealing with wanna-be stakeholders

/in /by

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!

/in /by

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

/in /by

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

/in /by

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?

/in /by

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

Creating a positive project environment

/in /by

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

/in /by

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