PMI®’s PMBOK® 8th edition states what has long been true in most organizations: the PM is responsible for creating value from project deliverables. So, an early task for the PM is defining effective measurement criteria. Read on for tips on doing that.

Two things to keep in mind:

1. Outcome-based value measures and how you will compile them is vital to success.
2. Results can take months to appear, so success criteria need to support a long-term view.

What you can do:

• • Focus on the organization change that’s intended to create value. This sounds simple, but frequently project success measurements don’t get to the heart of why the project was launched. For example, the number of help desk calls is not a good measure for changes in customer issues. Help desk calls might increase due to a significant increase in sales, rather than more customer issues. Success measurements should relate to things like increases in sales, production throughput, or market share; decreased costs; or customer experience.
  • Use early indicators for longer-term value items. When project value takes a while to measure, like cost savings that show up in the next quarter results, identify other measures that indicate whether the project is on the right track. For example, track adoption rates of updated processes, or observe stakeholders using a new business process to see if efficiencies are being realized.
  • Convert subjective value items to objective indicators of success. In the PMBOK 8th edition, PMI places more emphasis on value that can’t be measured directly, such as an increase in market’s or community’s positive view of the organization. That increase can’t be directly attributed to an increase in sales of a product. Instead an objective indicator, such as a survey asking “Does the recent news on Company X increase your likelihood of buying products from them?”
  • Define interim measurement points. Suppose a project has an objective of decreasing costs by 10 % across 15 manufacturing lines. The complete measure of success can’t be determined until the improvements are implemented across every line. But you can get an early impression of cost reductions by measuring after the changes are made on the initial manufacturing lines.
  • Get sign-off for the measures, the process, and the expected timing for success. It is common practice to get sign-off on project success measures. Consider also getting sign-off on the processes for measuring value creation, and the timing for overall and interim project success data points. This reduces the risk of misunderstandings about when and how business value will be realized.
• Note: Whenever possible, define baseline values for your measurements so you can compare before and after values to see whether the success criteria were met.

Are the success criteria on your current project truly measuring what matters most? If not, try these tips for measuring value creation.

Coming Up

Production work on my Project Management Foundations course is moving along well. I’ll be reviewing the entire course in a couple of weeks with publication soon after that.

_______________________________________

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

_______________________________________

A good testing process identifies the types and causes of errors originating during development. Understanding the root cause of these errors can reduce errors in future projects. Here’s what to look for to improve future performance through reduced errors:  

• Patterns. Development process weaknesses lead to repeated errors across projects. Look for trends in the types of errors found in testing. With that info, identify root causes in the development process to correct through process improvement.
• The why, not just the what. Understanding what caused an error is the first step. But genuine learning and improvement come from understanding why an error slipped through the development team’s preliminary testing. (It could also indicate the development team did not do proper preliminary testing at all!) Dig deeper into the why to find ways to improve the development process.
• The value business analysts can bring when involved in testing. Good BAs can note the type and causes of errors and use that information to improve requirements definitions. For example, if trends in errors related to a device’s data output are identified, future requirements can be written to avoid those output errors.
• Root cause thinking, so you can reward it! When teams know that root cause analysis will be conducted alongside the testing process, it motivates them to improve. Nobody likes to get called out or have their approach create errors. Recognizing and encouraging root-cause thinking can improve not only the development process but also other processes that produce project deliverables.

Does your testing process identify these points? If not, think about how to add them to your testing processes.

Coming Up

I finished recording voiceovers for most videos in the new Project Management Foundations course. Recording live action is coming up. In the meantime, I’m working on video storyboards. A few weeks away from LinkedIn Learning taking over production work!

_______________________________________

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

_______________________________________

Quality expectations drive the effort that the project team must commit to verifying project deliverables and outcomes. If you skip the conversation about quality standards, you’re just guessing what “good enough” means for the project. In other words, if you don’t know the needed level of quality, you won’t know how much verification and testing you need to meet stakeholder expectations and requirements. The discussion and documentation of quality standards connects stakeholder needs, project activities, and verification/testing effort that contribute to satisfying the project purpose. Here are some tips for managing a project with a quality standards mindset:

• Document both requirements and the tolerance for error in quality standards. Effective descriptions of quality come from understanding what deliverables need to do and how much tolerance stakeholders have for something going wrong. For example, a word processing program and an air traffic control system can both be called software, but they come with vastly different expectations of quality.  Meet with key stakeholders early on to ask them what failure looks like and what the risk would be.
• Use the required quality level to determine activities in the WBS. More rigid quality requirements mean more design reviews, testing activities, and potentially sign-offs built into the schedule. On the other hand, higher tolerance for unexpected outcomes means the team can move faster and skip some testing and verification activities without increasing risk. A best practice is to review each quality standard and make sure that verification and testing tasks in the WBS are at the right level to build to, review, and test against those standards.
• Allow fewer verification tasks for low-risk deliverables to increase delivery velocity. When the cost of an error is low, such as a minor bug in a word-processing feature, teams can engage in lighter testing. That way, the project manager can purposefully calibrate verification activities to the actual risk. For example, with tight deadlines, identify lower-risk components and make sure the team doesn’t over-test their deliverables. 
• Ensure high-risk deliverables get rigorous verification before delivery. Air traffic control software is a clear example of a high-risk deliverable. An error isn’t an inconvenience; it’s a potential catastrophe. This level of consequence justifies extensive performance verification, redundant testing, and formal sign-off before release. The extra time and cost for these tasks aren’t overhead; they’re mandatory for managing risk. In addition, for all high-risk deliverables, schedule independent verification rather than relying solely on team-level testing.

Have you defined quality standards for requirements and deliverables in your projects? If so, have you evaluated your WBS to see if you’ve included appropriate tasks for verification and testing? If not, give it a try!

For more about quality, check out Daniel Stanton’s Project Management Foundations: Quality course.

Coming Up

I finished recording voiceovers for most videos in the new Project Management Foundations course. Recording live action is coming up. In the meantime, I’m working on video storyboards. A few weeks away from LinkedIn Learning taking over production work!

_______________________________________

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

_______________________________________

Have you ever had people pitch an impractical project idea? You see lots of issues, but the idea hangs around like an overly friendly albatross. Maybe a senior leader is convinced it has merit but doesn’t understand the practical obstacles to delivering business value. Or people think delivering the project would be easy, but the project reality is chock-full of risk.

Here are some things you can do to handle this situation:

• Don’t say no. It typically isn’t the project manager’s place to say no to a project idea. If you did, you would be seen as an obstacle. Don’t take yourself out of the game.  
• Gather and present the numbers. Instead of saying no, perform due diligence. Gather initial estimates, assess the probability and impact of significant risks, and gather project histories for what has worked and not worked in the past. This fact-based evaluation, with projected costs and potential benefits, will show the project as viable or folly.
• Compare your findings with AI results. Prompt your AI tool to obtain costs, durations, and issues that similar projects have experienced. After verifying the AI results, you might have strong evidence that the project is impractical or feasible.
• Seek to understand the urgency. A project idea that won’t go away might come from a deep-seated concern or a perceived opportunity, especially when the idea persists despite numbers that don’t tell a good story. Determine what’s motivating the person’s passion for the idea. With this insight, you might be able to suggest an alternative project that addresses the motivation but with a more compelling business case.
• If the sponsor says go, support the project, and highlight risks. Senior leaders have the prerogative to take a risk if they consider it appropriate. As project manager, you can’t say no. Instead, clearly communicate the risks the sponsor is taking and suggest strategies for mitigating them. Be especially diligent about risk triggers and manage the project as confidently as possible. Taking risks can lead to great outcomes, so keep an eye out for opportunities to realize business value.

Coming Up

I finished recording live action videos for Project Management Foundations course last week.  A couple weeks away from LinkedIn Learning taking over production work!

_______________________________________

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

_______________________________________

Most project risk conversations focus on what’s happening internally, like scope, resourcing, and schedule constraints. But some of the biggest threats come from outside the business, from people and forces you can’t control. Here are some external risk areas that can catch even experienced project managers off guard. 

• Vendor and supplier lead times. When you’re relying on external contractors to start work at a specific milestone, their lead times could change significantly. The six-week lead time they told you in January could become ten weeks by March if their capacity shifts, and they’re unlikely to tell you about it unless you ask. To avoid surprise delays, communicate with vendors regularly and review any schedule changes.
• Third-party approvals and permits. Legal reviews, building permits, and regulatory signoffs are outside of the project team’s control and can completely stall a project. The mistake is treating permit approvals like a task you can manage, when really this task is sitting in someone else’s queue. Do research to identify regulatory lead times, ask about current lead times when establishing the project schedule, and build in a time buffer for any regulatory approval task.
• Outsourced IT and infrastructure changes. Technology support and maintenance changes, like network upgrades, system migrations, or applying security patches, often occur on a fluid schedule.  These activities can break assumptions that your project schedule depended on. An IT planned server maintenance window you didn’t know about could wipe out the weekend of work time you counted on to catch up on delayed tasks. To avoid this type of surprise, work closely with all support teams to  make sure the latest infrastructure schedules are reflected in your project timeline.
• Currency fluctuations. Currency swings can affect international projects or those that require components purchased overseas. A project that met business justification parameters in Q1 can look very different by Q3 if currency fluctuations increased your actual costs. Make sure you have risks and contingency funds set aside for unexpected cost changes.
• Product delivery charges. Schedule delays might require expedited shipping to get back on track. This could mean unexpected charges from the transport vendor. Make sure you have risks and contingency funds for shipping cost variations.
• Weather and seasonal factors. Weather impacts are obvious for construction projects but are easy to overlook in other projects. Shipping delays around holidays, staffing gaps during flu season, and office closures for weather events are easy to forget in contingency plans. Make sure your project has the equivalent of flashlights and rain gear baked into the plan!
• Partner dependencies. Joint ventures, integration partners, and subcontractors on someone else’s payroll can help your project but add the risk of lack of control. Partner’s internal politics and priorities become your risk the moment project work depends on their delivery. A partner reorganizing their team midstream can quietly reset the project timeline without any official notice. Ensure a balanced benefit and risk analysis is performed when the project depends on partner behaviors.

Take a recent project of yours. Did any external risks come up? Even if they didn’t, think about whether the project could have faced an external risk. Here’s a great place to use AI: ask your favorite tool to provide you with possible external (and internal) risks that your project might face!

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

Coming Up

I finally finished updating the scripts for the Project Management Foundations update! My office is set up for recording, and the sample video is waiting for feedback from the LIL production team. I’ll be recording voiceovers as you read this.

_______________________________________

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

_______________________________________