Project managers make decisions all day. We decide how to structure the work, who needs to be in a meeting, what needs escalating and whether a risk response is worth the effort. But the bigger the decision, the less likely it is to be ours to make.

At some point, the choice belongs to the sponsor, project board or another senior leader. That’s where a different project management skill becomes important: helping the person with the authority make a good decision, at the right time, with enough information to understand the consequences.

That is not the same as learning another decision-making technique. If you want the mechanics of working through a choice, start with my guide to project decision-making. Here, I want to focus on the project manager’s role in executive decision support: turning delivery detail into something senior leaders can actually act on.

Know which decisions are actually yours

One sign of an experienced project manager is that they don’t escalate everything. Senior leaders do not need to approve every change in meeting dates, every small spend decision or every adjustment to the plan. If you have delegated authority to deal with something, deal with it.

Equally, do not quietly make a decision that sits outside your authority simply because getting time with the sponsor is difficult. I have seen both extremes: project managers who ask permission for everything, and project managers who carry on making increasingly significant calls because “someone had to decide”. Neither is particularly helpful, and both can get you into trouble.

Get clear on decision rights early. Your governance arrangements should tell you what can be decided within the project team, what belongs with the sponsor (or steering) and what needs wider executive approval, through investment committees, the PMO, change boards and so on. Tolerances, delegated financial authority, terms of reference, and escalation thresholds all help.

The practical test I use is: does this decision materially change the business case, benefits, risk exposure, strategic intent, budget, timeline or operating model? If yes, it probably needs to go upwards. If not, you may be able to make the call and keep the project moving.

Translate project information into business consequences

Project teams live in detail. We know which test script failed, which supplier is late, how many tasks have moved and why the integration environment is unavailable. Senior leaders rarely need all of that information.

They need to know what the detail means.

For example:

• Project information: “Testing is two weeks late.”
• Decision-support information: “If testing moves beyond 30 September, we lose the only implementation window before peak trading. We can add testing capacity now, reduce scope, or move the launch to January.”

The second version gives the decision-maker a consequence and a choice. It connects delivery performance to something the business cares about.

This is why business acumen matters for project managers (it’s specifically called out as a PMI Power Skill). It's still a development area for many project professionals. PMI’s 2025 Pulse of the Profession found that only 18% of project professionals demonstrated high business acumen, and those with stronger business acumen were more likely to meet business goals, schedules and budgets.

You need enough understanding of the business case, benefits, operating model and strategic priorities to explain why a project issue matters outside the project team. A red milestone is not inherently interesting, although I know many execs will want to go straight to that, so they can fix it. It’s the effect of that red milestone on revenue, compliance, customer experience, capacity or another strategic objective that they should be caring about.

Bring a recommendation, not just a problem

There are times when the right thing to say is, “I don’t know yet.” But there are many more occasions where the project manager can do (at least some of) the analysis before asking the sponsor to choose.

Instead of taking a problem to the project board and asking, “What do you want to do?”, prepare the decision so the group can spend its time making the choice rather than discovering the issue from scratch.

A useful decision brief includes:

• the decision that is required
• your recommendation
• the realistic alternatives
• the main trade-offs
• the evidence behind the recommendation
• what happens if no decision is made
• the date by which you need the decision.

That does not mean pretending there is only one sensible answer. Your recommendation may be based on delivery considerations while the sponsor has access to commercial, political or strategic information that changes the picture. Your job is to make your reasoning visible so they can challenge it.

Being able to make a recommendation is not only a project management skill. The World Economic Forum’s Future of Jobs Report 2025 found that analytical thinking remains the most sought-after core skill, identified by 69% of employers, while leadership and social influence was cited by 61%.

It is also worth separating solving the underlying issue from choosing what to do next. I have written separately about the difference between problem solving and decision making. They are related, but they’re not the same activity.

Build enough business acumen to understand the trade-offs

You don’t have to become a finance director to support executive decisions. However, it helps enormously if you understand the language behind the trade-offs you are presenting.

Depending on your environment, that could mean understanding:

• Opportunity cost: what else cannot happen if resources stay on this project
• Cost of delay: what waiting another month actually costs the organization
• Benefits and value: what outcome the project is meant to create, not simply what it is delivering
• Total cost: including ongoing support, licences, maintenance, training and operational effort
• Strategic fit: whether the initiative still supports the priorities the organization has today, not only the priorities it had when the business case was approved.

Most project managers build this knowledge through experience: sitting in governance meetings, working with Finance, talking to sponsors and seeing what happens after a project goes live. Mentoring and cross-functional work help too.

Formal study is another route if you want a broader grounding in finance, strategy and leadership. For example, a Master of Business Administration online can provide a structured way to learn how the different parts of an organization fit together.

You don’t need an MBA to become a strategic project manager, but you do need to understand enough about the business to recognize what makes a trade-off important.

Be explicit about uncertainty

Executive decisions are often difficult because the information is incomplete. If the answer were obvious and the data perfect, the decision probably would not need much senior attention.

One of the most useful things you can do is separate what you know from what you think is likely to happen. Label the information clearly.

• Facts: things already evidenced or agreed.
• Estimates: numbers based on known inputs and an estimating approach.
• Assumptions: things you are treating as true for planning purposes.
• Forecasts: your current view of what is likely to happen.
• Unknowns: information you do not yet have and may not be able to get before the decision is required.

Avoid false precision

I would much rather tell a sponsor that the cost is likely to be between £180,000 and £230,000 than present £204,738 as if we have somehow achieved perfect certainty. False precision does not make a recommendation more credible!
Although I also remember being told as a young project manager that not submitting a round number made it look like we’d worked out the budget forecast somehow, instead of just guessing, which is what we were basically doing.

How you present the information matters too. The same facts can feel very different depending on whether you emphasize the potential gain, the potential loss, the short-term impact or the long-term consequence. My article on the impact of framing in decision making goes into that in more detail.

And if you are wondering why capable people still make poor choices when they have plenty of information, there are some common traps. I cover three of them in 3 things that stop you making the right decision.

Match the decision process to the decision

Not every decision needs a workshop, thankfully. Not every decision should be made by one senior person either.

Think about what kind of input will give you the right data for the decision. A technical architecture decision may need specialist advice. A change to a frontline process probably needs input from the people who will use it. A time-critical incident may need one person to decide quickly so everyone else can get back to work.

If a collaborative approach is appropriate, I have a practical guide to helping teams make group decisions. There are also situations where autocratic decision-making is the no brainer choice: someone has the authority, the decision is time-sensitive and wider consultation will not materially improve the outcome.

You can also reduce the stakes by avoiding one giant, irreversible decision. On uncertain projects it may be possible to approve a pilot, fund the next tranche or test an assumption before committing further. That is close to the incremental model of decision-making: moving forward in smaller steps as more information becomes available.

Manage the decision pipeline, not just individual decisions

A project can have perfectly good governance and still grind to a halt because decisions are sitting with busy people – this is decision latency, the slowness of decision-making.

One outstanding decision may not be a problem. Five decisions, each dependent on the one before it, quickly become a delivery issue. I think of this as decision debt: unresolved choices accumulate until the team is spending more time working around them than moving the project forward.

Manage significant decisions as actively as you manage risks and actions. For example:

• Keep a visible list of decisions waiting for action
• Give each decision an owner and required-by date
• Show the impact of missing that date
• Pre-circulate and socialize major decisions with key stakeholders before the formal meeting
• Make the decision ask obvious in papers and presentations
• Escalate an impending decision delay before it becomes a schedule delay.

And please do not hide the decision on slide 17 of a 30-slide project board pack. If you need the group to choose something, say so at the beginning, because who is going to read to slide 30?

A clear heading such as “Decision required: approve Option B by Friday” is far more useful than hoping everyone spots the ask in the discussion. Pop it in the exec summary right at the front.

Close the loop after the decision

The meeting finishes, everyone closes their laptops and the conversation moves on. That is exactly the point where a decision can disappear.

Confirm what was agreed, especially if the discussion moved away from the options originally presented. I worked with a sponsor who was incredibly good at this. He would summarize the actions and decisions in the last 5 minutes of the meeting, even though I had been taking the minutes. He must have had his own notes because the meetings could get a bit rambly.

Then turn the decision into delivery: update the schedule, budget, risks, scope or communications as required.

For decisions that matter, record the rationale as well as the answer. Six months later, “We chose supplier B” is much less useful than “We chose supplier B because they were the only bidder able to meet the regulatory deadline, despite the higher cost.” A project decision log gives you a simple structure for keeping that history.

Five habits that make your advice easier to act on

If you want senior stakeholders to see you as someone who helps them make decisions rather than someone who simply reports project status, these are the habits I would focus on.

1. Lead with the decision required. Do not make people listen to ten minutes of background before they understand why you are in the room.
2. State your recommendation. You are allowed to have a professional view, even when someone else owns the final choice.
3. Quantify what matters, but do not invent precision. Use ranges, assumptions and confidence levels where that is a more honest presentation of where you are now.
4. Say the uncomfortable trade-off. If saving three weeks means accepting more operational risk, say so plainly.
5. Say when you need the answer. A decision without a required-by date has a habit of becoming tomorrow’s problem!

For more ideas on strengthening your own everyday judgement, see my 5 tips for making better decisions every day.

Make yourself useful at the decision point

Becoming more strategic as a project manager is not about pretending to be a senior executive. It is about understanding the business well enough to recognize what matters, applying project judgement to the evidence and making the consequences of each choice clear.

That means doing the analysis before the governance meeting, knowing where your authority ends, presenting uncertainty honestly and making it easy for the right person to choose.

Do that consistently and you stop being the person who turns up with a status report and a list of problems. You become the person whose advice helps senior leaders decide what happens next.

This article first appeared on Rebel's Guide to Project Management and can be read here: 8 Ways for project managers to support better exec decisions

There are multiple stakeholders, different views on how things should be done, different channels to use, and no one has the time to do anything any longer.

I believe that project managers have had to move into the space that used to be filled by internal communications or change managers.

Those roles still exist and support large projects, but many smaller or internal projects don’t get that support, so as project managers, we step in to fill the gap.

That’s what I’m researching at the moment, and I’d love to hear how it is for you, communicating your project. The short survey below will let you tell me what challenges you face. Skip any questions you don’t want to answer, and add as much detail as you like where you have more to say!

I appreciate any and all answers, and at the end, there is a project communications health check spreadsheet you can download, plus a worked example so you can see how to use it to assess the comms maturity on your project. You don’t even need to leave your email address, but if you do, I’ll send you the survey results when they are available.

Thanks in advance! (And please share with your teams!)

This article first appeared on Rebel's Guide to Project Management and can be read here: Project Communications: Take the Survey

You sent the email. You explained the requirement. Everyone nodded in the meeting. And yet, two weeks later, people have interpreted the message differently.

Communication models aren't just academic diagrams: they give project managers different lenses for diagnosing why communication isn't landing. And given that project communication is a huge part of most people's jobs, it's worth understanding a bit about it.

What are communication models?

Models of communication are ways of understanding how communication flows between individuals and groups. There are lots of ways to improve project communication, and understanding some of the theory really helps.

Below, you’ll learn about these theories of communications:

• Shannon-Weaver
• SMCR (Berlo)
• Lasswell
• Schramm.

How can communication models help?

So how do we take communication theory and make it practical for projects? The table below shows where you can take a model and apply it to a problem at work.

1. Shannon-Weaver

The Shannon-Weaver model is actually taught on Project Management Professional (PMP) training courses.

Most useful for: Understanding what is getting in the way of the message.

This model looks at the communication process. There is an information source (person) that is translated by the transmitter (email/phone etc) which the receiver receives and then decodes at their end. The process can get interrupted by noise (disruptions in the process e.g. poor signal, language barrier etc).

It’s a linear communication model works well for interpersonal (one-to-one) communication as it’s clear to see the application where the information source is a person and the receiver is another person.

However, it also works in groups, for example in a town hall meeting or where one person is emailing a group – in this group or mass communication situations you would expect there to be more noise. And with communicating to customers, even more.

Dealing with noise in communication

Project communication has plenty of noise.

Noise isn't just a bad Teams connection. It can be jargon, assumptions, competing messages, cultural context, distractions or simply giving someone too much information at once.

There are four types of noise in communication:

1. Physical and environmental noise e.g. a bad connection, crosstalk or background noise, gatekeepers who change or dilute the message (on purpose or accidentally)
2. Physiological noise e.g. being hungry, tired or ill so you don’t focus on what is being said or, as the speaker, presenting your message clearly
3. Psychological noise e.g. being angry, stressed or holding opinions that mean you don’t absorb or present information clearly
4. Semantic noise e.g. lack of shared context, inability to access paraverbal and non-verbal messages e.g. people with their cameras turned off

We have to choose the right method to transmit to meet the needs of the recipient and do our best to avoid noise. For example, not making calls in a noisy environment (literal noise) or turning on automated captions (to reduce issues with language barriers).

So much of my communication is computer-mediated these days so noise has to be factored in. Shannon-Weaver is the only model that specifically mentions noise, although the others talk about the message being influenced by various factors, which would cover the disruption and interpretation of the content.

I hold most of my regular mentoring sessions on MS Teams, and it’s not as good as face-to-face for feeling like you truly understand what someone is saying because interpreting body language is harder. It’s also much easier to get distracted and get away with it. That’s noise.

2. SMCR (Berlo)

Berlo’s model is specifically called out in the Praxis Framework for projects, programmes and portfolios. It’s a transactional model (i.e. considers communication as a two-way process) and has four components.

The sender encodes the message which is passed through a channel and decoded by the receiver.

SMCR asks you to consider four things: who is communicating, what they're saying, how they're communicating it, and who is receiving it. Each can affect how the message is interpreted.

• S: Source: Influenced by communication skills, attitudes, knowledge, social norms and systems, impact of culture on comms
• M: Message: Influenced by the content and elements of the message, treatment of the subject, structure and code.
• C: Channel: influenced by delivery mechanisms e.g. hearing, seeing, touching, smelling, tasting.
• R: Receiver: influenced by the same as the source.

Most useful for: Am I choosing the right message and channel for this person?

Different channels will be useful in different ways, and you are encoding and decoding messages all the time as a project leader.

How to use SMCR

SMCR prompts us to consider how the social and communication skills of the person passing the message influence how it is received, and that we should take those same skills into consideration when looking at how someone may receive the message. For example, if they have a different attitude to the topic to us, they may interpret the content of the message differently. Most of what I do relies on sight and hearing, I don’t often do any mentoring or training where other senses are used to pass along information.

Read next: How to choose the right communication channel for your audience.

I now work with a mainly native British team or people who have been in the UK a long time, but I used to work with a much more diverse team with members from across Europe. We had to make sure communication avoided colloquialism and was paced appropriately for those who had English as an additional language.

Project Management Rebels meets once a month and I sometimes do training in that, or run webinars for project managers. This is group communication, and I do try to take preferences into consideration but we are limited by the tech available.

I try to make these sessions interactive with lots of case studies and examples, asking and answering questions to keep people engaged and to ensure I’m using examples that are relevant to the audience so social norms, organisational systems and cultures are things they can relate to, which reduces the barrier to understanding.

3. Lasswell

Lasswell’s model has been around since the 1940s and the premise is that effective communication has to have an effect. It is based on 4 parts: the speaker, the subject, the channel and the person receiving the communication. If these are in place, the final question is ‘what’s the effect?’

It’s still a linear transmission model that doesn’t include the feedback loop to see if people actually do what you want them to, but that doesn’t stop you including that step.

Most useful for: What do I actually want people to do as a result?

Before you communicate, ask: “What do I want to happen?”

For example:

• Stakeholder update – maintain confidence
• Risk or issue escalation – secure a decision
• Team message – change behaviour
• Project board paper – obtain approval
• Lessons learned – change future practice

Honestly, this model feels very basic and very much predicated on communication being one-to-one which is rarely the case for project managers. Perhaps that was the case at the time, but I doubt it: there has always been a need to communicate to team members in groups, even in the 1940s, so that is a limitation of the model.

We do a lot of email and text-based communication, and we need to be able to communicate clearly in writing. Those written messages tend to be used for groups, so the effect required needs to be taken into account. If you want people to take an action, you have to be really specific.

Modern, office-based communication generally tells you the effect they want, if it’s directional or task based information. We won’t share information and hope that there is an effect. It will be spelled out: “please reply by Friday” etc.

4. Schramm

Schramm’s model covers the source, the message, the destination. It’s considered an interactive model as the comms is circular as feedback is built in. It was developed into the Osgood-Schramm model later.

The premise is that there must be some understanding or something in common (the ‘field of experience’) for the communication to work effectively.

In other words, communication isn't successful because you sent the message. It's successful when you and the recipient have created enough shared meaning to act on it.

For example:

• Project manager says, “The project is Amber” – does everyone know what Amber means?
• Finance says, “Forecast variance” – does the delivery team understand the implication?
• Technical team says, “API dependency” – does the sponsor understand the consequence?
• Project manager says, “We need comms for stakeholder engagement” – does everyone agree what that actually means?

In project management we have so much jargon it’s easy to see how lack of common professional background makes it harder to make messages land appropriately.

Most useful for: How do I know they've understood me?

How is Schramm different from Shannon-Weaver?

Schramm’s premise is different to Shannon-Weaver (and was published afterwards, building on their work) because the recipient of the communication is not passive, but actively engaged by providing a feedback loop.

Shannon-Weaver is about transmitting info – it’s very one-way.

Schramm has a feedback loop built in. Communication is a continuous loop. The sender encodes the message based on their field of experience, transmits it via whatever channel they choose, and then the receiver decodes it, providing feedback.

Disadvantages of Schramm

This model is limited by having a single sender and recipient, so it’s not so easy to apply to group communication. It can be hard to get feedback on a group basis like public speaking, or where feedback is delayed. The model works best for one-to-one, face-to-face comms.

It ignores any power imbalance and internal politics (although I suppose we could include those in the ‘noise’), and that is frequently the case for project stakeholders and change management comms. Here, the issue is that it can be hard to provide honest feedback to people in power.

Also, Schramm expects there to be turn-taking in conversation, which is often the case in face-to-face discussions, but it doesn’t work like that with online comms. I can be having a Teams conversation with one person, getting info from another, do a quick call with someone else and then email the stakeholder the answer, so comms strands can be multi-overlapping on the same topic.

Communication models in project management: a practical example

Let’s take one scenario and run it through all four models: a project manager needs stakeholders to understand that a project milestone is at risk.

Shannon-Weaver: What noise could distort the message? The action for you is to make sure that you understand how best to land this message with the stakeholders, so you minimize the noise.

Berlo: Is the sender credible? Is the message appropriate? Is the channel right? Does the stakeholder have the knowledge to interpret it? The action for you is to address all of those so the message has the best chance of landing.

Lasswell: What do you want the stakeholder to do? The action for you is to think this through beforehand and decide on the collaboration expected. Do they need to tell their teams about the risk? Do they need to make a decision? Then present that clearly.

Schramm: How will you know they've understood and agreed with your interpretation? The action for you is to consider how you’ll get feedback. Will it be because they’ve taken the action you needed, or through the questions they ask?

Remember, there is no single right answer here. How you communicate day-to-day is going to be different from how you communicate in a crisis, or in other scenarios.

Case study

Recently, I supported a colleague to complete his time tracking for the first time. He joined last month and had not gone through the process. He messaged me and I rang him back to take him through the system. Using screensharing, I displayed the time tracking files and showed him what to do, using examples from past months to illustrate the kind of thing that is expected.

This was effective because showing him the tool and what people had completed in the past is a very tangible way to quickly understand what to do. He could take screenshots and I got immediate feedback. It was a more useful way of communicating than if I had, for example, called his landline phone and tried to explain it to him with no visuals.

Your next steps

You don’t have to choose one model, and in fact, I wouldn’t. They all have their uses, and you can see from the case study above that choosing the right channel, minimizing noise, asking for and expecting feedback, and being clear about what you need the recipient to do are all parts of making sure communication is effective. You can build all of this into your project communication management approach.

You also don’t have to memorize the models. Instead, try to remember the questions that each model prompts:

• Shannon-Weaver: What's getting in the way?
• Berlo: Am I communicating appropriately for this person?
• Lasswell: What do I want to happen?
• Schramm: How do I know they've understood?

Pop some notes in your communications plan template so you don't have to keep looking this stuff up.

The important point is that sending a message isn't the same as communicating effectively. Your email can be beautifully written and still fail. Your presentation can contain all the right information and still leave people confused. Your stakeholder meeting can end with everyone nodding and still result in four different interpretations of what was agreed.

Before your next important project communication, pause and think about the four questions above. Then consider what you need to do differently: remove some noise, change the channel, make the required action clearer, or create a way to check understanding.

Good project communication isn't about communicating more, although that sometimes helps too! It's about making sure the right message reaches the right people, in a way they can understand and act on.

This article first appeared on Rebel's Guide to Project Management and can be read here: 4 Communication Models Every Project Manager Should Know

What is a ROM estimate?

A rough order of magnitude estimate is used to give you a very high level view of potential project costs.

Ideally, you’d be able to provide a definitive estimate, carefully created from loads of input from subject matter experts and plenty of research on past projects and their budgets.

But in reality, we rarely have the time or luxury of being able to provide that level of estimate at the earliest stage of project.

A ROM estimate is useful when you need to make a decision before you have enough information for a detailed estimate. It gives you an early indication of likely cost, time or resources, but it should not be treated as a firm project commitment.

What is ROM used for?

Think of the ROM estimate as used for informational purposes at the beginning of the project. It’s not really something you should use for too long – it’s important to get to a more accurate view of project costs as soon as you can.

Often, execs simply want an overview of how much the work might cost. And we haven’t yet received the mandate to do a deep dive into requirements and scope that would enable more accurate results from the budget forecasting.

The PMI Practice Standard for Project Estimating mentions ROM as an option for adaptive project life cycles. It says:

During initial planning, the project team determines the number of initial iterations and their durations by approximating the effort needed.

The ROM variances are replaced reasonably quickly with more detailed estimates, after the initial planning gives you more information.

ROM estimate vs definitive estimate and when to use them

Later in the project, you can provide those detailed estimates, and this is really what execs want to see.

ROM and definitive estimates aren't competing approaches, one isn't 'better'. They are a natural evolution of project management work and appropriate at different points in the project lifecycle.

A definitive estimate is what you should end up with once your budgeting analysis is fully complete. It’s a very realistic view of what the overall project expense will be – and you create it by refining your higher-level figures and moving from general information to detailed information.

As you move through the project, you should be able to produce more accurate estimates with smaller ranges relating to accuracy. As the level of detail increases, the range that represents the accuracy of the ROM estimate decreases until it’s not really a ROM any longer – this is when you would use a definitive estimate.

I’d still recommend that you present definitive estimates as a range because there could still be extra cost – or you could come in under budget. This could also be included as project contingency.

PMI no longer provides specific guidance on what a definitive estimate range should be in their latest guidance. The PMBOK® Guide used to suggest it could be from -5% to +10%, but again, use your common sense for what works for you and what your Finance team or PMO advises in their internal guidance.

OK, back to ROM!

Want to know more about analysis and estimating? Check out my article on 4 Categories of Project Management Methods.

How do you present a ROM estimate?

I always encourage managers to present budgets as a range, because single-point estimates often trap you into a certain mindset where there is no scope for change, whatever the reason.

ROM estimates are no different, except the range is big. The budget figures are represented in line with the level of accuracy you have at the time. So they are shared as a + / - % figure.

The range is a way of representing the degree of confidence or accuracy level in the number.

But don't give your sponsor a number without explaining what it means. Share it like this:

£1.2m ROM estimate
Current estimate: £0.9m–£2.1m, based on the information available at initiation.

Include the assumptions behind the range, for example:

• Scope is still high level
• Supplier costs aren't confirmed
• Resource requirements are based on similar projects
• Requirements may change
• Technical solution hasn't been fully designed or approved by the architect.

When do you use a ROM estimate?

Use the rough order of magnitude as an estimation technique for when you don’t have a lot of clarity about the project budget.

It’s used in the early stages of work, to establish the estimate cost with the information you have. It builds in a lot of variance, so if you can’t create an accurate estimate because you don’t have all the detail (which is… always before you’ve done the planning), the ROM pricing will give you a ballpark estimate based on best guesses and with plenty of hedging built in.

Not sure when to use a ROM estimate or whether it's right for your project? You can learn everything you need about estimating in our Project Estimating Guide.

Why would you use an estimate that’s so vague?

Because some information is better than none! Whether you use T-shirt sizing (XS, S, M, L, XL, XXL) or a rough guess, the human brain is used to dealing with vague values.

A rough estimate provides a relative view of how large a project is (or how small) in relation to others in the portfolio. A cost of £1m might be small for some firms, but substantive for others, so an early overview of what costs could help people make a decision about next steps.

It can also inform your work breakdown structure. You can identify which chunks of work will fall into which cost ranges.

What types of projects can use a ROM estimate?

Any type of project can use a ROM estimate. They are useful for:

• Larger projects, where you need to provide management information and an initial estimate before you have all the detail for a more definitive estimate.
• International projects, where you may have to include costs from various countries and take currency conversion into account.
• Innovative projects, where cost drivers for the deliverable or new product are unique and pioneering, and the exact project scope is being progressively elaborated or managed through agile techniques.
• Construction projects, where you have to provide a ROM budget figure to a client.
• Projects with larger value budgets, as generally you can estimate small figures more easily than you can large amounts.
• Projects where you’ve got historical information; NASA’s cost estimating handbook version 4.0 talks about analogy cost estimating being an application for a ROM estimate.

They are less helpful for project managers where you’re doing the same implementation time after time and have a pretty good idea of exactly how much each part of the work costs.

For example, simple software implementations or an installation for clients where it’s basically the same effort and resources required every time.

If you’ve got the historical data, you may as well go straight to a detailed, more accurate project cost figure (especially if you are presenting those numbers to a client).

How do you come up with a ROM estimate?

Erm… to come up with a ballpark figure, basically, you guess.

This estimating technique is top-down, meaning you don’t need to know the exact details of what’s going to be done on the project. Just take the parts you do know and apply some professional judgment.

Break the project work into chunks. Apply some sensible categorization to each chunk. Is it a high, medium or low effort piece of work?

Your PMO might have definitions for each of those to help you define and refine your estimates at the early stages of the project. For example:

High effort:

• More than 6 weeks of work
• More than 10 people required to do the task
• More than £x required

Medium effort:

• Between 2 weeks and 6 weeks of work
• Between 3 and 10 people required to do the task
• Between £x and £y required

Low effort:

• Less than 2 weeks of work
• Only 1 or 2 people required to do the task
• Less than £x required.

If your PMO does not have standard categories like this, you can make them up. This gives you some assumptions to work to and a way of explaining how you came up with the estimate. They might also have a ROM calculator if your business regularly prices client projects and has a standard way to do it.

Estimate each chunk based on your effort estimation and then add the chunks up and apply the ROM variance range to the final figure.

Tip: Don’t forget to include your time! Apply a percentage of the overall time estimate as representative of the project management effort involved. I tend to use 20% for this, so if a project task is going to take a week, I’ll assume I need a day of PM effort for my part in keeping everything going.

What’s a typical Rough Order of Magnitude for project estimating?

‘Orders of magnitude’ has a specific meaning in scientific notation and mathematics, but in project management, it typically refers to broad-brush categorization for sizes. In other words, we're asking how accurate is a ROM estimate.

ROM is considered the broadest, least accurate way of representing the budget. (If you don't count completely making the number up.)

There is no perfect ‘bucket’ for what boundaries you should put on your ROM and ROM accuracy ranges are not universal.

The Project Management Institute used to provide guidance in the PMBOK Guide Sixth Edition that said a ROM estimate is within the range of -25% to +75%. However, ROM cost estimates are no longer mentioned in the current version of the Guide.

Talk to your Finance department to see if there are internal cost management and forecasting standards to apply to, or just get the range as accurate as you can based on your professional judgment. The ROM estimate accuracy is not expected to be high, so don't worry too much about it.

Let’s look at an example to see how it would work in a project budget.

ROM example

Let’s say that we’re in the Project Initiation phase. We don’t know the total cost of the project – at least, not an accurate cost. The business case has been approved already with a budget that’s very high level, and now the exec sponsor is asking for more information about what the work might realistically cost.

We just need a first estimate.

We review the different estimation techniques available to us and decide that we don’t have enough information about the work packages and tasks to give anything more than a budget estimate in a range that puts it in a very rough ballpark.

We take a quick look at previous projects -- lessons learned are a good starting point. We consult subject matter experts (who are unwilling to commit themselves to a ‘real’ number because they haven’t seen the detailed requirements yet) and talk to them about what their effort cost last time. After much cajoling and negotiation, we get an idea of how much this project is going to cost.

However, it’s based on so many ‘what ifs?’ and assumptions that we can’t possibly have confidence putting that number in front of the steering group.

So, we present it as what it is: our best estimate based on all the knowledge, information, and professional judgment available to us. We share it as a range so everyone can see straight away that it’s not a single figure.

The accuracy of the ROM estimate is represented in the range. We share the budget, based on our research and understanding of what the project will deliver, as £1.2m with an accuracy range of -25% to +75%, like this.

• Initial ROM: £1.2m
• Range: £900k–£2.1m
• Confidence: Low
• Key assumptions: 12-month delivery, existing team, no major technology procurement
• Biggest uncertainties: scope, supplier costs and resource availability

This means that our total project budget, based on today’s estimates, could be as low as £0.9m or as high as £2.1m (gasp!). That’s quite a variance.

With that information, the steering group can start to prepare themselves mentally for the outcome of the detailed project planning and what that might mean for a more accurate version of the project budget.

When to revise the ROM estimate

The rough cost estimate is not designed to last for the whole project life cycle. In fact, you should be refining and improving your budget estimates all the time, especially through the planning stage.

The estimate changes as you gather:

• better requirements
• supplier quotations
• resource information
• solution design
• delivery assumptions
• risk information

A ROM estimate is not "wrong" because it changes. The expectation is that your estimate will become more precise as uncertainty reduces, and leaders expect that.

Make sure your keep your RAID log updated with any changes to your budgeting assumptions.

Project cost management is something you do throughout the whole project, and your budget is under constant review.

When should you stop using the ROM estimate?

As we've seen, the ROM cost shouldn't become a permanent project budget. As you learn more about scope, requirements, resources, suppliers, delivery approach, risks and assumptions, you should revisit the estimate.

If your project has moved into detailed planning but you're still reporting the original ROM as though it were a firm budget, you've got an estimating problem.

What is a ROM quote?

A ROM quote, or ROM price, would be provided to you by a supplier. Or you might be the supplier, providing it to the client.

Essentially, it's a pretty vague statement of how much they think the work will cost at this time. It's common in construction -- when we had an extension built on our house, the project manager came round to view the property and then told us the ballpark figure of how much the work would cost. That was before they'd done a proper survey or anything, so it's a good way to understand whether you want to go ahead with the work at all.

It's also a faster way of gathering multiple quotes so you can see if suppliers are all broadly providing similar costs at this time, or whether one is particularly cheaper or more expensive than the others -- why would that be?

The ROM calculation from the supplier's side also helps them work out if they want the job. If it's too small a piece of work, based on the high-level requirements provided, they might not want to contract with you.

FAQ

This article first appeared on Rebel's Guide to Project Management and can be read here: How to calculate a ROM estimate and when to use it

Once upon a time I used to try to plan my projects around dates when I knew I was going to be in the office. My colleagues joked that I planned the birth date of my first child around a major transformation project go live date (I didn’t). It turned out that we had to move that go live by three months, so I was on maternity leave with a new born when they eventually went live.

As experienced project managers know, when things change on a project, all your carefully planned deadlines switch around too.

In this article, we’ll look at how to plan and execute a handover to a colleague. Looking for specifics on how to write a handover email to your manager? I have a full article on that too, with templates, so be sure to check it out!

If your project is closing, read my guide to how to handover a project at closure instead.

Reasons to handover your work

At some point in your career, you are going to have to handover your project to someone else. That could happen for a number of reasons:

• Maternity leave
• Paternity leave
• Parental leave
• Planned medical leave
• Someone moving to backfill a role elsewhere in the organization
• Vacation time, annual leave or booked holidays
• Unpaid leave of absence
• Employee resignation or a departing employee (perhaps you) means work allocations have shifted around and you have to do a knowledge transfer to someone picking up your project permanently.

As you can see, those reasons split between a temporary handover (when someone else takes responsibility for your work for a short time) and a permanent handover (when you are leaving the project behind).

The process is pretty much the same, and either way, you need to feel confident handing over your work before your absence so you can actually switch off.

If you are leaving for good and handing over your work during your notice period, then you’ll want to be more inclusive and comprehensive. For temporary leave, you can focus mainly on passing over tasks that need to be completed during the time you are unavailable.

Vacation handovers

The most common reason for briefing someone else on your work is that you have a holiday planned. A vacation handover helps you both. It means you have to think about what might happen and plan for it. It helps your colleagues deal with stuff while you are away.

And most importantly, it means you can go away knowing that nothing will go wrong while you are out of the office.

A holiday handover tends to cover only the tasks that you need someone else to do on your behalf. That could include the following items:

• Briefing senior managers on the completion of a task
• Sending out a report (bonus points for you if you can pre-write some of it before you go)
• Being the point of contact in an emergency
• Being the point of contact for a supplier in case they need something
• Supervising the day-to-day activities of the project team and being a point of escalation if team leaders need something
• Being the approval point for key processes so that changes etc don’t get stuck in the workflow while you are away.

Mostly, projects can cope without you for a fortnight. It’s good to brief someone on what to do, but if they aren’t able to step up due to their own workload, it’s not the end of the world. Try to keep your expectations manageable.

The 10 tips below will help you put together a smooth transition plan, regardless of how long you are going to be away (or if you are ever coming back).

Here are 10 simple ways to leave your work behind and not worry about what’s going on back at base.

1. Check what will happen while you are away

Look at the calendar, project schedule, upcoming milestones, meetings, deadlines, reporting dates, approvals and supplier commitments.

Do a 'while I'm away' scan, looking for:

• What is due?
• What could go wrong?
• What decisions might be needed?
• Who might need me?
• What meetings are happening?
• What approvals could get stuck?
• What deadlines fall during my absence?
• What happens immediately after I return?

2. Decide what actually needs handing over

You don't have to handover everything if you are only out of the office for a couple of weeks. Make smart decisions to minimize the workload for everyone else.

Think about this: If something goes wrong while I'm away, what is the most likely thing it will be?

For example:

• stakeholder disagreement
• missed deadline
• supplier issue
• approval delay
• team absence
• budget question
• technical problem
• project decision
• meeting where you're normally the only person with context.

What can you do in advance to cover those scenarios, if anything? Your options normally are to prevent it, delegate it, escalate it or wait until you're back and deal with it then. Consider what you want your handoveree to do so you can brief them in advance.

3. Choose your cover person

A good cover person:

• has sufficient authority
• understands the project or work area
• knows where information is stored
• has capacity
• knows when to escalate
• isn't expected to do your entire job on top of theirs

They don't have to do everything you normally do (because they physically won't be able to). And sometimes we get told who it will be, so ask your manager if there is anyone they would like you to delegate to while you're away.

Ideally, if you are going to be out of the office for only a short period of time, you should handover all your current projects to one colleague. Look at the resource plan for the team and consider who that might be.

4. Plan your handover to a colleague and create your notes

This might sound obvious but the first step is that you need to plan to handover your work and create ‘handover notes’. I do this in a notebook because I'm a pen and paper thinker. (Read more about how I organise a notebook.)

Your handoveree (that’s not really a word, I know) doesn’t need to know everything about the project. They simply need to be briefed on the necessary information:

• Main deliverables during this time, if any
• Things happening while you are away and what they need to do about them e.g. preparing weekly reports on your behalf
• Main risks or issues that are currently on the table and might need watching (take them through your RAID log)
• Main stakeholders and the project sponsor’s contact details so if anything urgent does come up they know who to talk to
• Where they can find information about the project
• Major decisions that should be taken during this time, if any, and what your recommendation would be and/or criteria for making that decision.

You may have other things to add to that list depending on your project and situation. For example:

• The steering group meets while you're away: You can postpone or cancel the meeting, prepare the deck in advance and ask someone else to chair it, record the meeting and catch up afterwards.
• The supplier is due to deliver the revised design: Make sure the supplier knows who to send it to so it doesn't sit in your inbox for 2 weeks.
• The project sponsor or PMO is expecting the monthly status report: Draft it in advance and ask someone else to finish it off or ask for an extension.
• The change request is awaiting approval: Ask the decision makers to copy in someone else when the decision is made so the work isn't held up while you are away. Ask your cover person to chase after a certain time if they haven't had a decision.

If you are preparing handover information as part of the recruitment process – to give to a new starter because your own responsibilities have changed or you are leaving – then you will want to include a comprehensive handover report.

That should cover all the important information, a list of key files, key processes, key contacts for each of the different teams involved, specific activities that are in progress or outstanding, current issues and how much time they should expect to be spending on keeping the work moving forward.

Tip: Long before you go, make sure your team has people in it capable of delegating to while you are away. This book has some tips to help support your team and manage your own workload.

5. Set your digital boundaries

Prepare to manage your digital presence while you are away.

I’ve seen more and more people using their email signature as a way to alert people to upcoming out of the office time. I think it’s a good idea. It reads a bit like this:

Email signature, contact details, etc
Advance notice: I’ll be out of the office from Tuesday 14 July until Friday 24 July.

The text is normally in red or bolded (or both) so it stands out.

I have no idea how effective this is and whether it just means you get a ton of emails on the day before you are due to leave, but it seems like a sensible thing to do in an environment where you have a lot of messages and people need to know where you are.

Before you go:

• Set your Outlook/Teams out-of-office
• Make sure your calendar reflects your absence -- invite your manager or key stakeholders to a 'meeting' that lasts the duration of your holiday so they have a physical note in their calendars for your absence.
• Check your Teams status
• Delegate approvals where possible
• Check shared mailboxes
• Update voicemail if relevant
• Make sure your cover person has the required system permissions
• Test that delegated access actually works.

Set up an out of office email response message letting people know that you are away from your desk. You can automate it to go to internal recipients and then set a different one for external senders as well, if you’d like to tailor your responses.

Here’s an example of a bad out of office message:

I’m on annual leave until Friday. I’ll pick up your email on my return.

This doesn’t give the recipient any useful information because they cannot be sure which Friday you are talking about. Have you accidentally left your out of office message on from a previous absence?

And if they have an urgent query, they’ve now drawn a blank as you’ve given them no alternative contacts.

Microsoft Office/Teams/Outlook makes it easy to set autoresponders and out of office messages, and I've noticed that it prompts me to do so if I type something that looks like 'I'll be out of the office next week' in an email to someone. There's no excuse!

Autoresponder email template

This is a better email template:

I’m on annual leave until Friday 24 July. I won’t be accessing my email during this time. If your question is urgent, please contact:
Project Alpha: John Smith (telephone number xxx, email xxx@zzz.com)
Queries about invoices: Accounts Payable team (call xxx and choose option 3)
Other queries: Emma Jones (telephone number xxx, email xxx@zzz.com)
I’ll respond on my return.

List the contacts for each of your projects or major areas of responsibility if you have them (if you don’t, just stick your deputy on the list).

Check with each person that you name that they are happy to cover for you while you are away.

These are likely to be the people that are in your project workbook's Contacts tab.

Think about whether you want this list of internal contacts to go to external senders. The amount of spam emails I get, I wouldn’t want my colleagues’ names to end up on sales people’s mailing lists. So consider having a different message for external senders.

It’s tricky responding to queries when someone you have never heard of before calls you up with a question about a project you know nothing about (that has happened to me).

If in doubt, put your manager as your out of office contact as he or she should be able to direct enquirers to the right person on your behalf.

Teams Tip: Your out of office Outlook email will show up in your Teams status alert, so colleagues using Teams will see that you are absent.

6. Meet your colleague to handover

Set up a meeting with the person who will be picking up your work. I find that it helps to create a document with all the key points. They can then use this as a reference and update it with anything that changes. If you are coming back, they can give it to you. If you’re gone for good, they can adapt your notes into something that’s relevant for their job description.

They will also be prepared (hopefully) to receive the handover, and they'll have questions for you. They might even be using my list of what to do when you take over a project -- perhaps you should read that too so you can check out the kinds of things they'll be looking for!

For temporary handovers, make sure you are clear on what the priorities are (or should be) so they only have to focus on the really important stuff. Remember they have their own job to do too!

Walk your colleague through the judgement calls as well as the information. For example, say something like, "The RAID log says X is a medium risk. In reality, I'd keep an eye on it because the supplier has missed two dates already." That's the kind of thing that it's hard to pass across in an email.

If you have an automated approvals process or a project management workflow, such as the change management process, make sure they get access to that so that work doesn’t stop because you aren’t there.

For tips on how to talk to someone about picking up your work, read my guide to delegating tasks.

7. Remind people nearer the time

You should remind your manager, project sponsor, customers and other stakeholders that you are going away or leaving. Your manager might have approved your time off, and others might know it's coming, but they might not remember exactly when it is happening.

Give them lots of notice and introduce them to the new person who will be their temporary/permanent contact.

If you are on holiday and it’s that sort of project, let them know how they can contact you during your vacation, if you are prepared to take their calls. But don't make yourself the emergency contact unless you've explicitly agreed that you are going to be available.

Remember: You don't have to take calls or check your emails on holiday. You don't have to be available, even if they ask.

Holiday handover email template to use with clients

Hello [name]
I thought I’d remind you that I’m out of the office from [date] to [date]. I can assure that I’ve handed off the important topics to [colleague] who is available to help you during this time. You can reach him/her on [contact details] if you need to get in touch while I’m away.
If it’s not urgent, feel free to email me and I’ll respond to your message on my return.
Kind regards
[your name]

If you want, you can include a statement about the latest progress, what next steps are, what they can be doing while you are off, or something like that.

Personalize as much as you can, especially if you are out of the office for more than a week.

Giving a last-minute-before-you-leave update is going to reduce the emails you get on your return because they (hopefully) won’t be chasing for routine status reports.

8. Tie up loose ends

Don’t leave your colleagues with admin to finish off. The point of a handover is not to get someone else to do your boring work.

Spend a bit of time sorting out your inbox, delivering on your promises and tidying up your workload so you aren’t leaving (or coming back to) a massive mess.

Write a to do list of things that are essential for when you come back, so you don’t spend your first day back in the office wondering what on earth you were working on before you left.

The 5 things I check before every holiday

1. Calendar – what happens while I'm gone?
2. Commitments – what have I promised people?
3. Dependencies – who is waiting for me?
4. Decisions – what might someone need to decide?
5. Consequences – what happens if nobody does anything?

This last situation has happened more often than you might think!

9. Plan for a handover back when you return

The last thing to do is to schedule time in your diary for your return so that you can pick the project up from the person who was looking after it for you. Don’t assume nothing has happened. You never know what they might have dealt with or done while you were away.

If you are leaving for good, draw confidence from the fact you prepared the best handover documents possible for the incoming employee. By all means stay in contact with your ex-colleagues, but don’t lose sleep over the work you left behind.

Also:

• Turn off your autoresponder email if you haven't set it to auto-expire when you get back
• Update your voicemail to your standard message
• Book time with your team members so you can catch up on their work progress.

Make sure that you talk to your cover person as soon as you can so that you get the context for any of those messages that relate to the project.

10. Go on holiday and don’t look back!

Honestly.

If you are taking a vacation, don’t think about work. You’ll be more refreshed. Things are in good hands. And even if they aren’t, I promise you can sort it all out when you get back. The world will not end.

And if you are staying back while others are off, here are 7 ways to stay motivated and productive at work during the holidays.

If you want to think about work people, do it in the context of buying holiday treats for the team and bring back some local sweets or something. It’s always nice to thank the people that helped you while you were off.

This article first appeared on Rebel's Guide to Project Management and can be read here: Handover checklist: Leave work without worrying + email templates