Archive for month: June, 2026

Teams that work cohesively and understand both the business and technical ramifications of their tasks are a big part of producing successful projects. Explaining business relevance of work to team members can be tedious. No worries! Here’s how to do this without taking up too much project time:

• Assign technical team members to shadow the people whose jobs will be impacted by the members’ task outcomes. Shadowing not only shows the relevance of the task; it can also generate other business improvement ideas the team can pursue. Note: Review those new ideas with diligence and leverage a change control methodology to avoid scope creep.
• Review mission statements of affected departments. The business goals and priorities outlined in a department’s mission statement often help project team members complete their tasks with the business in mind. After reviewing the mission statements, hold a follow-up discussion between business and project team members to ensure they understand the department’s current approach.
• Attend business team meetings or ask the business team to attend sprint sessions. That way, specific business objectives and current shortfalls can be discussed, along with technical options for how systems might work. It can also strengthen the relationship between the project team and the business, yielding benefits in this and future projects.
• Include the desired business outcome in task descriptions. Instead of just describing a task as “Fix the data validation bug,” add a description like “Address the issue that customers abandon checkout at a 12% higher rate because of this bug.” When team members understand the objectives, their decisions will better align with the business’s desires and direction.
• Use process maps to show how technical components and business value align. Embrace the approach business analysts use to figure out project requirements. Don’t just create text versions of project requirements. Put them in graphical form, showing the ties between technical tasks and business requirements. Place these maps somewhere visible and refer to them in conversations. When someone asks why something is a priority, it serves as a quick reference to answer the question.

Have you used any of these approaches? If so, what was your experience with them? If not, can you see using any of them in your current PM approach?

For more about business goals and objectives, check out my Project Management Foundations course.

Coming Up

I’m starting to work on updating a couple of my projects. Stay tuned for more info!

_______________________________________

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

_______________________________________

An organization’s risk tolerance influences decision-making, resource allocation, and stakeholder alignment, so you need a clear understanding of how much uncertainty the organization is willing to accept.

How you plan and communicate a project will differ depending on whether the project risk fits within the organization’s risk tolerance. As risk increases, discussions about risk are more important and more frequent. Plus, you will track risks more carefully and communicate more. Maybe you ask for more contingency funds. Dare I suggest, you might ask whether the key stakeholders really want to do the project. If risk level can’t be compromised, you need to lower the project risk level before moving forward.

With so much riding on risk, here are approaches for assessing an organization’s risk tolerance.

• Review past project decisions and outcomes. Review how the organization handled past uncertainty, including whether risks were avoided, mitigated, or accepted. This indicates how leadership responds to project setbacks. Note: Don’t trust risk plans that don’t describe how risks were addressed, which means the plan wasn’t revised as the project was executed. As a result, the risk impacts or lack thereof were likely not documented.
• Engage key stakeholders. Use structured interviews to identify risk perceptions, priorities, and thresholds. Note the differences between senior leaders, sponsors, finance representatives, and operational teams. These stakeholder groups often have differing perspectives, but you need to explore conflicting impressions in more detail. For example, senior leaders might consider a risk category as low, while operational personnel identify significant issues in the details they manage. Conduct a process review to resolve these conflicting opinions.
• Analyze financial indicators. Examine the management reserves allocated for past projects. Organizations that operate on tighter margins or under strict cost controls tend to have lower risk tolerance. Look for the areas of greatest concern, such as raw material costs, manufacturing, or distribution. In a software development environment, you can assess risk tolerance by looking at the willingness (or resistance) to contract highly skilled personnel or the thoroughness of testing prior to software release.
• Evaluate governance structures and approval processes. The more reviews or signatures required to approve a document, the lower the risk tolerance. Highly regulated organizations or those with a strong hierarchical philosophy typically have lower tolerance for ambiguity and require lower risk approaches to approve a project launch.
• Use a formal risk assessment framework. A good framework will rank risk on a scale of 1-5 and have a pre-determined cut level for acceptable risk. For example, acceptable projects have a risk rating of 2 or lower. Any projects above that level must be restructured to reduce risk before approval. This framework provides a direct measure of the organization’s risk tolerance. Once you quantify risk impacts and probabilities, compare the resulting risk level to the organization’s framework. Note: If more risk is required to achieve strategic outcomes, discuss the situation with project sponsors to see what they want to do.  

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

_______________________________________

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

_______________________________________