Let me tell you about a project decision that was awkward for me -- then I'll share some tips on how to do decision-making better.

We were due to go live with our pilot software launch but things didn’t feel right. We had the go/no go meeting and as I sat in the office, it just felt like we weren’t ready.

My project sponsor was on holiday in Canada. I emailed him, because I wanted to be told that we were making the right decision.

I got a message back: his hotel had burned down. He and his wife escaped with his phone and her jewelry. He sent a photo. It was bad.

Our executive sponsor was sitting in his office; one of those rooms with glass walls. I knocked on his door and explained why no one had heard anything from my boss and what I thought we should do about delaying the launch. He nodded.

Decision taken. We would delay the pilot.

And… breathe.

Taking the decision was the hard part. The easier part is always implementing that decision – after all, isn’t that what project managers do?

As a project manager, you will be used to making multiple decisions on a daily basis. People will rely on you, often several times a day, to provide guidance and to help make important decisions.

Some of those decisions are straightforward. You just decide a path and move on. Other decisions have broader impact and will likely require additional thought and even input from multiple team members and stakeholders.

All of them are part of the project governance framework.

Some of the most common decisions for project managers are related to cost, scope, resources, and schedule.

In the planning phase there are a lot of decisions to make before a project even starts. If I’m being honest, the decisions never really stop.

However, if we make enough good decisions, especially during planning, it can certainly make our lives easier. Who doesn’t want that?

It’s helpful to have a decision-making process or framework to guide you, especially when faced with complex problems that require additional info from others.

Using a framework is important to ensure consistency in how decisions are made, and to help minimize or remove any personal bias around certain solutions or options that might unfairly sway the outcome.

In this article, I will provide more detail on a framework for making better decisions in an effective, rational and ethical way.

Step-by-step decision-making process overview

There are 5 steps in the decision-making process in project management. They are:

1. Identify decision – someone identifies the need for a decision (project manager, project team member, or another stakeholder).
2. Gather information – determine what information is available to help make an effective decision.
3. Evaluate and select option – review available information, potential path forward, and pros / cons of each to determine the preferred option based on agreed criteria.
4. Take action and implement – implement the selected option.
5. Monitor outcome – monitor the impact of the decision on the project.

Let’s look at each of those in more detail.

Step 1: Identify

The need for a decision occurs at any time during a project’s lifecycle. The first step is to identify that there is a choice that needs to be made – a problem that needs to be solved or something else you need to take a decision on.

The people who determine the need for a decision can also vary – from project leader, to project team member, to a request from key project stakeholders.

It is worth mentioning that the project manager has the option to delegate decisions to the project team (or specific team members) when appropriate. For example, the project manager may rely on a lead for a specific discipline or project area to help manage routine or day-to-day decisions.

The most common example would be what specific task(s) the project team members will work on each day. However, it is appropriate to set some boundaries for escalation so that the project manager can focus on other project responsibilities but still “step in” to help support as needed.

Once the need for a decision is identified, the project team should start to gather information.

Step 2: Gather Information

The next step is gathering information and that’s exactly what you think it is. The team looks at what information is available to help determine overall project status, give some context for the decision, and use that to help facilitate a good result. 

Some examples of useful information would be:

• the project’s overall financial status
• financial targets such as profit margin that are set by the business
• cost benefit analysis of various options
• planned versus actual progress for ongoing work
• root causes, if the choice relates to an issue
• resource availability on the project and within the available resource pool (if applicable)
• external factors that might make a difference
• any other relevant data.

If you don’t know what’s going to be useful think about it this way: what are our options? Silent brainstorming, a SIPOC diagram, or using digital tools like Google Jamboard to put down all the ideas could get the ball rolling.

Tip: Part of the decision-making process is to identify the decision-makers. Sometimes you need to know how to make a group decision; sometimes you can make the call yourself.

The purpose of gathering the information is to ensure that the decision is based on the most current project state and information. The type of information that is needed may also vary depending on the decision.

For example, if the decision involves vendor selection to help deliver a specific part of the project, then it would be helpful to have a list of relevant vendors, their status on a preferred vendors list, any differences that may exist in pricing, contract terms, or other relevant factors to consider in the selection process.

Tip: You need all the info in order to make an informed decision. Don’t skimp on this step!

Step 3: Evaluate and Select

During this step, the project manager, the project team, or a combination of these discusses all available and relevant information. They may also pull in other subject matter experts and / or stakeholders as needed.

Here are some options to help evaluate the various options you have identified:

• Team voting. The team can discuss and vote on the various options. This can be done by a secret vote or open team vote. Open option for voting “openly” is to put various options on a flip chart and have team members put sticky notes, stars, or other indicators of the option(s) they believe would be best.
• Elimination. If there are options that will not work for some reason (example: extremely unfavorable contract terms) then those options might be eliminated.
• Multiple criteria. Sometimes it is helpful to identify multiple criteria and score the various options across those criteria (perhaps on a scale of 1 – 10) in terms of how much benefit or value they bring to the project. Then the option with the highest composite score would be the most likely choice
• Decision tree analysis. Some problems lend themselves to this kind of analysis. Create a tree structure with different paths. That can help you see the options available so the team can select the best possible solution.
• SWOT analysis. I would use this for portfolio or strategic-level decisions, but it’s not something I used regularly for project-level decisions.

Sometimes you’ll want to use a variety of techniques so you can look at a problem from all angles. However, that can extend the time period for actually getting on and doing the work. Ideally, you’ll have documented the decision-making process in the project management plan because it’s relevant to project governance and quality, so hopefully you can look back at that for some guidance on how to keep things moving.

Tip: Avoid dragging out this process over a long time. Failure to decide can block progress – sometimes the best approach is just to choose and move on.

Once the team has completed the discussion and evaluated the various options, one option is usually a clear winner. If that is the case, then that’s the best choice and that option can be implemented.

In some cases, if two or more options are considered equivalent (or close to it) then perhaps additional criteria might be considered. If that is not the case, then some options may be equivalent and other factors like ease of implementing and least impact on the project may also help narrow the selection.

Step 4: Take Action / Implement

Once there is a clear choice, that option can be integrated into the project plan. The team should take necessary action to carry out the decision as described.

In addition to the implementation, there are other steps to take for completeness and adherence to good project management practice.

In general, stakeholders should be kept informed of the different decisions even if they aren’t directly involved in the choice itself. For a more important decision, it is a good idea to send a general communication on the challenge, the outcome, and the rationale for the decision.

Using a Decision Log

To ensure that decisions and outcomes are also properly documented, add them to the Key Decision Log (which you might call the Project Decision Log). This is the best place to record any critical project decisions that occur during a project’s lifecycle.

If someone, including a project stakeholder, questions a decision later, you can always revisit the decision log to explain what was decided, the relevant context at the time, and who agreed. This is particularly helpful in cases where stakeholders may tend to change their minds.

Keep in mind that the most influential stakeholders may have their own expectations in terms of updates and when they should be involved. It is always a good idea to discuss this at project kickoff to ensure that they are always appropriately informed.

Step 5: Monitor Outcome

Once the best solution is implemented, monitor the impact on the project. For example, if a decision is to add new team members during a project, it would be a good idea to monitor their efficiency and work quality to spot potential issues early (or validate that there is no impact).

Tip: Use this step to learn for next time. What can you take from this experience that will help you on future decisions?

What decisions can you use this process for?

There are several types of decisions you’ll be making on projects.

Programmed and non-programmed decisions

Programmed decisions are the kind you have a formula for: can we approve this request for leave? Do we organize the project board meeting for Tuesday or Friday? There’s a process or a set of norms to follow, even if you can’t predict when the decision will need to be made.

Non-programmed decisions don’t follow the program. They have more variables and are typically more complex. Shall we buy or build? Should we launch these new products or improve these processes first?

Operational and strategic decisions

Some decisions affect the operational running of the project: routine decisions about who gets assigned to which task, for example.

Strategic decisions relate more to the direction the project needs to take. They typically affect the budget, benefits, or key deliverables for the project – and sometimes the project manager doesn’t have the authority to make them. You’ll have to present recommendations for major decisions to the project sponsor or project board, and they will normally make the final decision.

Risk and decision making

Risk management is an exercise in decision-making. Once you’ve identified a risk, you need to come up with a plan to manage it. There’s normally a bunch of ways you can mitigate against a risk, so you need to apply all your analysis skills to make the right choice.

One of the factors in making a choice is risk. If you have online tools and the skills to do it, Monte Carlo simulation can give you a picture of what the impact of any particular course of action will be through risk modeling. I love the idea of it, but I’ve never worked anywhere that has taken a proactive approach to simulation.

Project management software also has decision-based modeling built in to help you see the impact of a choice on project tasks and timelines -- if that feature is important to you, choose the a tool that will let you model the outcome of your decisions.

An ethical model for decision-making

In some cases, a decision may have ethical considerations. You should always be mindful of conflicts of interest, working with other ethical companies, responsible use of company resources, adherence to established company policy, etc.

Some project decisions may even negatively impact others, create bad press for the company, or harm the environment. Although the specifics may vary by project, the ethics of a decision should always be considered.

Skills for decision-making

There are certain skills to help a team make effective decisions. Those skills vary by team member and role. Here’s what I mean:

• Stakeholder: demonstrate trust by letting teams make decisions independently as often as possible
• Project manager: provide meeting facilitation, emphatic listening, stakeholder engagement, asking probing questions, using the 5 Whys
• Team members: provide subject matter expertise.

In summary

Making decisions is a normal part of managing projects. Although some decisions may seem complex, you can also rely on input from team members, subject matter experts, and stakeholders.

As decisions get more complex, using a framework or step-by-step guide can make things much easier – and positively influence the project’s success. Once a decision is made, don’t forget to document, tell the relevant people, implement what was agreed, and monitor the outcome.

Your next steps

• Make sure there is a decision-making process documented in the project management plan (or at least some commentary around how and what to escalate)
• Download the project decision log template
• Check out a new technique and try using it on your next decision!

Good luck and happy decision-making!

This article first appeared on Rebel's Guide to Project Management and can be read here: Project decision making: a guide for doing it better

We gathered 57 of the top AI in project management statistics to help understand this key development in technology. Recent advancements in tech have changed how project managers work.

Using our 20 years of project management experience, we reviewed AI statistics and trends from trusted third parties, which forms the foundation for this list. It covers everything from the impact of AI replacing jobs to how AI is used to support the delivery of projects.

Many project managers will be aware of the impact (or potential impact) of GenAI and other AI technologies in project management, although not everyone has yet to see substantive benefits in real-life adoption. Let’s take a look at the latest stats.

Top AI in project management statistics

You’ve probably read that 80% of project management tasks will be eliminated by AI by 2030 (Gartner). That means removing the busywork of project management like data collection, status reporting and tracking – which I think is a good thing.

Here are some other top project management statistics worth knowing.

• The global market for AI for project management is expected to grow to US$5.7bn by 2028 at a CAGR of 17.3%.
• 41% of experts report significant enhancements in project delivery since adopting AI-based tools and techniques.
• 28% of a project manager’s skill set can be augmented by GenAI including methodology and life-cycle driven tasks.
• There are more data and analytics projects being kicked off in 2024 than previous years, with 77.6% of organizations reporting that they are driving business innovation with data compared to 59.5% in 2023.
• 72% of project managers say AI is very or extremely likely to change their roles.

Sources: Markets and Markets, Nieto-Rodriguez/Viana Vargas, LinkedIn, Wavestone, APM

Listen to me and Cornelius Fichtner discussing these stats in a webinar

I met Cornelius for a webinar on AI for project managers and what these statistics really mean for practitioners. We got some great questions during the live broadcast, so if you'd rather watch than read, check it out!

Adoption of AI in project management

22% of project managers say AI tools are deployed in their organizations and in use today (Capterra). However, different surveys report different adoption levels. PMI’s GenAI report says that a third of practitioners' organizations have adopted AI in at least a moderate capacity.

Only 12% have adopted AI in a substantial way, and the adoption levels are much higher in tech-forward companies (34%).

• 39% of project managers say there are plans to deploy AI tools in their organizations.
• 21% of business leaders say deployment of AI tools is not in their current plans.
• Companies expect to increase investment in AI for their project management function by 32%.
• 29% of project professionals say they don’t feel ready for the adoption of AI tools. Only 9% say they are extremely ready.
• 75% of experts say complex projects are very likely or extremely likely to benefit from AI compared to a simple project.

Sources: Capterra, IPMA, PMI, APM

Impact of AI on project management jobs

47% of people believe that AI would do better at treating all job applicants in the same way than humans (Pew Research). So that could be a positive for project managers applying for jobs.

Will AI replace project managers? I don’t think human intelligence will ever be removed from project delivery. Here are some other statistics on the impact of AI on project management roles.

• 85% of people believe that on-the-job training is the best way to develop the AI skills required.
• Large Language Models help the least experienced employees the most. Research shows that less experienced staff showed a 43% improvement in performance when using LLMs, compared to an improvement of only 17% by more experienced staff.
• 80% of project leaders believe they will have more time for complex managerial tasks when using AI tools.
• The non-IT skill required the most for using AI in project management is analytical thinking, followed by creative thinking and complex problem solving. Social skills are considered the least likely to be needed to use AI.
• Only 40% of practitioners believe that AI will create new tasks. 54% believe it will change the way work is organized and 53% believe it will increase project team agility.
• 65% of experts see AI as a catalyst for implementing advanced project management strategies.

Sources: IPMA, Microsoft, Nieto-Rodriguez/Viana Vargas, APM

AI Project Manager salaries

I couldn’t find a survey that summarized AI project manager jobs and salaries, probably because there aren’t that many positions. The role hasn’t been around that long. Oceania is the continent that is doing the most to build or recruit AI competence into the organization (PMI).

However, I searched Glassdoor and Totaljobs, and from the job adverts I saw, the average salary for an AI project manager in London, UK, was £75,000.

Glassdoor puts salaries for an AI project leader at between £41k and £77k per year.

Salary.com says that Wells Fargo pays AI project managers between $90,629 and $124,401.

Another way to review the salaries for an AI project manager is to consider that as it’s a niche skill, those roles are likely to command higher-than-average salaries. The Bureau of Labour Statistics says the highest 10% of project management specialists earned $159,150, so you could consider that a benchmark.

One thing that isn’t clear is whether AI will, over time, actually reduce salaries as the role will not require so much administrative work – companies might be looking to make cost savings.

Uses of AI in project management

AI is in use by project delivery practitioners and Project Management Office professionals, generally through tools like ChatGPT or Microsoft Copilot, and more specifically such as in tools designed to support particular domains like AI in risk management.

Latin America has the highest AI maturity levels and also spends the most effort on making sure employees are ready to use AI tools (PMI).

25% of PMO directors say that AI has disrupted their PMO (Capgemini) – and I’m sure that number will only continue to rise. Let’s look at some more statistics about the benefits of AI.

• Over 70% of practitioners say that achieving compliance with quality standards could benefit from AI adoption.
• 65% of project managers say that they are most likely to use AI during project deployment and execution phases.
• Automating tasks is the top benefit for using AI tools (cited by 33% of project professionals), followed by effective resource allocations (32%) and getting more accurate metrics (27%).
• Predictive analytics tools and chatbots are the most commonly used, with 26% of organizations using these or planning to use these to support project delivery.
• 23% of organizations are using or planning to use RPA.
• 66% of experts believe that project scheduling and time management is the area with the highest potential for AI process automation.
• 60% believe that augmented analytics can help risk and opportunity planning and management.
• 49% of organizations believe that implementing GenAI will generate huge productivity gains.
• Over a quarter of project managers are extremely likely to use AI to analyze large data sets on complex projects – I can see this being useful for identifying potential risks and in analyzing real-time data.

Interestingly, project management domains where there is low impact from AI are considered to be stakeholder management, project communication and project budgeting.

Sources: Capterra, APM, IPMA, Wavestone, PMI

Barriers to adopting AI in project delivery

The ‘classic’ barriers to adopting any new technology, like limited funding, user adoption and senior support, training etc are holding back AI’s progression into companies. Cyber security concerns and the risks of putting your data into a model that you don't completely own are also holding people back -- addressing these adequately seems very expensive at the moment.

Other limitations like the carbon offsetting burden – training an LLM can emit 25 times more carbon than one-way air travel between New York and San Francisco – may also hold companies back from building their own solutions (Stanford).

The shift towards using AI tools is happening so quickly that the regulation is lagging behind, and in regulated industries like healthcare and financial services, this is an issue.

• 70% of people report that a limited understanding of AI technologies is the most important barrier to using new tools.
• 49% of professionals say that limited financial resources are a barrier to adopting AI.
• 28% of project professionals say lack of a clear strategy is the main barrier to adopting AI tools at work.
• Other barriers to adopting AI include ethical, privacy and security concerns (26%), and AI technology immaturity (25%)
• 1 in 5 project managers say there are inadequate skills within the team to implement AI tools.
• 74% of experts are worried about potential ethical challenges resulting from AI-based decision making.

Sources: IPMA, Capterra, Nieto-Rodriguez/Viana Vargas

How project managers feel about AI

The future of project management is positive, with high demand for jobs and a strong focus on successful project outcomes – there is a lot to be done, and AI is poised to help.

• 44% of project practitioners believe that they will end up with more projects to manage as a result of organizations adopting AI.
• Only 29% of project managers are worried about AI taking over their jobs, although this increases to 40% in the next 15 years.
• 77% of project managers are optimistic about AI.
• 44% of project professionals say they are extremely satisfied with the use of AI technology at work, and 46% report being very satisfied.
• 54% of companies using AI in project management are very comfortable using it to make decisions. Only 2% are not comfortable.
• 68% of project managers say they have not received enough training on how to use AI tools.

Sources: IPMA, Nieto-Rodriguez/Viana Vargas, Capterra, APM

What do these project management and AI statistics mean?

Here are my top 3 takeaways from analyzing hundreds of artificial intelligence project management statistics, charts and numbers.

Takeaway 1: AI isn’t going to take your job (yet)

My key takeaway from analyzing the data is that AI isn’t going to take your job if you work in project delivery. Too many project management skills can’t be done by computers… which is a good thing in my view! You can only get so much business acumen, systems thinking and cultural understanding from a model.

However, the many surveys and research studies all point to the same thing: the role of a project manager is changing, so you do need to keep up to date with how the tech is evolving. Sentiment analysis, for example, is an area where we could get stakeholder engagement insights from a data set to help determine action plans for different stakeholder groups.

Consider how AI can help with monitoring, controlling and creating project deliverables. The other area to actively look into is resource management: resource availability and capacity planning is a common pain point with the project managers I mentor, so anything that helps is a plus.

I think there is a lot of data and training out there now, including courses from LinkedIn Learning and PMI, so there is no excuse not to have a basic understanding of tools like GenAI and what they can do.

If you can lobby for AI training and time to practice with the tools available for you, then do so. Knowing how AI-driven solutions work will only make your job easier, and most project managers report not having been provided with adequate training.

Takeaway 2: AI benefits complex projects

The next thing that was clear to me from reviewing the data is that AI benefits complex projects. The larger your data sets for research and analysis, the more AI-powered tech can make it easy for you to sift through the data.

We're going to see a move from predictive analytics to prescriptive analytics, where AI gives us information on project performance and ideas about how we should act on the data to course correct or take the next step. At this point, we still need a human to scrutinize the output, but this will remove some of the 'gut feel' of project management and hopefully help us all make better, data-driven decisions.

APM’s research says that IT and Technology projects are most likely to see a benefit from AI but I think over time we’ll also see legal project management and construction seeing benefits due to the huge amounts of data that can be used in those projects.

I think that the biggest barrier to making use of this advancement is having clean data. I would suggest that any project teams looking to use the analytical power of data models and LLMs need to schedule time on the plan for data cleansing and preparation.

Takeaway 3: GenAI benefits less experienced project professionals

Finally, I picked out the point that GenAI is more beneficial to people with less experience. Project success rates are hugely impacted by the quality of the team working on the project. With natural language processing and machine learning, it is easier to review data from historical projects to support project planning.

This is so important for a profession where we are losing experienced project managers to burnout and people transitioning out of the job. Routine tasks can be made easier and projects processes can be turned into workflows with RPA.

Final thoughts

Reliable AI facts and statistics on artificial intelligence in project management is important to understand the sentiment of how project professionals are feeling about the impact of newer technologies and to provide valuable insights into how it is used.

AI will continue to dominate project delivery conversations and become embedded in the ways that projects are scoped, executed and analyzed in the years to come, most likely removing administrative tasks and supporting informed decisions.

Perhaps the question we should be asking is how do we want AI to impact project management? Then we can shape the technology to deliver the best results.

This article first appeared on Rebel's Guide to Project Management and can be read here: 57 AI in Project Management Statistics

What should a PMO measure?

There are millions of data points, so how do you decide what is really going to make a difference for your team?

In my experience, we want to track metrics that we can do something about and that enable decision-making. There are plenty of things that your Project Management Office could track but that wouldn’t move the needle – focus on capturing data that’s to do with things you can actually do something about.

Below are some examples of key performance indicators to consider, that measure project performance in an aggregated way.

If you are looking for KPIs to set for people in project roles, as part of their annual performance review, then I have a guide to KPIs for Project Managers that also covers goals you can set for PMO analysts and PMO managers.

Delivery success KPIs

• Project benefits realized vs planned – in my experience this is the most important one!
• % of projects delivered on time
• % of projects delivered on budget (or combine these two for a ‘project success rate’ measure, although you’ll have to be very clear how ‘success’ is defined)
• Customer/stakeholder satisfaction scores
• Milestone completion rate – helps you identify trends in projects running behind

If you’re in a less mature environment, it can also help to track aggregated project-related KPIs, for example, actual cost of all projects under portfolio management.

Governance adherence KPIs

• % of projects with approved business case (which will be 100%, obviously!)
• Compliance with reporting cycles (e.g. weekly updates submitted)
• Audit or QA findings resolved within agreed time

Someone suggested that we include ‘% of projects following the agreed methodology’ but as you should be tailoring the methodology to suit the project, that is a bit pointless.

It’s also really hard to establish what it looks like to follow the methodology. Perhaps track how many projects go through the stage gates or approval process, if that’s important to you.

Operational/throughput KPIs

• Number of active projects vs resource capacity
• Resource utilization (useful for professional services organizations)
• PMO response time (e.g. to new project requests)
• % of projects using standard templates/tools
• Project stage distribution (e.g. initiation vs execution vs close)

How to report PMO KPIs to senior leaders

As a PMO leader, you've got to share information with other leaders.

Tailor the message to the audience

Execs care about strategic alignment, risk, ROI, or in your organization the emphasis might be on something different, like sustainability goals or budget spent.

They want data they can use to take decisions, so measures like resource utilization rate, rework rate, resource conflicts, those are things they can act on. And your data can surface this information.

Practitioners (that’s project managers like you) would want to see different things. I am interested in whether my project is achieving its sustainability objectives, of course, but I’m also more bothered about whether I’m being judged on compliance with reporting cycles. And in that case, I want to see my track record.

Tailor the message to the audience so everyone gets what they want.

Use visual dashboards

Use Red-Amber-Green (RAG) status for measures, projects or the portfolio overall. Read my guide on how to define RAG and use it on projects, so you can set criteria about what each color means.

Show trends and the impact you’ve made, not simply raw data points. Add spark lines in Excel or use arrows or RAG status to show movement from last month (or the last time you reported – try not to get into the habit of reporting weekly as it’s a lot of work and really things don’t change that much).

Make it easy to spot outliers or risks needing action: call these out with colors or in a separate section of the dashboard if necessary.

Suggested reporting cadence

Live dashboards are great, and people can self-serve information in real-time. But let’s be honest: stakeholders won't go looking for the information. The number of individuals I can think of who have self-served in my career would fit on a hand. That’s not because they don’t care, but because once the dashboard is in place, they assume someone will report outliers and escalations, and we do.

As a PMO leader, you’ll still have to send out links to dashboards, packs, decks or email updates, depending on what your leadership team needs. 

Monthly or quarterly portfolio review packs are useful to have as an audit trail of a snapshot in time. You might also need to produce KPI snapshot slides for exec meetings or ad hoc deep dives for problem areas, so be ready!

Communicate the reporting deadlines to project managers so they can organize themselves to give you the data you need.

KPIs in action: Example metrics dashboard

There’s an example below of what a dashboard could look like in table format. I wasn’t able to use status indicators as colored blobs in the Status column, as the emoji characters wouldn’t show up in this article in every browser, but I would recommend that you do that.

Switch out the words ‘Red/Amber/Green’ in the Status column with a visual color indicator. Leave the word in as well. This makes the report more accessible. Remember, people with red/green color deficiency will find it harder to distinguish on track and off track projects if you skip the words.

Include a legend:

• Green = On target
• Amber = Watch / trending up
• Red = Off track

Tips for customization

• Replace months with weeks or quarters depending on your reporting cycle.
• Add trend arrows (? ? ?) if desired for visual clarity.
• You could also highlight the top 3 KPIs in a summary box at the top of your report

Add any extra measures you’ve identified that will help your execs or team make the right choices about where to focus their attention.

Agile PMO dashboards

What if your PMO has to cover projects using Agile methods? You can use agile metrics to report overall on projects, but do tailor as necessary to give you useful data, not just reporting on project-level info that isn’t useful when rolled up.

Here are some examples.

Tools for dashboarding

If you already have enterprise project management software, you may find it has dashboards or rolled up reporting already. If so, use that as a starting point.

You can also pull out data from your project management tools and display it through Excel. Google Sheets, PowerBI or other tools like Smartsheet.

What to do with your KPIs

Use KPIs to trigger action, not just report history. They should (if I haven’t already made this point often enough above) drive action and decisions. Reporting for the sake of reporting is time consuming and pointless.

Create KPI ownership within the team. Show people what the KPIs are being used for so the project teams understand what is happening to their data.

Review and evolve KPIs as the PMO matures. What works in the first few months of your PMO won’t be what you report on in two years. Go with it, you’ll get feedback and evolve in time, and that’s fine!

This article first appeared on Rebel's Guide to Project Management and can be read here: PMO KPIs: Success metrics to prove the value of your PMO

There's a stat that gets thrown around a lot in project management circles: project managers spend up to 90% of their time communicating. I’m not convinced that there was a lot of robust academic research behind that number, but the broader point still stands. Communication is the job. Everything else — planning, risk management, scheduling — supports it.

And yet, for all the time we spend communicating, we don't always make deliberate choices about how we communicate. We default to email because that's what we've always done. Or we stick to weekly status meetings because the project plan says so. Or we fire off a Teams message when what the situation really called for was a proper conversation.

Choosing the right channel matters. If you’ve ever tried to get hold of a stakeholder and missed them because they don’t monitor their Teams messages or whatever, then you’ll know what I mean. I have one project sponsor who is on WhatsApp every day, but wouldn’t take a call, because he’s out on the road. So you have to know your audience and what will work for them.

Channel choice isn't a minor detail

According to PMI's Pulse of the Profession research, 56% of project spend is at risk due to poor communication*. In other words, you could be wasting over half your project budget if you don’t get the comms right.

So is that 'project managers aren't communicating enough'? I don’t think so. In my experience, the more common problem isn't volume. It's mismatch — the right information going out through the wrong channel to the wrong person at the wrong moment.

If your information is not accessible (or interesting), then it won’t have the effect you were hoping for.

Your communication management plan should address all of this, but even if yours is fairly basic, making more intentional choices about channel selection will pay dividends.

When you're building or updating your communications management plan, add a column for preferred channel. Ask people directly. It takes two minutes and it can save you significant rework when you discover, three months into a project, that the sponsor has been deleting your status emails unread because they assumed someone else was summarizing them.

The communication channels problem

One of the things the PMBOK Guide covers — and that you'll want to memorize if you're studying for CAPM® or PMP® certification — is the communication channels formula.

The number of potential communication channels in a project is calculated as n(n-1)/2, where n is the number of stakeholders.

What this formula makes clear is how quickly communication complexity escalates. A single person added to a 10-person project team increases communication channels from 45 to 55. That’s a 22% increase in complexity for a 10% increase in team size. This is why communication management can't be improvized on larger projects.

But structure doesn't mean rigidity. It means knowing your options and making deliberate choices. And that’s even more important when you bring users and customers into the mix.

The main channels available to you

Most project managers have access to a fairly consistent set of communication channels, even if the specific tools vary. Here's how I think about them.

Email

Email remains the workhorse of project communication, and for good reason. It creates a record, it allows people to read and respond at their own pace, and it's universally accessible.

It's particularly well suited to formal updates, decisions that need to be documented, and information that stakeholders will need to refer back to.

The downside is that it's easy to ignore. An email can sit unread in a busy inbox for days. And in high-volume environments, important updates can get buried. If you're sending status reports by email, think carefully about format and frequency. A long, poorly structured update is worse than no update at all, because it trains stakeholders to stop reading them.

Meetings

Meetings are high-bandwidth: you can pick up tone, handle questions in real time, and build relationships in a way that written communication doesn't allow. They're the right choice for anything that needs discussion, negotiation, or alignment. Status meetings, steering group sessions, workshops — these need to be in-person or video, not summarized in a document.

The pitfall is over-reliance on meetings. If everything becomes a meeting, people stop attending properly. Meetings should be reserved for communication that genuinely benefits from dialogue.

Instant messaging and collaboration tools

Teams, Slack, WhatsApp — whatever your organization uses — these are fast and conversational. They're well suited to quick questions, informal updates, and day-to-day team coordination. They're not well suited to formal communication that needs to be on record, or to reaching stakeholders who aren't active on the platform.

One issue I see regularly is that important decisions get made in Teams chats and then lost. If something matters, move it to email or a document.

SMS and text messaging

Whether you favor WhatsApp, iMessage or ‘traditional’ SMS, these all get underused in project management, which is a shame, because they have a useful place. Open rates for text messages are significantly higher than for email, and texts tend to get read quickly. For time-sensitive alerts (a go/no-go decision, an urgent escalation, a reminder about a critical sign-off) SMS is more attention-getting than email.

If you're running a project with external stakeholders who aren't on your internal systems, or working with senior sponsors who are hard to reach by email, SMS is worth considering as part of your outreach toolkit.

Dashboards and status reports

For stakeholders who need a regular view of project progress but don't want to be emailed about it, a self-serve dashboard or a structured status report distributed on a predictable schedule can work well.

These are ‘pull’ communication: the stakeholder chooses when to look. They work best for stakeholders who are engaged and know what to look for; they don't work well as the primary channel for disengaged or hard-to-reach stakeholders.

In my experience, after a while, no one but the hardcore PMO team look at them. Sometimes they are just about providing confidence to senior stakeholders. Once they know that things are being tracked and that it’s all OK, they use their time for other, higher priority tasks than checking a dashboard, on the assumption that they’d hear about it if something was seriously wrong.

Combining channels: the case for a blended approach

For most projects, the right answer isn't one channel, it's a mix. You might use a regular email update to share the week's key progress, WhatsApp or a Teams message to flag anything urgent, and a monthly steering group meeting for anything that needs a decision.

It’s worth the effort to learn how to use email and SMS together for blended project communications. That resource is particularly written for a marketing context, but it translates well into thinking about stakeholder engagement, particularly around personalization, timing and avoiding channel fatigue. Whether you are communicating internally or externally, segment your audience, vary your channels and don’t rely too heavily on one medium.

Remember to lean into the expertise in your Marketing department if you are planning on messaging customers. Normally, project people wouldn’t reach out to customers directly as you’ll have a structure in place to do that, so make sure you’ve got a CRM expert on the project team (which is what we did – no one is letting me get my hands on the system to communicate to customers!).

Get the timing right

Channel and timing go together. Email sent at 11pm on a Friday will be buried by Monday morning. An urgent SMS sent at 7am will be seen immediately but might annoy. A monthly steering group update shared two days before the meeting gives people time to read it; shared the night before, it doesn't.

Think about when your stakeholders are most receptive. Senior sponsors are often more engaged mid-week than on Mondays or Fridays, but that might be different in your organization.

Teams with operational responsibilities may not be checking project communications during busy periods, like month end, and they probably won’t show up to meetings (Finance colleagues, looking at you).

None of this needs to be complicated. A simple communication matrix to remind you what to do when or who needs what, that’s often enough to bring some discipline to what otherwise becomes ad hoc.

A quick note on documentation

Whatever channels you use, make sure that decisions and key information end up somewhere they can be retrieved. Instant messaging and informal conversations are great for getting things done quickly, but if the audit trail lives in someone's deleted messages, you'll regret it.

I’m happy to chat on Teams, but when we’ve made a decision or got some kind of output from that back-and-forth, it goes on an email to everyone, or is transferred to the action log, or something, so it exists somewhere that is not a conversation thread.

In summary

Communication channel selection isn't a detail to figure out later. It belongs in your communications management plan, it should be revisited when your stakeholder landscape changes, and it should be driven by what your stakeholders actually need — not by habit or convenience.

The channel-per-stakeholder approach, combined with deliberate thinking about timing and frequency, is one of the more practical ways to improve stakeholder engagement without significantly increasing the time you spend communicating. Often you're doing the same work, just routing it better.

If you're looking to develop your stakeholder communication skills more broadly, you might find my book Engaging Stakeholders on Projects a useful complement to the tips above. And if communication planning is something you want to explore with a peer group, it's a topic we return to regularly in the Project Management Rebels community.

* Project Management Institute. (2013a). Pulse of the profession^® in-depth report: The high cost of low performance: The essential role of communications. Newtown Square, PA.

This article first appeared on Rebel's Guide to Project Management and can be read here: How to choose the right communication channel for your project stakeholders

What is the stakeholder salience model?

The stakeholder saliency model was proposed by Mitchell, Agle and Wood (1997). They define salience as:

the degree to which managers give priority to competing stakeholder claims.

Their model looks at how vocal, visible and important a stakeholder is. Those dimensions help you identify the stakeholders who should get more of your attention.

Project stakeholder management and saliency

Project management relies on people: you need the project team to get things done, and that team might include members of different stakeholder groups. It’s common to have a core team of people who work daily (or at least regularly) on the project, and then a wider stakeholder community.

The saliency model is a tool you can use as part of stakeholder analysis, management, and engagement. It’s a way of categorizing stakeholders so you can evaluate the best way to involve them in the project.

There are three elements to consider, which together highlight the saliency of a stakeholder: in other words, how much priority you should give that stakeholder.

The three considerations are:

• Legitimacy
• Power
• Urgency.

Let’s look at each of those and how they can support stakeholder classification.

Legitimacy

This is a measure of how much of a ‘right’ the stakeholder has to make requests of the project.

Legitimate stakeholders can have a claim over the way the project is carried out can be based on a contract, legal right, moral interest, or some other claim to authority.

The strategic management layer in an organization is likely to have a say in how the project proceeds. Key customers or clients are also likely to have high legitimacy.

Power

Power is a measure of how much influence they have over actions and outcomes. Their power could derive from hierarchical status or prestige within the organization, money invested from a particular shareholder, ownership of resources required to successfully deliver the outcome, or similar.

Larger projects are likely to have higher numbers of people with power involved because they tend to attract greater corporate governance and oversight – so the top management likes to know what is going on.

There are also often power imbalances at play within complex organization structures, so identifying those early will help you come up with strategies to make them work for you.

Examples of stakeholders with high power are the sponsor, the CEO and the client.

Urgency

This is a measure of how much immediate attention they demand and how unacceptable a delay in response/action is to the stakeholder.

The expectation of high urgency can result from some kind of ownership, previous experience where urgent action was taken that leads to continued expectations of comparable response times, a time-sensitive problem that creates exposure for the stakeholder, or similar.

For example, how often are they likely to bring you urgent issues? Things that can’t wait?

Again, sponsors, clients and senior management are likely to score highly for urgency. Regulatory agencies and compliance teams might also have the right to demand immediate action.

Together, an assessment of these three elements can tell you how engaged a stakeholder is or will be in the work and how they could influence the project. This is useful information for tailoring your engagement activities and working out with whom to invest your time.

How the dimensions overlap

The picture above shows how power, legitimacy, and urgency overlap to give stakeholders more or less saliency.

Project managers love a good Venn diagram!

Stakeholders that fall into areas where they have two or three elements of saliency are the ones to be most aware of and to spend the most time with. They're the ones to focus on when you're doing stakeholder mapping.

Mitchell, Agle, and Wood define these salient stakeholders as follows.

Dominant stakeholders

This group has the stakeholder attributes of high power and high legitimacy to influence the project. An example would be the board of a company. The blend of power and legitimacy means they can act on their intentions, should they ever want to.

They might not spend much time on the project, but you know about it when they want to get involved. They also have controlling influence over things like resource allocation, and they might have a say about how the budget is spent, for example.

Dangerous stakeholders

This group has high power and also expects their needs to be met with a high degree of urgency. However, they have no legitimate claim over the project.

The researchers point out that people in this group, for example, pressure groups, can use coercive power and unlawful tactics to draw attention to their interest in the project. So there's some potential stakeholder behavior to watch for here.

Dependent stakeholders

This group has legitimacy and urgency but lacks real power to influence the direction of the project. An example would be the future process owner who will be responsible for running the activities resulting from the project’s deliverables.

If you work in projects for local governments, for example, you might find that lobby groups, local community groups, or local residents fall into this category.

They have a legitimate claim to influence the project as the outcome is going to impact their environment. They want their views to be heard in a timely fashion. But they don’t really have any power to influence the direction of the work because they are not employed by the contractors.

They are ‘dependent’ because they depend on the power of others to generate action at this time.

Definitive stakeholders

This group meets all the criteria for saliency. They have high power in the situation, they have a legitimate claim over the project and they have a claim to urgency.

For example, your sponsor.

Together this gives them an immediate mandate for priority action on the project. Typically, this situation occurs when a dominant stakeholder wants something done and gains urgency as a result.

Small projects may only have definitive stakeholders: perhaps just you and a manager.

Non-stakeholders

They also define a group of people who don’t meet any of the criteria and are therefore not stakeholders.

I would advise caution when using this label because they might become stakeholders at some point, especially for internal colleagues.

There’s also a risk attached to labeling everyone else as non-stakeholders. Perhaps you simply haven’t identified them yet.

Other types of stakeholders

The model does talk about other groups – what happens if someone falls into the bracket where they only meet the criteria of urgency, for example. If you want to look them up, these are:

• Dormant stakeholders
• Expectant stakeholders
• Latent stakeholders.

My personal view is that in a business context, given how little time we have to engage all the stakeholders, it’s better to focus on the individuals and groups who tick two or more boxes. The reality of managing projects is that you simply don’t have the time to go through a consultation process and do the analysis for everyone.

Your choice, though.

How to use the salience model

So what are the practical implications for the model of stakeholder salience? I like it because it goes beyond the 'classic' approach of influence and interest. A power/interest matrix can be useful, but it doesn't always show the full story, especially if you have external individuals or groups involved. And there are other stakeholder analysis frameworks as well, so you may have to use whatever your organization suggests is the appropriate way to work this out.

However, understanding saliency is useful because it helps you identify how to spend your limited resources. You have limited time, and you can make the most of that by applying different levels of stakeholder engagement to different people.

Stakeholder relationships are time-consuming, so it’s worth investing your energy where it is going to have the greatest effect.

Look through your analysis and identify the individuals and groups who are going to benefit most from your time. Prioritize the definitive stakeholders as they tick all the boxes.

Then look at the other groups. There might be important stakeholders hidden away in other categories. Don’t let the model become a replacement for common sense.

However, remember, stakeholders can move between the categories as the project and the situation evolve.

Power, urgency, and legitimacy can be lost and gained slowly over time, or in a moment. Keep your analysis under review and switch up your actions accordingly, creating a stakeholder management strategy that fully engages your community to the best of your ability.

This is an edited extract from Engaging Stakeholders on Projects: How to harness people power by Elizabeth Harrin (APM, 2020).

You might see older versions with the old APM branding on the cover (red, black and purple). It's the same book on the inside, but the cover was updated in 2023 in line with the APM's rebrand.

Mitchell, R. K., Agle, B. R. and Wood, D. J. (1997) ‘Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts’, The Academy of Management Review, Vol. 22 (4), pp. 853-886.

This article first appeared on Rebel's Guide to Project Management and can be read here: The Stakeholder Salience Model and How to Use It