Archive for category: Project Management

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.

_______________________________________

Agile planning involves allocating an amount of money (or time) to produce functions that deliver business improvement. When that time or money runs out, the project ends unless a business case to continue is made and approved. There are other situations, though, when an agile project should be stopped – even one that appears to deliver business value:

• Priorities should be changed. Although the project might still be making a positive contribution, those contributions might have decreased in importance to the organization at this point. If other initiatives are poaching skilled technical and user team members, assess THIS project’s contribution relative to other initiatives. It might be best for the business to stop this agile project to allow skilled team members to focus elsewhere.
• The primary business problem or opportunity has been addressed. Projects are launched to deliver value and specific changes. Once the value and changes are realized, user and sponsor interest might wane. Indications of this lack of interest can show up as inconsistent meeting attendance or features not being completed within prescribed sprints. Review the project to determine whether work should be stopped.
• Technical debt is increasing. When there’s pressure to deliver value, taking little shortcuts is common. Add code without comments, skip some testing scripts, or install a bit of code that doesn’t quite fit into the overall solution design. Is this the wrong thing to do? Maybe, maybe not. What these shortcuts do is create technical debt, that is, an accumulation of work that needs to be addressed downstream. If this starts to happen more often, the team might be working beyond their current experience and capabilities to deliver value and creating issues in the process. When this occurs, it’s time to address technical debt and close the project. Evaluate whether the right skills – and business case – are in place to continue.
• Benefits rationalization is increasing. When agile projects are launched, features in the backlog typically have a clear-cut purpose and business case. As the original backlog is completed and new features are added, the business value for those features can become a bit fuzzy or be based on broad assumptions. This rationalization of benefits to produce more features can be a waste of time because they don’t deliver solid value. In addition, maintaining them downstream can add unnecessary complexity and financial burden.

For more about agile projects, check out Doug Rose’s Agile 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 104,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.

_______________________________________

In most projects, the primary stakeholder is the sponsor. For projects in regulated environments, the regulator becomes an equal, maybe even the primary stakeholder. Here are six actions to consider when your project runs in a regulated world. 

• Make sure you completely understand relevant regulations. Regulatory compliance is a deliverable! To successfully deliver that compliance, the PM and team members need to grasp all aspects of the regulations and what is needed to satisfy them. This understanding helps when talking with key stakeholders and senior leaders, too. Their confidence in the project increases when you’re able to describe the regulations clearly and accurately and what needs to be done to address them.
• Understand the difference between regulated output and regulated processes. Make sure you know what you can and cannot change. Some regulations address the required output and the processes used to create that output, such as with new drug development and testing. In other cases, accurate reporting is regulated, but the processes to generate those reports aren’t. People in regulated environments often assume that the processes to produce regulated output are also regulated. As a result, they might overlook valid and efficient process changes. 
• Designate a compliance owner(s). Choose a team member to coordinate the interpretation of regulations, track organizational obligations, and monitor compliance-related risks. A business process and legal expert is typically the best person for this role. For larger projects, consider appointing more than one owner. If you have more than one, make sure the responsibilities of each owner are clear so you don’t create overlaps or gaps in compliance monitoring.
• Treat testing as mandatory. Testing is often reduced to decrease duration when the project schedule is tight. However, in regulatory projects, the deliverables need to demonstrate control, traceability, and conformity. Thorough testing is the only way to do this. Reduced testing in these projects is high-risk.
• Assume a regulator will audit your records. Keep thorough and detailed project records throughout the project lifecycle. Those records could become evidence in an audit to confirm regulatory compliance. Solid project records are fundamental to demonstrating control, which auditors will use to identify how your project and organization plan to comply with the regulations.
• Consider regulator assistance if feasible (they are a stakeholder)! One way to ensure that regulations are understood and followed is to involve regulators throughout the project. They can review solutions, propose test scenarios, and examine processes and data stores to ensure compliance in advance. This can save time and money and promote goodwill with regulators.

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 104,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.

_______________________________________