Posts

Can you have too much authority as a project manager?

/in /by

Bob McGannon and I talk about whether a project manager can have too much authority. We also talk about what to do to make sure everyone understands the authority the project manager does have.

https://youtu.be/oz7ydHpboVc

A tip for introverted project managers: Your team probably likes you that way.

/in /by

Many of your team members are introverts. Engineers, developers, technical folk of all ilks tend to introversion. They usually want clear, rational reasons why the project is important and how they fit into the project picture. They almost always dislike sales pitches and hype.

As an introverted project manager, you are probably most comfortable organizing the project environment and making sure the work gets done. You also understand the importance of the project, the makeup of the players, and lots more. You are the perfect person to help your team members grasp the info they need, because you can talk in their language.

What’s more, you don’t have to be a cheerleader to lead a team. Introverts can inspire and motivate people just fine. Think leading by example. Or guiding and growing your team members behind the scenes. (As an introvert, you’re likely to manage people with a lighter touch than extroverts use.) And using thoughtful, yet powerful persuasion to convince people at all levels to do what’s needed.

To learn more about leading, check out the courses in the LinkedIn Learning Become a Leader learning path.

Using milestones to track progress

/in /by

Tracking project progress is part of a project manager’s job. Gantt charts aren’t always the best way to report progress–they provide too much detail for busy leaders. Using milestone charts are better for reporting progress. Here are my recommendations.

  • In your project schedule, create at least 2 milestones per reporting period. Capture dates the milestones were completed and share the rationale for early or late completions. The milestones don’t have to be significant events, just tangible partial or full deliverable completions. If necessary, break down longer tasks into shorter ones to allow for these milestones.
  • Don’t abandon the Gantt chart! Manage your schedule and share details with a Gantt chart. It’s your best management tool. Use it whenever detailed tracking information is requested.
  • Create “super milestones” for major project events. Identify significant events with milestones in bold or capital letters. Use these to share high level progress. Continually track planned dates, and revised projections for completion of super milestones to show overall progress.
  • Update your milestones as the project progresses. As task completion actual dates can vary your schedule, ensure you continue to have 2 milestones per reporting period. Add new milestones if necessary. Also, add or revise dates for all your milestones as any project change requests are approved and added to your schedule.

Tracking progress isn’t the traditional way to apply milestones, but they create two levels of project tracking detail with minimal additional work. Share your intent to use milestones for tracking with leaders, especially if they have only seen milestones used for significant events.

To learn more see the “Learn to use milestones” movie in my course Project Management Foundations.

ProjectManager.com goes into more detail about what you need to track project progress. Check out Project Tracker: The Ultimate Guide for another take.

Should I pad my estimates?

/in /by

Q: Everyone tells me to pad my project estimates. Should I follow their advice?

A: No! You should share your best, most accurate and non-altered estimates with your sponsor. Padding your estimate is adding contingency without justification. Be transparent. Share estimates with your sponsor, emphasizing that they don’t include contingency.  Then, share your recommendations for how much contingency to add based on specific risks associated with the project.

For more on project management, check out the Become a Project Manager Learning Path at LinkedIn Learning.

What’s the best style for a project manager?

/in /by

Bob McGannon and I talk about project manager styles and the best one to choose in this video

To learn more about project management, check out the Become a Project Manager learning path at LinkedIn Learning.

Can there be too much collaboration on a project?

/in /by

Collaboration is gold in projects. Collaborative stakeholders produce better requirements, provide support for your solution, and rarely raise issues when accepting deliverables. Even with these benefits, there can be too much collaboration. Here are symptoms of too much project collaboration and how to correct them:

  • You have more stakeholders than necessary. Environments that are extremely collaborative can bring a wide variety of hopes, expectations, and opinions – more than needed for success. When many stakeholders want to collaborate, assign primary stakeholders and secondary stakeholders (more like interested parties). Restrict project authority like submitting formal requirements or decision-making to your primary stakeholders.
  • Decisions take too much time.  As stakeholders seek to include others, decision-making can get dragged out. While including everyone can help produce better decisions, timeframes for reaching those decisions can be too long. Lack of consensus can cripple a project. To address this, include review time and decision-making tasks in your project schedule. Emphasize when decision-related tasks are on your critical path and discuss the impacts of extended decision-making time.
  • Scope increases. As stakeholders participate in requirements sessions and your solution comes to fruition, new ideas for adding business value can arise. The more the collaboration, the more this will occur! While business value is a good thing, your scope might grow beyond your “minimum viable product.” Ensure your change approval process focuses on limiting project scope to what’s needed to deliver business value. Remind stakeholders that Phase 2 of the project can be evaluated and cost-justified to accommodate the new business value ideas.
  • It’s difficult to get approval to proceed or implement your project deliverables. If you hear lots of “it’s ok with me, but please check with x” responses, you may have an approval process issue. Ensure you have agreed upon processes for approvals built into your Project Charter, including who has final approval.

To learn more, see “How organizational culture affects projects” in my LinkedIn Learning course, Project Management Foundations.

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.