I’m sure you’ve sat in meetings where you go round the table and give updates on progress. You could argue that it’s not the most interesting or effective use of everyone’s time, but it is used in many settings. For example, if you have a team of project managers meeting and it is useful to share a couple of points about the work that is going on, as the rest of the team wouldn’t necessarily be aware of it while they are busy on other projects.
However, I also know that many people hate the ‘creeping death’ of going around the room for updates. Below are a few tips from my experience that will help you in your next ‘round table update’ meeting.
If your team meetings or PMO meetings have a section where you go round the table giving updates about progress and what you’ve achieved and so on, then you should know it’s coming. It might be specifically called out on the agenda or just part of your normal meeting practice.
Spend some time before the meeting – just a few minutes – writing down a couple of bullet points so you have something to say when called on. These can be about your projects, successes, blockers or dependencies on other projects that would be worth highlighting to the group.
If you aren’t given a time limit, assume you have hardly any time! Three minutes feels like a very long time to the other people having to listen to you, so I would suggest less than that if you can, especially if you have nothing much to report.
If you are the first to go, you set the unofficial time limit for the group, so it’s even more important to be speedy.
Don’t repeat what another colleague has already said or things that the team already knows or has heard about. For example, if you said a milestone was completed when you all met up last week, you don’t need to say it again. It’s worth keeping track of what you did say for this exact purpose – I often find people repeat status updates that we covered last week and I have to assume they don’t remember telling us about it previously.
It's also common that several people with the project office will be working on the large projects, and the person who goes first may well share the big successes or challenges for that project. You don’t need to say them again; just say, “To build on what X has already said about the Y project,” and share something different. Make a note of a couple of different updates you could give and cross them off your list if anyone else says them first!
Focus on specific things. Talk about what issues you are having or successes the team achieved. Share where you need help or what you know they are most interested in. Focus on things that overlap with other projects, for example, where you share resources, as these are the information points that will help others in the team manage their own work more successfully.
Risks get logged on our spreadsheets or in our tools, but it’s often the identification part that people find difficult.
Below are 5 causes of risk. You can use these as a jumping off point for your own risk identification. What would happen on your project if one of these causes created a situation for you?
1. Equipment failure
On projects in the past, we’ve had the local council cut through power lines while doing work digging up the road outside one of our locations.
We’ve had internet outages. We’ve had component failure. And once one of my colleagues had their laptop stolen from out of the back of their car – not exactly a failure, but it caused the same kind of situation. If you’ve ever lost a piece of tech you’ll know the headache that comes with getting a new one and all the governance paperwork to fill in too.
What risks could you have on your project around equipment failure?
2. Planning errors
Incorrect estimates, incorrect assumptions… these all lead to the potential for your plans to be wrong.
Even missing out someone’s annual leave or scheduling over a bank holiday because you didn’t have it on your calendar can cause a delay.
You might have risks related to the accuracy of your planning and scheduling.
3. People problems
A lot of project risks are created by people! For example, in one situation I heard of, a project team hired the wrong person for the job. The candidate said they could do the work, it sounded like they could do the work and when they showed up, they couldn’t.
Other risks could be the risk of someone not turning up (as has just happened in our house with contractors due to fit the new floor), refusing to do the work, changing their daily rate or is otherwise demonstrating difficult behaviour.
Even if you can resolve the problem, sorting out challenges like this takes time and energy, and often we don’t have much of that on projects.
What people-related risks can you foresee on your project, and what can you do about them?
4. Watermelon projects
Another risk is that people don’t report the true status to you so you end up with a watermelon project: green on the outside and red in the middle.
You can deal with that risk by making sure you have processes for adequate reporting and are able to understand the current situation. If you don’t have visibility, you can’t control the project.
Could one or more strands of your project be at risk of going watermelon?
Finally – and this can happen on any project – miscommunication. Team members do things wrong because they don’t understand or they haven’t had complete instructions.
In theory, this one should be easy enough to resolve, so much so that you might not even think it is worth putting on the risk register at all. However, if you work with a cross-cultural team, different time zones or remote teams then it is probably a higher risk factor for you.
Would your project be at risk of communication challenges?
Let’s not kid ourselves: optimism bias creeps into most things we do. I’m certainly guilty of it: “Yes, of course I can finish that slide deck for the board today, even though I’ve done nothing on it yet.”
Project teams at all levels of experience and in all sectors tend to approach their work optimistically; it’s human nature. In UK government projects, they even have a process for addressing optimism bias. Estimates are expected to explicitly adjust for bias when stating the costs and benefits. I think this is fantastic. It forces people to think about what is realistic and what bias they might be bringing to the table. It helps highlight risk too.
The published Guide to Developing the Project Business Case also talks about adjusting the adjustments down again when there is some performance-based evidence to show that the project is progressing to plan. So we don’t have to worry about padding the estimates forever – they can be readjusted as and when you have more specific, data-driven information to include in the forecasts.
The guidance even includes what percentage increase to use on your estimates to counteract the effects of bias. Of course, you can choose to use whatever you feel is the best adjusted value, but the numbers given for time and cost are based on a study by Mott MacDonald and are a good starting point if you don’t have internal data to draw from.
(As an aside, if you don’t have internal data to draw from, what are you doing to start building up that repository of information? Given the amount of data we capture in our project management tools these days, and the prevalence of AI tools to help us interpret and interrogate it, we really should be setting ourselves up to rely on our own data sources instead of industry-aggregated ones. But in the absence of your data source being substantive enough on its own at this time, do tap into published data sources as a starting point.)
For example, the suggestion is that for a software development project, you should add 54% on to the schedule! I’m not sure my stakeholders would agree with that as it seems an awful lot of padding. However, past experience tells me that this is probably not far from the mark realistically. 54% is the top bracket – you could opt to add the lower bracket of 10% or anywhere in between.
It also suggests adding between 10 and 200% to the project budget to bring you more in line with something you can realistically achieve. Again, I’m not sure my sponsor would go for doubling my budget ‘just because’ but I think these numbers open up the conversation to allow us to talk about risk and the validity of estimates.
The guidance suggests that you start with the upper limit and then work back from that based on whether you feel the optimism bias can be or has been reduced. For example, have risks been managed, have estimates been fully throught through in a robust way and benchmarked across industry actual results and so on.
If you do take this approach, make sure that everything is documented and you can explain your rationale for adding an adjusted figure – including why you haven’t been able to mitigate against optimism bias (yet). Stay transparent and keep talking about what it means for the project.
What do you think of this approach? Let us know in the comments!
1. Get involved with business cases and proposals
First, lobby to get involved with business cases and proposals. The more delivery expertise we have involved in the initial stages of a project, the more likely it is that the project will be able to actually hit its goals.
Have you ever been involved with a project where you’ve been handed something to do and the sales people have made promises that you can’t deliver on? Then you’ll know what I mean!
When project people are involved in business cases, in my experience you’re more likely to end up with a timescale that’s achievable and a resource plan that reflects the real amount of resources likely to be consumed by the work.
It’s even better if you can lobby for a seat at the table when the 3-year plans are being drawn up, so your top level project people, like the Head of PMO, get involved in creating the strategy in the first place. That provides a real insight into what initiatives are coming and how the delivery teams can help.
2. Use the project assurance function as a check mechanism
Project assurance is a way of checking that what you think you can do is actually achievable. It’s their job to pick apart your plans and proposals and apply a sense of real-world pragmatism. They can also help identify whether there are any resource gaps, strategic holes or other issues that you haven’t seen.
After all, as a project manager I’m sometimes so close to the information that I can’t see the bigger picture enough to realise that this project will clash with something that someone else is working on – but project assurance has the bigger picture and can point that out.
If you don’t have a project assurance function, ask a colleague for their opinion and talk them through the plans, asking them to basically pull them apart. Ideally, to be able to add some strategic oversight to your plans, this should happen around the time of the business case or PID. By the time you’ve got to creating a schedule you’ll be looking for a different kind of peer review.
3. Share what you know – but only what you know
My third tip is something I learned from Tony Meggs, Chief Executive of the Infrastructure and Projects Authority in quite an old article now that he wrote for Project magazine, but it has stuck with me. He said: Only announce what you know.
We know this in theory, so it’s not news to you, I’m sure. However, many project managers are ‘encouraged’ to share dates before we are ready, or pushed into committing to dates publicly before we have all the information to support the fact we can deliver to them.
So, if you want to be a strategic operator, only share what you know to be achievable. That goes for delivery methodologies as well. Meggs talked in the article about not committing to anything unless you know it to be true, including how the work would be delivered. If you are going to partner with someone and there’s a robust contract in place, by all means announce it. But don’t announce your intentions before they are fixed in stone because if it doesn’t happen you’re then having to walk back on the messaging and that can be damaging.
We can do this as project managers on a small scale, by giving our teams the space to come up with the best methods and timescales before we announce them to sponsors, but also on a strategic level, by ensuring there is a communications plan in place that supports the bigger picture messaging for the project, programme or even the portfolio.
Do you do any of these already? How are they working out for you? Let us know in the comments!
Here are 5 ways to see the bigger picture in your work in order to make a bigger impact with what you do.
There is more about each of these in the infographic below.