Rebles Guide to PM

• PMO KPIs: Success metrics to prove the value of your PMO

  

  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.

  Don't track earned value

  I wouldn’t track earned value. That’s a project management KPI. I’ve seen other people recommend tracking Planned Value or Schedule Variance but really, what does that give you at PMO level? If your teams are using earned value, they’ll be using this data for operational efficiency anyway, so the results will show up in your other metrics.

  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)

  KPIs are different for different PMO types

  Choose KPIs based on your PMO type (supportive, controlling, directive etc). Focus on what people want to know about and that would drive actions and decisions.

  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.

  KPI	Definition	Target	May	June	July	Status
  % Projects on Time	% of active projects meeting timeline commitments	? 85%	78%	81%	88%	Amber
  % Projects on Budget	% of active projects within agreed budget limits	? 90%	92%	94%	93%	Green
  Reporting Compliance	% of projects submitting status updates on time	100%	95%	100%	98%	Amber
  Stakeholder Satisfaction	Avg score from post-project survey (1–5)	? 4.0	4.2	4.5	4.3	Green
  Benefits Realisation	% of forecast benefits delivered (closed projects)	? 80%	76%	85%	83%	Green
  PMO Response Time	Avg days to respond to new project requests	? 5 days	4.2	5.8	4.6	Amber
  Open Risks Resolved on Time	% of high-priority risks mitigated by due date	? 85%	72%	86%	88%	Green

  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.

  KPI	Definition	Target	Sprint 6	Sprint 7	Sprint 8	Status
  Sprint Velocity Stability	Consistency of story points completed across sprints	? ±15% variance	12 pts	14 pts	13 pts	Green
  Team Throughput	Total stories or features completed	? 8 per sprint	9	10	8	Green
  Planned vs Delivered Ratio	% of committed work completed per sprint	? 90%	88%	92%	91%	Green
  Defect Leakage Rate	% of defects found post-release	? 5%	6%	3%	4%	Amber
  Cycle Time (Avg)	Average time from work start to completion	? 7 days	9 days	6 days	7 days	Amber
  Team Happiness / Morale Score	Team-rated satisfaction score (1–5)	? 4.0	3.8	4.2	4.4	Green
  Business Value Delivered	Sum of value points assigned by Product Owner to completed work	Track only	48 pts	65 pts	58 pts	For info
  Story Carryover Rate	% of stories not completed and carried to next sprint	? 10%	12%	8%	5%	Green
  Release Predictability	% of releases delivered on planned dates	? 95%	100%	100%	90%	Amber

  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

• How to choose the right communication channel for your project stakeholders

  

  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.

  Channel	Pros	Cons
  Email	Creates a record Asynchronous so people reply at their convenience More formal	Easy to ignore
  Meetings	Allows you to pick up tone and handle questions Best for topics that require discussion	Time-consuming Difficult to manage with large groups
  IM/Collaboration tools	Fast and conversational Best for 1:1 or small group discussion	Not suitable if you need a formal record Some stakeholders won’t be on top of their messages
  SMS/Text	Fast Best for urgent action required	Some stakeholders won’t want to give you their phone number Risk of over use and getting ignored
  Dashboards	Good for stakeholders who will self-serve Can be tailored to show what’s important to an individual or team Often real-time info	Need set up and maintenance Most stakeholders won’t seek out information proactively

  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.

  Case study

  On a recent project, we needed to inform customers about the project and how the work we were doing would affect them. We chose a combination of email and text message. The email went out first, with the reminder text message shortly after.

  Before choosing those channels, we checked the amount of email addresses and phone numbers that were on file for customers in the CRM system. There were more emails than phone numbers, and in the weeks leading up to the milestone on the project plan, staff on site who talked to customers used the opportunity to gather more data where we didn’t have it, so the communications would reach as many people as possible.

  Overall, this ‘plan, gather data, communicate, communicate again’ approach seemed to land quite well.

  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

• The Stakeholder Salience Model and How to Use It

  

  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.

  You might be familiar with the classic stakeholder analysis impact and interest grid. Stakeholder saliency is simply another tool for stakeholder classification. Personally, I find impact and interest easier, but the theory of stakeholder salience is worth understanding to deepen your knowledge about what action to take and who to be aware of.

  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

• How to save time at work: 15 tips for project managers

  

  As a project manager, your time doesn't just belong to you. You're managing your own workload while coordinating teams, chasing updates, running meetings, and fielding requests from stakeholders who all think their priority is the priority.

  There are no real shortcuts in project work, but there are smarter habits. I've been managing projects for over 20 years and these are the time-saving approaches I actually use.

  Some of these will be familiar. Others might be the nudge you need to finally do the thing you know you should be doing. Either way, I hope you find something useful here.

  1. Call people before meetings

  Give people a ring before a meeting. Ask them if they are still coming and if they have anything for the agenda. (Do you need a template for that? Grab a meeting agenda template here.)

  If there are any decisions to be made, talk to them about the options and informally canvass their opinion on what they think is the right way forward.

  This takes a little time but saves eons of time in the actual meeting, because you’ll be able to use the information you have gathered to head off conflict and bring the group to a decision far more quickly.

  

  2. Trust your processes

  You don’t want to worry about how to handle changes when they get raised. Or what to do to process an invoice. So set up processes for repetitive tasks.

  The extra bonus benefit of having documented processes is that you can then hand the work off to someone else – they can follow the process steps just as well as you.

  Common processes for project management include:

  • Making decisions (yes, you can have a process for this!)
  • Risk management
  • Setting up a meeting (my bundle of meetings templates have a checklist for this process).

  Even things like using a password manager app means you have a process for logging into the many software tools that project managers use throughout the day. Single sign on is a must-have!

  

  3. Use templates

  I never write a project document from scratch. There's always something I can start from — whether it's last month's status report, a risk log from a previous project, or a stakeholder comms plan I've adapted a dozen times.

  I'll just say here: Don't steal templates from one employer and use them at another employer. That is most likely against your contract of employment, and you don't need to anyway, there are plenty of document templates available online.

  Templates work for more than just documents, though. Think about your project management software: most tools let you save project structures, task lists, or board layouts as reusable templates. If you're setting up a similar project for the third time and starting from scratch each time, that's wasted time you could easily reclaim.

  The same goes for emails. I have saved drafts for common messages — meeting invites, escalation nudges, end-of-stage summaries. I'm not sending identical emails, but having a starting point means I'm not staring at a blank screen either.

  If you want ready-made templates to get started, my template shop has a range built specifically for project managers — including meeting templates, status report formats, and more.

  Lean into generative AI

  One more thing on templates: if you don't have a starting point at all, AI tools like Copilot, ChatGPT or Claude can generate a first draft for you in seconds. Describe the document you need ("a project status report template for a construction project with a steering group audience") and you'll get something workable straight away. It won't be perfect, but it'll be 80% of the way there and it's easier to start with that than a blank page.

  I created a sample project charter for a learning exercise recently and I was impressed at how good the output was. I use Claude regularly now for documents I haven't created before, or when I'm moving into something new and my usual templates don't quite fit.

  Treat the AI output as a starting point, not a finished product, review it, adjust it to match your project context, and save it as your new template for next time.

  4. Batch your work

  Switching between tasks isn’t productive because it takes you time to wind down one task and get into another. Task switching is a productivity killer -- that's valuable time that could be spent figuring something else out.

  Batching tasks is where you work on multiple things that use the same tools or skills at a time. For example, part of my job at the moment is to support corporate clients with project management content for their websites. In other words, I write stuff for them, create graphics and from time to time do short videos.

  Video work is easy to batch. I have to produce a video for a client once a month, but setting up the camera and so on just for one recording seems like a lot of effort for not much return. And thus we arrive at the concept of batching. I tend to record three or four videos in a batch because it takes time to set up the camera and pack it all away again.

  I do the same with emails: I’ll block out a morning or an evening to just blitz emails. You could do the same with any similar tasks. Block booking meetings is a good one. Here are other tasks that you can batch:

  • Returning phone calls
  • Filing
  • Completing project reports for multiple projects
  • Completing timesheets for multiple projects
  • Providing feedback or saying thank you to team members.

  I teach strategies on how to do this in my course on managing multiple projects. There's a free webinar on the most important skills for juggling several projects at once that you can watch to get the basics.

  

  Timeblocking

  Batching goes hand in hand with timeblocking.

  Block off time in your calendar for related work, whether that's replying to emails or exercise. It's a way to make sure you've got a stretch of focus time available to get into a task.

  It's one of the time management tips I use the most. I block time to create steering deck reports, do month end financial management and lots more regular activities. If I don't, my calendar gets broken up into smaller chunks for meetings about a range of projects and it's hard to find the capacity to focus on the bigger things.

  Manage your energy levels

  Do the most difficult tasks on your To Do list at your high energy times.

  This isn't really a productivity hack: it's a way of knowing how your body works and listening to your rhythms. Your mental energy might be highest in the morning, like mine. You might dip in attention after lunch. Or you might be a night owl.

  Start time tracking or use a time management app to monitor how you spend your time for a week and you'll see when your productive time is. Look for when there is a drop in productivity.

  Fill those lower-energy time slots with lower-energy work like replying to phone calls, filing, easy jobs you can do without much effort. And use the high energy times, your peak productivity hours, for complex tasks, like digging into your scheduling tool to find out why the autoscheduling isn't giving you the answer you expect.

  5. Write your reports as you go

  This tip saves me thinking time.

  I take last week’s (or last month’s) project report and save it with the name/date for the next report. Then I highlight all the text that needs changing or updating in yellow. During the reporting period I go into the document regularly – sometimes I have it open practically all the time – and add in things that need to be reported.

  So if I add a new risk to the risk register that is significant enough to make the report, I put it on the report at the same time.

  At the end of the reporting period there will still be some bits in yellow that need to be updated or removed, but the bulk of the updates will be done and I won’t be struggling to remember what significant things happened.

  6. Consolidate your notifications

  I can’t do with managing app alerts from Teams on my iPad, LinkedIn messages on my phone, and desktop alerts for meeting appointments from my calendar.

  My inbox is where I spend a lot of time. Here is one of my winning time management techniques: All my important notifications go to my inbox so I only have one place to check. Consolidate them (or turn them off).

  You don't have to use your inbox. You can forward notifications to Slack (if that's your tool of choice) using a range of integrations, or some other workflow that helps you. The point is just to consolidate the noise.

  Read next: Best and worst habits for managing email. Find out how to ditch the email clutter!

  https://www.youtube.com/watch?v=QHrWMMlVYRA

  7. Turn off popups

  As with notifications, turning off popups helps minimize the noise. This helps you focus without being distracted. Turn off the popup in Microsoft Outlook (or whatever you use) that tells you when you have a new mail. And if you get other popups like Teams chat notifications or even anti-virus 'look at us, we've done something in the background to your computer that you don't care about' messages, then go into the app settings and turn them all off.

  The extra benefit of this is that you don’t then get those notifications ping on the screen when you are busy trying to show someone something on your computer. Trust me, they won’t be able to stop themselves from reading your alerts and messages.

  8. Stand up for phone calls

  Try it, it works! If I want to get someone off the phone, I stand up. Somehow it helps me finish the conversation more quickly.

  Note that this doesn't work if you are on a video call, unless you can tilt up your camera somehow. When I have tried this, all I've got in nostril shots -- not a good look! This is a tip for being on the old-fashioned phone, not a Google Meet call.

  Generally, calling people (even on Teams/Google Meet etc) is often faster than emails or instant message if you can get through to them.

  

  9. Unsubscribe!

  Reading all those emails eats up time in the day. Unsubscribe! Be ruthless.

  Not from my newsletter, obviously :)

  10. Delegate

  You will burn out trying to do it all. Delegate as much as you can to as many people as you can. Say no a lot.

  It's hard to delegate urgent tasks because by the time you've found the person to do the work and explained what needs to be done, you could have more quickly done it yourself. So think about what can be delegated -- the routine activity like updating project management tools or daily tasks.

  There’s a long article here on how to delegate tasks if you are finding it difficult to let go.

  11. Use email mailing lists

  I have standards lists of people to whom I write every week. There are lists for people who get this report or that one, lists of project team members, Steering Group members, wider stakeholders, people who get the project newsletter… and so it goes on.

  I can’t hold all those names in my head and I know the implications of what would happen if I left someone off accidentally. Given that people get 117 emails per day, you want to make sure that you're not sending too many or missing them out.

  I have email mailing lists for all these scenarios. Some are created directly within Outlook so I can use a short name and call up the mailing list people. Some I have in Excel and then open the file and copy and paste the names – this is for a particular user group that changes almost every week. It’s easier to add and delete members in a spreadsheet than it is to use Outlook’s email list function.

  Set up lists for your own project and save a few seconds here and there trying to remember and enter all the names.

  12. Cut meeting times

  Check your diary. Are all your meetings in for an hour?

  An hour isn’t the ‘right’ length of time for a meeting. It’s just the length of time that calendar apps default to. These days, my Outlook defaults to 30 minutes (this has changed since I started work, unless it's a system admin setting that my company has amended).

  However, software shouldn’t dictate how long your meetings are. Challenge yourself to set up your next meeting for 45 (or 25) minutes and to stick to it. I promise you will be more focused and you’ll still get through your agenda in the time.

  Plus you get extra minutes of your day back. Win!

  

  13. Pick your battles

  Sometimes, being right is not as important as getting the job done.

  Sometimes, it is worth the fight and you have to do it for the good of the team. Sometimes, just let it go and save your time and energy for a day when you have to step up.

  If your sponsor is asking for something that is a bit outside your job role but that you could do easily enough, or your team wants to do a task in a different way to how you would do it: think about whether it’s a battle worth getting into.

  If it isn’t (and it probably isn’t), move on.

  14. Use checklists

  This is another tip that stops you relying on your memory and helps you systemize more of your tasks.

  Use checklists: for meeting prep, packing luggage for overseas business trips, for finishing a project stage, for starting a project… for anything really.

  If you do it routinely, a checklist can help you work through the steps more quickly and with less stress.

  Read next: 3 easy steps to make a checklist for any process

  15. Take a break

  Finally – and I know this sounds counter-intuitive in an article about getting things done faster – take a break. Have a lunch break. Go for a walk.

  You’ll come back refreshed, with more energy and a clearer head to face the rest of the day. Even a short break away from the screen can help. Get a coffee, chat to a colleague and preferably get some fresh air if you can.

  Regular breaks really do make a difference to your productivity. It's reflective focus, and letting your mind wander, that can help you solve complex problems. Try it -- it really works!

  Finally: Use AI to handle the low value work

  I was sceptical about AI tools for project management at first. But I've changed my tune, because the time savings on certain tasks are real. And I still don't think I'm using it to its full capacity.

  25% of project managers are 'very familiar' with AI, up from 16% in 2023, with two thirds of project professionals now using AI (up from 41% in 2023), according to the AI-Driven PM Revolution survey (Nieto-Rodriguez/Viana Vargas 2025). So if you don't use it, you'll be left behind.

  Need a staff briefing written? Want to tidy up your meeting minutes? Then generative AI is my go to. Sometimes, I know that writing from scratch is going to be faster and more accurate, but sometimes it's worth leaning into the tools you have available.

  You have to know which tasks to hand off. AI is genuinely useful for the kind of work that's necessary but cognitively draining: drafting documents you've written a hundred times before, summarizing long email threads, turning scrappy meeting notes into a structured action list, or writing a first draft of a stakeholder update when you know what you want to say but don't want to spend 20 minutes saying it.

  You do have to check it though: taking the meeting transcript and turning it into minutes might not be the win you think it is. And watch out for those side-conversations at the top and end of meetings where people "stay on for a few minutes" -- you don't always want those documented!

  If a task requires your judgement, your relationships, or your knowledge of the project, keep the task. If it's just a case of getting words on a page in a standard format, AI can take a first pass. Think of Copilot or whatever you use as a very fast junior assistant who needs editing, not a finished product.

  If you want to explore this further, I've written more about AI in project management and how to use it without losing the human judgement that actually makes projects work.

  Save

  This article first appeared on Rebel's Guide to Project Management and can be read here: How to save time at work: 15 tips for project managers

• Terms of reference vs project charter: Which do you need?

  

  So you’ve just started a new project, and you’re not sure what you’re supposed to create. Do you need a project charter? Or will a Terms of Reference (ToR) do the job?

  The challenge is that neither document has a single universal definition, so if you join a new company and find they use ToRs instead of Charters, then it can be hard to know what they are actually looking for as part of project governance.

  And don’t get me started on how Project Initiation Documents fit in! Let’s cover that a different day – in this article I’m going to cover what each document is, how they are different, when to use which and what to do when your organization uses both (or uses the terms interchangeably).

  

  Project charters 101

  A project charter is the document that formally authorises a project to exist. It names the project, defines the objectives, identifies the sponsor and project manager, and gives the project manager the authority to use organizational resources.

  In PMI's framework (The PMBOK Guide) the charter is a formal artefact with a specific purpose: it's the thing that kicks the project off officially. The PMBOK Guide defines it like this:

  [A] document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

  PMBOK Guide, 8th Edition

  PM2’s definition is a bit longer and more specific:

  The Project Charter is a document that captures the essence of the envisaged solution in the form of high-level needs and features that gives the reader an overview of the final project deliverable(s). It includes information regarding the project scope, cost, time, and risks, as well as information such as milestones, deliverables, and project organization and approach. It is a document initiated by the business sponsor that formally authorizes the existence of the project and the project team and provides the Project Manager (PM) with the authority to use organizational resources to staff project activities. The final responsibility for the quality of the Project Charter lies with the Project Manager (PM).

  PM2 Methodology Guide, Version 3.1

  I’d argue that you could skip content on project risks and the budget, as this will be covered in the business case, but it’s up to you (or your PMO template).

  PRINCE2 calls these Project Briefs.

  Here are the key things a charter typically contains:

  • Project purpose and justification: why are we doing this?
  • High-level scope: what's in, what's out and/or a list of deliverables
  • Named project sponsor and project manager
  • High-level budget and project timeline, even a table of milestones will do
  • Extract from the stakeholder register listing key individuals (or at least the departments impacted by the work)
  • Assumptions, dependencies and constraints
  • Formal sign-off / authorization i.e. someone approves the document.

  You won’t have any info on resource allocation, the work breakdown structure or any of that detail, so don’t worry about including it.

  A charter is often more formal in tone and structure than a ToR. It's typically signed by someone senior. It's a statement of intent and authority, not a working governance document.

  Technically, it should be written by someone who is not the project manager, but in practice, you can normally count on your senior leaders to need your help to get it together. And if you’re using the PM2 methodology, then it’s firmly on your To Do list to get the document done.

  Charters are typically a one-pager, or as short as possible! Some organizations have them as project posters, which is a nice option if your team is co-located and you can put it up on the wall.

  Terms of reference explained

  A ToR defines how a group works, what it's responsible for, and what authority it has. It's primarily a governance document, it's about people and process rather than project justification.

  It’s a really versatile document. You can have a ToR for a steering group, a workstream, a change advisory board, a program board. A ToR can exist without a project charter, and vice versa.

  Read this next: How to write a Terms of Reference (includes a free template!).

  ‘Terms of Reference’ isn’t a phrase you’ll find in the PMBOK Guide. In PRINCE2, ‘Terms of Reference’ is mentioned in passing as something to cover in the project mandate – they are using it not to mean ToR like I am here, but more ‘the things that you need to cover off in the project to help you get it done’.

  PM2 also has no reference to Terms of Reference.

  Where they overlap and why people get confused

  I think part of the challenge of using a ToR is that of the 3 project management frameworks/methodologies I’ve looked at (PRINCE2, the PMBOK Guide and PM2), none of them use ToR as a formal project document for managing the project.

  Running a meeting or defining what a committee should do is the perfect use case for a ToR but that’s not a project management-specific job, so the guidance doesn’t cover it.

  So, let’s review. Both documents can contain:

  • Project objectives and scope (pull this from the business case to save writing it again)
  • Roles and responsibilities
  • Stakeholder information
  • Some level of governance or decision-making process

  In some organizations, the project charter has grown over time to absorb what would traditionally be ToR content, particularly roles, responsibilities, and governance. In others I’ve seen the ToR is used at project initiation in place of a charter. And in fact, I have done this, to define workstreams within a larger project and where it helped the team see what they were responsible for.

  The practical difference

  So where does that leave us in the charter vs terms of reference debate? Here’s a simple way to look at it.

  A project charter says: this project is authorized, here's what it's for, here's who's in charge

  A ToR operates one level down. It either defines how a governance group functions within the project, or scopes out a piece of work within a larger initiative. It assumes the project has already been authorized; it's dealing with how things work inside it.

  In other words, if the document is answering the question, "Why does this project exist and who's sanctioned to run it?" then it’s a charter.

  If it's answering, "What is this group responsible for, or what is this workstream here to deliver?" then pull out your ToR template.

  On a large program you could use both, and you'd expect several ToRs at different levels: like having one for the program board, one per workstream, possibly one for any specialist advisory or review groups.

  When to use a project charter

  You would use a project charter when:

  • You need formal sign-off to start a project — particularly where resources, budget, or cross-functional commitment are needed
  • You are working in a PMI or PMBOK-aligned environment where the charter is an expected artefact (sorry, some governance structures and PMOs mandate it!)
  • The project needs visible executive authorization because the charter signals seriousness and gives you credibility as the project manager
  • You're starting something new and there's no existing governance structure around it, because you have to have something that sets out what you’re doing, right?

  Unsurprisingly, this document is created at the beginning of the project lifecycle.

  I would also use a charter if you’re already worried about scope creep at this stage, because having it all written down will help you control it later.

  When to use a terms of reference

  You would use a terms of reference when:

  • Setting up any recurring group or committee e.g. steering group, working group, review board
  • Defining a workstream within a larger program or project
  • A group has been running informally and needs to be formalized
  • You need to document decision-making authority clearly like who can approve what and what happens when there is conflict or a voting tie

  If you're producing both, make sure they're consistent. The scope in the steering group ToR should align with the scope in the charter. The decision-making authority in the ToR should make sense relative to what the charter has authorized. Otherwise your stakeholders are just going to get confused.

  What if your organization uses the terms interchangeably?

  If you’re anything like me, you’ll work with stakeholders who don’t have a great understanding of project management terminology. They could use the phrases interchangeably to mean the same thing.

  My advice is: don't get into a terminology argument. Find out what the document is actually supposed to do in your context: is it authorizing the project, or governing a group? Or do they actually mean a Project Initiation Document that is completely different again?!

  When you know what they think they want, you know what you’re supposed to be writing.

  Your next steps

  Honestly, what you call it matters less than getting the content right.Whether your organization calls it a charter or a ToR (or something else), what matters is that someone has written down what the project is for, who's in charge, and how decisions get made, and that the people involved have agreed to it.

  Save it to a shared drive, Teams or link to it somewhere in your project management software so everyone can see it.

  If you're building out your project governance documents, the terms of reference template is a good starting point. And if you need more help, book a power hour call.

  This article first appeared on Rebel's Guide to Project Management and can be read here: Terms of reference vs project charter: Which do you need?