Sponsors have to make critical decisions that can affect both the project and the overall business. But not all project sponsors are ready for this responsibility. As a proactive project manager, you can help. Here’s how: 

• Anticipate when decisions are needed. The more time you give a sponsor to ponder the decisions they need to make, the better. That way, they can tell you the data and help that they need to make a confident decision. And you can develop data collection processes and schedule time to review data to ensure it accurately reflects the project situation. 
• Sort through facts, intuition, and conjecture. Major decisions often require significant input. To help the sponsor sort through the information they receive: confirm facts, identify when a viewpoint comes from intuition, and when the info shared is someone’s conjecture or assumption. This effort can sometimes help the sponsor confirm assumptions.
• Identify the sponsor’s preferred data sources. Project sponsors usually have favorite data sources, for example, internal trusted advisors or external entities like consulting companies. It’s good practice to proactively ensure the input from these sources is incorporated into the decision-making process.  
• Inform the sponsor of the decision pros/cons, including affected stakeholders and business processes. Sponsors might make decisions without fully understanding the impact on all business areas and stakeholders. To address this, it’s best to proactively summarize detailed pros and cons when you present options. That way, your sponsor can use them to make informed decisions.
• Anticipate decision timing impacts. Tell the sponsor about potential timing factors to consider. For example, delaying a product purchase decision until shortly before accounting year-end might mean a lower price. Conversely, purchasing a product earlier, though more expensive, might allow project staff to spend more time learning how to best deploy the product.
• Maintain psychological safety.  Project managers should consider what constitutes psychological safety for themselves and then provide the same to their sponsor. That way, the sponsor will probably feel less stress about their decisions. For example, if you disagree with the sponsor, share that information calmly without being judgmental. Share the risks, saying that this information comes from your experience. Unless it is an extreme situation, reassure the sponsor that you will support their decision regardless of the one they make, given they understand the risks.

Do you have an example of how you’ve supported a sponsor’s decision-making? Share with us in the comments.

For more about working with sponsors, check out this Office Hours with Antonio Nieto-Rodriguez.

Coming Up

Whether you’re a manager aiming to lead more effectively or a team member feeling stifled by excessive oversight, this conversation is for you. Join Julie Robinson and I for Office Hours on Tuesday, September 23, 2025 3pm MT, 5 PM ET where we will talk about how to improve performance by reducing or eliminating micro-management.  We’ll discuss how to recognize signs of micro-management, whether you’re dishing it out or receiving it. If you’re a manager, you’ll gain insight into the why of this behavior and what you can do to become a more empowering leader. Team members will discover strategies for regaining autonomy. You’ll come away with a handout from Julie with tools and resources to support lasting change. Click here to join!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 97,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.

_______________________________________

Filing project documentation in a shared folder named “Repository” doesn’t cut it. An effective project repository is designed to maximize value. It can increase foresight and provide valuable information in project deliverables such as the risk plan. Here are the characteristics of a well-designed project repository.

• Provides information to solve recurring issues. Designers base how they organize and present information in their project repository on specific challenges the organization faces during project delivery and they ensure that the repository holds project data that helps to improve outcomes in future projects. For example:
  • If estimation is difficult, create common names for frequently used tasks so you can track time and risks for those tasks over many projects and improve performance over time.
  • If risk planning is incomplete, compile risks from reported issues and create an initial risk list with response strategies.
  • If contractors are often used, collect detailed performance and cost information by company and by individual consultant.
• Includes a powerful search function, indexed with commonly used terms. This makes it easier to find data without reviewing extensive lists. Common terms include terms regularly used in the organization’s project management methodology as well as typical industry terms. For example, “project charter” will be used universally for the document to launch a project. “Pour the foundation” might be a common activity description in construction, while “unit testing” might be used for information technology projects.
• Organized with clearly defined and consistently applied folder hierarchies (i.e., by project phase, document type, activity, or discipline). While a search function allows for specific data reviews, folder hierarchies enable project managers to review multiple project examples. For example, say a project has a task to prep a roadbed before paving. Various approaches for laying the roadbed, the time taken, and the risks that surfaced could be viewed by looking at histories from several projects. Phases allow project managers to review best practices and standards for closing a project, for example. Cataloguing data by discipline allows for the review of multiple procurement plans to determine the best fit for an upcoming project.
• Managed by an administrator to maintain status, naming standards, and version control with a focus on continuous improvement. A repository must be clean and easy-to-use or project managers won’t use it. When a repository is used regularly, new ideas for data to extract are generated routinely. Administrators can deploy these ideas to add indexing, massage existing data, or collect additional data to satisfy data requests and improve project delivery.

How do you set up your project repository? Share your tips and tricks with us in the comments.

Coming Up

Whether you’re a manager aiming to lead more effectively or a team member feeling stifled by excessive oversight, this conversation is for you. Join Julie Robinson and I for Office Hours on Tuesday, September 23, 2025 3pm MT, 5 PM ET where we will talk about how to improve performance by reducing or eliminating micro-management.  We’ll discuss how to recognize signs of micro-management, whether you’re dishing it out or receiving it. If you’re a manager, you’ll gain insight into the why of this behavior and what you can do to become a more empowering leader. Team members will discover strategies for regaining autonomy. You’ll come away with a handout from Julie with tools and resources to support lasting change. Click here to join!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 96,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.

_______________________________________

At a project start, there are things you won’t know, so you have to make assumptions. While management considers whether the project business case is worthwhile, practical and reasonable assumptions can make the difference between a project launch and “a good idea, but.” Here are some ways to differentiate useful assumptions from the ones to avoid.

Useful

• A high probability of being valid. Accurate and easily verified project assumptions are very useful. Example: You assume that a specific contracted skill is available. A call to a trusted vendor can provide informal verification to confirm the accuracy of the assumption. That’s followed up with a formal request. The contract with the vendor later commits to the skill availability. 
• Enable initial costs to be estimated. Estimates are part of every initial go/no-go decision. Carefully craft assumptions that can support informed financial decisions.  Example: The assumption about a contracted skill should define the role so a vendor query would provide an approximate hourly or daily rate. This approximation would validate the assumption and support estimated costs.
• Limited in scope. Useful assumptions address a narrow aspect of a project, rather than a broad prediction of project outcome. Example: An assumption about cost for tooling to maintain a new manufacturing line is appropriate. An assumption of the entire cost of a project to build a new manufacturing line isn’t helpful. There are too many elements contributing to the total project cost, making it impossible to predict anything with confidence. 
• Supported by project histories. Useful assumptions are based on facts. If the time to produce a project deliverable has been consistent in the past, it is low risk to assume that timeframe for a new project. Example: Even when building an entirely new manufacturing line, preparing the floor and power drops for that line might be like past buildouts. So, you can assume the buildout timeframe in the preliminary plans for a new line. If an assumption isn’t supported by history, it’s time to document the risk and use wider ranges for estimates.
• Stakeholders understand and support the assumption. Stakeholders have to understand and support assumptions when participating in project go/no-go decisions. Additionally, with assumptions related to stakeholder performance, it enables them to help make the assumption a reality. Example: You might assume a key stakeholder’s availability to support project completion within a constrained timeframe. If stakeholders are aware and understand that assumption, they can strive to ensure that the skilled resource is available

Not useful

• Speculation that can’t be proven without completing the project. Assumptions regarding items such as customer acceptance of a new product, made without surveys or other market research, are pure speculation and carry high risk. You can determine market acceptance only by completing the project and releasing its product. Example: You assume that new electric toenail clippers will be in high-demand without any customer outreach, and launch the project anyway. Note: Innovative product development often proceeds without surveys, because sharing a novel idea with the marketplace early would hurt competitive advantage. These projects are always high-risk, but when the project’s product is broadly accepted (like the iPhone), the rewards can be significant.
• Opinions are the basis of an assumption. Opinions are often based on gut feelings, not on fact, but they can be expressed with passion. Question proposed assumptions and evaluate whether the accompanying passion hides a lack of factual basis.
• Based on old or incorrect data. Assumptions based on incomplete or outdated facts aren’t useful. Confirm the facts behind a proposed project assumption! Example: Stakeholders propose that new robotics will increase manufacturing line output by 300%, based on their experience, and want that applied to a new project they proposed. However, that productivity increase is achieved only when one raw material is used, and the new manufacturing line in the current project will require three raw materials. 
• Require “ideal conditions” to be accurate. Overly optimistic assumptions can mislead stakeholders. Example: There’s an assumption that construction completion can be achieved within 4 months. However, this can be valid only if there are no weather delays, all materials are delivered on time without defects, and none of the construction crew members fall ill.

Review some assumptions from a current or recent project. Find any that meet the not useful criteria. Think about how you might turn them into useful ones.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 95,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.

_______________________________________

High-performing project teams embrace continuous improvement. And continuous learning is the core of that mindset. Here are tips for developing a learning environment in a project that enables continuous improvement and long-term performance.

• Allow for experimentation. New tools and approaches can produce significant changes but deploying them can be a challenge. You can get better performance and improved business results when you allow project team members to experiment without excessive deadline pressure. This is easier said than done. You have to include time for experimentation into your plans and then defend those plans with key stakeholders. Note: To gain approval, discuss the potential for significant improvements and also create alternate plans in case the team’s experimentation doesn’t work out.
• Focus on “what did we learn?” rather than blame. Setbacks occur in every project. To enable learning, focus on what led to the setback, rather than who was at fault. Identify training and processes that could help avoid setbacks, or look for ways to learn from them. This positive approach embraces what makes learning organizations productive.
• Make mentoring a high priority. In learning organizations, leaders support project team members by sharing their background and experience. Pair team members and leaders carefully to maximize the value the team member gains from the interaction. Schedule meetings regularly and follow through with those meetings. Don’t treat them as a “when time is available” exercise. 
• Offer plenty of formal and informal training opportunities and don’t create time constraints. Make sure that training opportunities are available. Build them into project schedules, so taking a course doesn’t put team members under time pressure to deliver their project tasks. Provide training in many forms, including lunch and learns, accredited training courses, and online tutorials, to maximize their availability and applicability. Note: Not all training needs to relate directly to the team member’s current project. Learning organizations take a longer-term approach to expanding team member skills. That way, they can increase their capabilities for current and future projects.
• Maintain an organized, formally administered project data repository. Learning from past projects is key. Learning is sporadic at best without an efficient way to reference historical project data. Have an administrator collect lessons learned, categorize them, and provide guidance for finding and retrieving information.

Many project managers won’t have the authority to deploy all these approaches. You can adopt some of them.  For example, you can probably create a lessons learned repository, ask leaders to spend time with a promising team member, mentor team members yourself, and hold your own lunch and learn meetings. 

Take stock of your project environment and see where you can fit in more learning. Gauge your authority and perhaps push the envelope a bit with your project sponsor.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 95,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 reporting often uses traffic light indicators (green-yellow-red) to present status. The colors usually represent variance of actuals from the baseline plan. This article describes how to associate percentage ranges with traffic light colors for several project conditions.

Quick refresher on traffic light status: Green means all is well. Yellow indicates caution. And red is danger, danger! Green might be less than 2% over schedule. 2% to 5% over schedule is yellow. And greater than 5% over schedule is red. 

Here are ways to set traffic light indicator ranges for different purposes.

• The priority of the triple constraints. Each project will prioritize the standard constraints of cost, time, and scope. If you must make changes to meet a government legal compliance mandate, time and scope will be critical to avoid legal penalties. In a market where the organization needs to stay ahead of the competition, scope might be a top priority, so the product stays best-in-class. If delivering a project for a client on a fixed-fee basis, cost can become the highest priority. For example, if there’s a penalty for missing a compliance deadline, you would set up a traffic light indicator for schedule variance with a low percentage for red, such as greater than 2%. 
• The consequences of missing critical constraint targets. The time and scope percentages could be broad (5% to 10%, for example) if the organization only pays a $10 penalty for a missed legal compliance mandate. On the other hand, with a $10 million penalty for a missed government deadline, the time and scope percentages should be narrow (0% to 1%), because you don’t want to miss that deadline. The red light comes on with the smallest slip in schedule, so you have early warning to work on getting the project back on track.
• The team’s familiarity with the tools and processes they use. When the project team is familiar with the context and tools they will use, narrow traffic light percentages are reasonable, because the risk of delays from unfamiliarity is low. However, you must factor in the learning curve when new tools or processes are being developed. With unfamiliar new tools and processes, broader percentages are appropriate because the team might spend more time experimenting or back-tracking. Because narrow percentage ranges convey confidence in the estimates, you want broad ranges in this situation, so stakeholders recognize the uncertainty within the project. The broad ranges (5% to 10%) indicate that things might change.
• Industry standards and expectations. Specific industries have generally accepted variances for project constraints. For example, the construction industry utilizes variances to accommodate unpredictable weather patterns (up to 15% in many cases). Manufacturing, which is much more controlled and predictable, often sets percentage ranges no greater than 5%.
• Stakeholder expectations. Organizational history and strategy elements may dictate stricter compliance to constraints, and thus narrower percentage ranges. Alternatively, plan to hold up-front discussions if percentages are broader than usual to explain the rationale for the variance range.

If you use traffic light indicators on your projects, consider whether you would adjust the variance ranges due to the preceding conditions. And think about other conditions that might affect the ranges you choose.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 94,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.

_______________________________________