When do I Share Issues With my Sponsor?

/in /by

Photo by Amy Hirschi on Unsplash

Sharing issues with your sponsor is like walking a tight rope. You don’t want to bother them with trivial matters. But you want them to feel informed. And you never want them to be blindsided. Here are situations when you need to share issues with your sponsor.

  • The sponsor’s confidence is low. Sponsors are afraid of not being in control. They also don’t like to report project concerns to their superiors. To address their fears, give them detailed project status. In status reports, include issues that you are addressing and how. If the project progresses well, your sponsor’s confidence will increase and the need to discuss minor issues will decrease. Use your perception of the sponsor’s confidence to determine which problems you should review proactively.
  • Issues will affect project time or cost. The potential impact of an issue is a good measure of when you need to talk with your sponsor. How do you get this right? By setting a threshold in advance for when the sponsor wants to be informed. Is it when there’s a 1% impact on the budget, 5%, or some other number? Do the same for impacts to your schedule. (The percentages might be different for budget and schedule. Sometimes, meeting the schedule is more critical than staying within budget, or vice versa!)
  • An issue affects a critical stakeholder. Influential stakeholders watch your project carefully and are likely to talk to your sponsor if problems arise.  Prevent surprises by sharing details of brewing problems and what you’re doing to address them. That way, your sponsor will be ready to address stakeholders’ concerns. And it’ll also keep stakeholder follow-up tasks out of your to-do list!
  • You might need a decision. If you have a problem that might require your sponsor to make a decision, tell them about it! For example, let’s say you have problems with a new component and that component is the only way to meet some lower priority requirements. Dropping those requirements from the project might be best, but only your sponsor can drive decisions like that. By sharing the problem early, your sponsor has time to consider options and make the best decision.
  • The problem might affect the sponsor’s critical performance measures. Sponsors and key stakeholders typically have operational responsibilities with measures to assess their effectiveness. For example, a target for the weekly output of a production line. If your project could impact that production line, speak up as soon as possible. That way, the sponsor and stakeholders can work with their operational team and the project to manage business impacts.

As you develop a relationship with your sponsor and confidence grows, you can shift your focus. You can spend more time resolving problems versus reporting on them. Use these guidelines along with your sponsor’s concerns to decide when you should work to solve a problem or focus on reporting it to your sponsor first.

Are there other situations where you share issues with your sponsor? Or do you have questions about how to handle sponsor discussions? Share in the comments section.

For more about working with your project sponsor, check out my Project Management Foundations course.

Use a Product Breakdown Structure for Complex Solutions

/in /by

You probably use a Work Breakdown Structure (WBS) in your projects, but sometimes, it isn’t enough. A product breakdown structure is helpful when you need to deliver a complex solution. A Product Breakdown Structure (PBS) is like a WBS, except it shows product details and how its components fit together. Here are the benefits of using a PBS.

  • It creates a common vocabulary for discussing the product. A PBS uses nouns, versus a WBS with verb-based tasks. The PBS defines the pieces that make up your project’s product. Because projects create unique products or services, you probably need definitions for the solution components. The PBS is where you keep those definitions. It also shows how components fit together. This helps reduce errors due to misunderstandings about what the product is and how it will be assembled.
  • It helps clarify development assignments. The PBS defines the product components, so the skills needed to build the product are easier to understand. It also helps people come up with ideas for product improvements and refinements. A PBS helps your technical team members understand where their responsibilities begin and end. This saves time and potential confusion as the project progresses.
  • A PBS helps identify alternate approaches for building the product. The PBS clarifies what is being built. The process of creating the PBS will help team members come up with ideas for how to build the product, too. It provides different perspectives for how components can be assembled and tied together. It also helps visualize how stakeholders can use the product. Because it shows the tasks you need for construction, it helps you build your WBS as well!
  • It helps identify who builds and tests interfaces. The PBS defines how pieces fit together into larger components. Each component needs to be tested to ensure it works as intended. The PBS spells out component relationships, making testing tasks straightforward. And it’s easier to assign testing tasks to team members. The visual nature of the PBS helps prevent overlooking test activities. Those test activities translate to tasks, tying the PBS to your Work Breakdown Structure. This helps ensure you have a complete picture of the product or service, and how it will be built and tested.

Have you ever used a product breakdown structure? Did you receive other benefits? Wondering how to implement one in a project? Share your tips and questions in the comments section.

Bad Risk Response Habits to Avoid

/in /by

Effective risk management is crucial to project success. Unfortunately, many project managers fall into traps when developing risk responses. Bob McGannon and Bonnie Biafore share some tips for avoiding common mistakes in risk response planning:

  • *Do not* base your risk response on using standard project management tools. Saying that you will address a potential stakeholder relationship issue through your communication plan isn’t helpful. Instead, develop a response that describes how you will work differently with the stakeholder: such as: inviting the stakeholder to your risk assessment meetings or increasing the frequency of status reports to that stakeholder. You can use PM tools as long as you describe in detail the difference from standard approaches.
  • *Do not* omit details. Specifics are helpful when crafting risk responses. They help you examine conditions you need to address. For example, a common risk response is “add more resources.” Sure, that could be exactly what you need, but you need to describe that action in more detail. Specify the resources you need, the skills and experience required, and where you will get them. If you will contract resources, identify the lead time needed to engage those resources.
  • *Do not* create overly generalized responses. Risk responses need to address the risk’s cause and impact. Let’s say you have a project task to transport parts. There’s a risk that the truck won’t show up on time to pick up the parts. Your response could be to keep an extra truck on standby. This would be appropriate if the risk event is a truck breakdown. But what if truck drivers go on strike! Instead, make sure your risk responses are complete by addressing the impact while considering the causes. In this example, the impact is a delay in delivering crucial parts, which requires two risk responses. One for potential truck breakdown and a second for a potential driver strike.
  • *Do not* use extra checking or verification as a risk response. Verification activities show if a risk may happen or is happening. They do not address what you will do if the risk occurs. Instead, create a response that describes the actions you will take to address the risk if it occurs.
  • *Do not* define certain, or near certain events, as a risk. In a 6-month construction project, it will rain at some point. So you need to build your schedule to handle that. Addressing flooding due to excess rain is different, because flooding isn’t a certainty. Likewise, a project team member might miss a few days of work. Your schedule needs to accommodate that. Address short resource absences with scheduled breaks or by including extra time to complete critical tasks. A team member resigning and joining another company is a risk and requires a specific risk response action.

For more about risk, check out Bob’s Project Management Foundations: Risk course. That course and my Project Management Foundations course are both unlocked through December 31, 2025, in the LinkedIn Learning path: Career Essentials in Project Management by Microsoft and LinkedIn to support you in gaining digital skills for tomorrow’s workforce. 

Coming Up:

Leading with Curiosity- How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

The Worst Mistakes PMs Make with Risk- Bob McGannon and Bonnie Biafore are holding a LinkedIn Office Hours on December 19, 2022, at 3:30PM MT (5:30 ET and 8:30 AM AEST December 20, 2022). Join us for an in-depth discussion about developing risk responses.

Have a big job? Use small projects!

/in /by

photo by Anders J on Unsplash

In today’s complex world, projects can become quite large. The problem is large projects are often fraught with issues due to the amount of change they create and the complexity that comes with those changes. Here’s why a series of small projects usually outperform a single large initiative.

  • They deliver value earlier. Small projects finish faster, which means the business realizes value sooner. Organizational change also occurs in smaller bites, so stakeholders can digest new ways of working more easily.  
  • Changes are easier to handle. A series of small projects provides agile-like results. Learning from one project helps the team improve on the next one. Stakeholders learn from using the project’s products, so they create better requirements. And better requirements improve the value the business realizes.
  • Key staff members aren’t as much of a bottleneck. Project assignments often take key operational staff away from their day-to-day tasks. Assigning a critical staff member to a two year project is a challenge. Rolling on and off a series of shorter projects is easier to juggle. That way, you can use internal staff instead of expensive contractors. (And contractors don’t know your environment as well, which can lead to poorer project solutions.)
  • Small projects are less complex and less risky. Smaller projects mean smaller scope. Less scope means fewer new functions, fewer stakeholders, and fewer team members. All these mean less risk to the business. However, a series of smaller projects does introduce a different risk. Changing business priorities might mean later projects in the series could be cancelled so some of the original scope is lost.

Have you divided a big project into several smaller ones? What worked well? What didn’t? Share your experiences in the comments section.

For more about small projects, check out my Project Management Foundations: Small Projects course.

Coming up:

Leading with Curiosity

How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

Helping team members feel like they belong

/in /by

Have you ever been invited to a meeting or office social event and feel like you don’t belong? What about when you finally feel like you’ve found your peeps, tribe, or whatever you call the group you’re comfortable with? A feeling of belonging helps in so many ways and yet it can be elusive. Read on to learn about how belonging provides value and what you can do as a project manager to help foster that feeling in your team members. 

When people feel like they belong, they are more engaged in their work; they are happier and healthier; and they’re a lot more likely to stay in their job. Your team members contribute more to your project: creative solutions that are aligned with the project’s objectives and the organization’s strategy; fewer errors; higher productivity; more enthusiasm. The list goes on.

Belonging is something that employees feel. You can’t execute an action plan to make it magically appear. Humans have an inherent need to belong. Our precursors were far more likely to survive when they belonged to a group. Today, the need to belong is even stronger due to remote work, less in-person interactions, bad behavior kindled by anonymity, and all the uncertainty of our times. How wonderful it is to feel like you fit in.

Although you can’t force a feeling of belonging, project managers can coax it along in several ways: 

  • Tie the project and team efforts to the organization’s mission. People feel like they belong when their values are in line with the organization’s mission — they feel like they belong to something worthwhile and have purpose. Take the time to show your team members how their work supports the project goals and, in turn, how that supports the organization’s mission.
  • Include team members in defining team goals and norms. People are more engaged when they help define their team’s goals. They feel that they have a say in the team’s direction. Helping to define the team’s norms – that is, the behaviors that everyone considers acceptable – creates a bond of shared values with teammates. Are there standard work hours or can people work when they are most productive? What method of communication do people use? How do people behave in meetings?
  • Involve team members in project planning. Contributing to the project plan gives team members a sense of ownership in the project. They also can see where tasks fit in the big picture and how tasks interact, which helps them produce higher-quality deliverables. That deeper understanding might help people spot early warnings that things aren’t going as planned.
  • Highlight contribution by assigning team members their own project tasks. You might assign tasks to technical team leaders, who then assign and manage all the tasks within their area of expertise. While that saves time building a project schedule, you miss an opportunity to emphasize what specific team members contribute to the project. Take the time to determine who will deliver on each task and assign tasks directly to them. Ask them for task status as the project proceeds. This inspires pride in their individual contributions and demonstrates how they help make the project successful.
  • Ask for team member recommendations and suggestions. Feeling needed enhances a sense of belonging. Asking for input during the project shows that you want and value team member contributions. It also boosts morale, particularly when their input helps deliver better project outcomes. You also get a sense of the team’s mood. That way, you can communicate proactively to leverage positive views of the project or reduce negative ones.
  • Assign management-related tasks to team members. Team members can also contribute by checking and reporting on risks. Using their relationships, they can assist with organizational change management activities. They can work with stakeholders to draft new business processes. For more advanced team members, you can delegate project management tasks. This makes them feel valued while also easing your workload so you can work on more complicated project elements.

What helps you feel like you belong when you work on a project? What doesn’t?

For more about belonging, check out the Diversity, Inclusion, and Belonging for All LinkedIn learning path.

Coming Up:

Leading with Curiosity

How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

Five Tips for Building an Effective Project Filing System

/in /by

Photo by Edu Grande on Unsplash

Want a project library that supports your project management practice and makes it easy to find information? An effective project filing system doesn’t have to be fancy and doesn’t require an expensive tool. Simply be purposeful about how you add project data to your system. Here are five tips for mindfully adding artifacts to your project filing system. 

  • A project filing system is for all project artifacts, not just lessons learned. Many people talk about the importance of adding lessons learned to their project documentation. But the most valuable items in a project filing system are plans that can be edited and reused. Project plans that worked well are the ultimate in positive lessons learned! And other project artifacts, like documents, outputs, and deliverables can also be reused on future projects. Be sure to finalize and close out project artifacts before storing them in your filing system. When you do that, you’ll stock a warehouse of project templates to pick from that can save you time and money.

Lessons learned are important. To increase their effectiveness, tie them to specific project artifacts. For example, when you capture a lesson, reference the project task, change request, or risk to which it applies. If you ran into schedule delays because the database administrator was overcommitted, document the tasks that were affected. Or, add a reference to the risk about resource constraints and how those were managed. Lessons can also be about things that went well. Organizing all the lessons learned in your filing system can make future projects more successful.

  • Categorize artifacts by project scope. Artifacts from previous projects are most relevant when they come from a project like the one you are managing now. But finding those projects in a filing system can be a challenge. Try categorizing projects by subject area or scope to make finding useful artifacts easier. (For example, projects that implement new financial procedures or add new functionality to the retail website.)  Classify your projects as you close them out. That way, you’ll expand your ability to reuse project management deliverables and increase your efficiency in the future! (Be sure to compare the scope on a new project to the scope of the past project and adjust for size and complexity, if necessary.)
  • Focus on the triple constraints. Include a summary of your triple constraints in your project records. Files from past projects can help you estimate new ones. They provide benchmarks for costs and project duration. Need a quick answer for a senior leader who asks how much a project will cost? Want to know how long a project might take? Data that can help is in your filing system, as long as the scope, time, and cost data you captured are accurate and detailed.
  • Identify the data you want to get out. Then capture and highlight what goes in. Organizations may have information that they’re interested in that projects can provide. For example, which top vendors perform best on projects? How long do decisions from regulatory bodies take? What items do regulators target when questioning results? Once you understand the questions and data your organization (and other projects) can benefit from, you can highlight that information in your archived project data.
  • Appoint a curator or librarian to manage the project filing system. If everyone threw their data into the system, you could end up with duplicate terminology for the same item or the same lesson archived numerous times. To build a great project reference library, put someone in charge of curating and organizing the data from completed projects. The curator can also develop a guide to the library to help project managers and others track down the info they need.

There is no best way to design a filing system because it depends on your organization, projects, and other factors. That doesn’t prevent us from sharing tips with each other. If you have filing system tips and tricks that you’d like to share, post them in the comments section.

For more about saving and archiving project information, check out my Project Management Foundations (updated October 2022) course.

Project Assumptions: Types and the Risks They Pose

/in /by

Photo by Kaleidico on Unsplash

Every assumption you make for a project introduces risk. By raising your awareness of types of assumptions and the risks they pose, you can make sure that you develop solid risk management plans for them.

  • Initial assumptions are part of every project proposal. When project ideas surface, you must make assumptions to estimate project benefits. In addition, you usually assume that business stakeholders will accept the solution approach. 

These assumptions are low risk because you validate them early in the project. If you’re diligent, initial assumptions can facilitate the early stages of a project without incurring undue risk. You can create a case study to validate benefit assumptions. Paper-based models or simple diagrams can show a proposed solution. Flowcharts can demonstrate how a new business process might work. Or you can build quick product to validate the project solution. 

  • Planning assumptions relate to how you will execute your project. For example, you might have to assume the level of skill required to complete your project. You will validate these assumptions during planning as team members explore potential solutions (and determine whether they are simple or complex.) 

Risks like these are usually manageable — under one condition. The team members doing the planning should not feel pressure to say the project is doable. They should be free to identify complexities without consequences. In short, project planners need to be able to communicate the difficulties the project may face.

  • Fundamental assumptions are resolved through execution of project scope. These assumptions are often necessary. But they are high risk because you might spend lots of money and time before you realize your assumption was wrong. For example, you might want to add functions to a system component that has a response-time constraint. You might have to assume the component can handle the extra workload, but you won’t know that for sure until you build the function and run the component.

For example, architects build models to help customers evaluate the appearance of a building. Once the building is under construction, the customer might not like it and request changes. 

  • Project premise assumptions are the riskiest. These can be validated only by completing the project, for example, building a new product and introducing it to the market. While there were signs the iPad would be successful, there was also criticism of the idea. Only by producing the iPad and having customers use it were Apple’s assumptions validated. Projects with premise assumptions are gambles, so diligence is needed. Conduct as much market research as is feasible.

Bottom line: Make assumptions and follow up on them! We need them to launch our projects. By understanding the nature of your assumptions and when you can resolve them to assess your project risk.

If you have any tips or questions about assumptions, share with us in the comments section.

For more about assumptions and risk management, check out Bob McGannon’s Project Management Foundations: Risk course.

Increasing Your Chances of Project Approval

/in /by

Submitting a project for funding approval can be stressful. Will management give thumbs up or down? Doing your homework and providing critical information is the key to getting your projects approved. Here are the questions to answer to increase your chances of project approval.

How will you meet financial targets? Many organizations have financial thresholds that a project must meet to obtain funding. Others don’t. In either case, understand your sponsor’s financial expectations for the project. Include an explanation of how you will meet financial targets in your high-level project plan.

What skills do you need? As projects represent unique endeavors, you might need to train staff members or hire contractors for your project. Do your homework to identify the availability of internal staff members. Also, determine the lead times you’ll need if you plan to hire skilled contractors. If possible, check with others who have run similar projects. Identify the cost of hiring top-notch contractors. If those costs are high, using internal staff members (even if they would take longer) might be preferable for your organization.

How does your project support your organization’s strategy? Often, projects are specifically designed to support strategy. In other cases, projects indirectly support strategy. For instance, one project might make other strategic projects easier to deliver. Management might not recognize these subtle links to strategy. In your project plan, spell out how your project helps implement your organization’s strategy.

How will you measure progress? It’s important to identify how you will track progress on your project. Also, how you will ensure project outcomes deliver business value. Many sponsors are wary of spending money on projects without a solid promise of receiving business value in return. You can reassure your sponsor and management by explaining how you will assess progress and business value during the project.

How will you transition to new tools and processes? Projects create business change. Create an overview of how you will train and transition project stakeholders to new ways of working. This is important, because new tools and processes can be intimidating. Your overview helps management understand how your approach to gaining acceptance of your project’s business changes.

Do you have any tips for helping obtain project approval? If so, share it with us in the comments section.

For more about obtaining approval for a project to proceed, check out my Project Management Foundations course.

Overlooked Cost of Project Change

/in /by

Change happens! It’s not a bad thing if you control the cost. But some change cost often gets overlooked. Here are costs you should examine before approving a project change request.

  • Cost of additional process decisions and handoffs. Changes might affect the business processes for using your solutions. If decision points are added to business processes, calculate the cost of these steps. For manual steps, include the probability and cost of human error. For automated steps, consider the cost of maintaining and testing technical interfaces.
  • Cost related to more stakeholders. Cost increases are common when you add stakeholders to your project. Additional stakeholders means more communication paths for you to manage. You might also introduce more differences of opinion or feature prioritization issues. This can slow progress for your original stakeholders, which can lead to conflict and — more for you, the project manager, to manage. 
  • Cost of extra technical complexity.  The cost of technical training, application support, and expanded testing requirements can be substantial.  End users need to be trained.  Additional technology increases the cost and time needed to deliver project outcomes. Make sure it’s worthwhile.
  • Cost of managing vendors. Project changes might require contracting with a vendor. That contract cost adds to the total project cost. Also, you must consider the cost of managing the contract. Keep in mind the increased cost of managing multiple vendor contracts, especially when one vendor must work directly with another. You must manage each vendor and control the relationship between them — to ensure you get the proper products or services.

Have you run into cost you didn’t foresee due to project changes? Do you have tips for identifying change cost? If so, share with us in the comments section. 

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

Coming Up

My updated Project Management Foundations course is live! This version includes info about PMBOK7, clarifications to confusing items from past versions, a few corrections, more templates, and a new look.

Is Your Sponsor Ready for Agile?

/in /by

Photo by Parabol on Unsplash

A critical factor for using agile methods successfully is the mindset of the sponsor. With the wrong attitude about how agile works, you might as well forget about using an agile approach. A sponsor who is ready for agile must:

  • Support a “learning organization.”  Learning organizations spend some time on activities that don’t directly create business outcomes. That time is used to develop capabilities within the organization that produce better outcomes in the future. This learning organization philosophy is pivotal for agile. The agile approach is itself a learning philosophy. With agile, you learn, adjust what you produce, and reprioritize features based on the knowledge you’ve gained. You learn about the product as it’s built.

Sponsors must embrace a learning mindset to support agile initiatives. In many instances, agile teams don’t do well at the start, because agile is so different from traditional project methodologies. A supportive sponsor will give teams the time and opportunity on a couple of agile projects to get into the agile flow. 

  • Be open to new metrics. Sponsors with traditional PM leanings depend on Gantt chart schedules, pre-determined risk management plans, and specific milestones to measure progress. They might struggle with agile, because Gantt chart representations and fixed milestones aren’t very relevant to agile projects. Features are produced in a sequence that can change with each sprint. Agile uses measurement techniques like burndown charts and traditional budget management to provide schedule and cost status. Embedded testing and feature validation addresses the need to reduce risk. So, agile is a managed methodology — but it requires a sponsor who is open to different ways to assess progress.
  • Focus on what’s needed, not how to achieve it. Agile is not the ideal approach when you have a fixed set of requirements and details for how the solution will be constructed. In an agile project, you define an objective, and then explore ways to achieve it. It’s typical for direction and approach to change along the way. Sponsors who are uncomfortable with the speculative and explorative nature of agile will struggle with its methods.
  • Be willing to dedicate resources. Agile teams need to make decisions quickly and flexibly to be…well…agile! To do that, knowledgeable senior staff members need to be dedicated to agile teams. Sponsors need to assign the proper team members to agile projects and take other business activities off their plates. If junior staff members lead agile projects, teams might jump to inappropriate conclusions. This can create rework and reduce the team’s velocity. 

If you have experience with agile Projects, share your tips about sponsors in the comments section!

For more about agile approaches, check out Doug Rose’s Agile Foundations course.

Coming Up

My updated Project Management Foundations course is live! This version includes info about PMBOK7, clarifications to confusing items from past versions, a few corrections, more templates, and a new look.