I was inspired to do the Generative AI for Project Managers course (which is currently free, and definitely worth looking at on the PMI website) and from there, to sign up for a ChatGPT account. In parallel to that, I was asked to deliver a webinar on AI-proofing your career (spoiler alert: AI takes away the parts of the job that I didn’t like so much anyway, and frees up more time for you to shine in human relationships), so I seem to have embedded myself in the world of AI recently!
I thought I would put ChatGPT to the test by asking it a question I get asked frequently:
What are the top 5 challenges affecting project managers in the world today?
This is an edited version of what it said. It gave me 246 words, and I’ve added my own thoughts after each point to add a human-in-loop spin on the feedback. The GenAI course explains human-in-loop if you have not come across this term before.
(Sidenote: I feel weird calling it ‘it’ when you can have a conversation with it. I think I would like to give my ChatGPT bot a name, I just don’t know what!)
As of my last knowledge update in September 2021, the following were some of the top challenges affecting project managers worldwide:
Elizabeth says: So far so good. This seems to be a perennial problem across the ages. It’s not particularly new, but I’m sure it is true. Every project manager I speak to seems to have issues with resourcing and capacity planning.
Elizabeth says: Again, this is not new news. It’s not the modern, fresh take I was hoping for. Perhaps there isn’t one: we’re stuck with the challenge we’ve always had, which is reassuring and disappointing at the same time!
Elizabeth says: I’m sensing a theme here. These are all true, but as project managers, we’ve been overcoming the challenge of remote and distributed teams for years, even before the pandemic.
Elizabeth says: I agree that risk management and working in uncertainty is a challenge, but we have whole project approaches designed to minimise the impact of that and maximise user engagement through short deliverable sprints. Yes, the world is an uncertain place, but again, project managers have been looking out for the things that will bite us in the backside for years. That’s the job!
Elizabeth says: I would not have put stakeholder management as one of the challenges for project managers. In fact, it’s one of the fun parts! I do understand that it is challenging to manage competing priorities, but again, our processes are set up to identify those and work through them.
Then ChatGPT goes on to add:
Please note that the landscape of project management may have evolved since my last knowledge update. Factors like emerging technologies, evolving business models, and global events (such as the ongoing COVID-19 pandemic) can introduce new challenges or shift the emphasis on existing ones. It's recommended to stay updated with current industry reports, trends, and insights to understand the most pressing challenges faced by project managers in 2023.
Elizabeth says: I agree that it is important to stay up to date with the pressing challenges, and the best way to do that is to stay connected to the industry. Conferences like the PMI Summit and publications like project management magazines provide timely insights into what is important. For example, sustainability isn’t on the ChatGPT list and I would have thought that would have been a concern back in 2021.
I haven’t yet paid for an upgraded account, so perhaps a paid account would have better outcomes and give me a different take on what the current challenges are, so there’s that to consider.
Meanwhile, I’m curious! Do you agree with these challenges? Do you think there are others more pressing for us as project managers? And what do you think of the output of ChatGPT if you’ve used it? Let me know in the comments below!
I have an electronic copy of the PMBOK® 7th edition, so from time to time I open it up to check on something. Recently, I’ve been looking at different ways to forecast as we’ve got some work on that needs to be planned out.
There are 6 quantitative forecasting options called out in the Guide. These are as follows.
Estimate to complete (ETC)
This is top of the list and the one I personally use the most often. It works even if you are not in a full, compliant, earned value management environment. The risk here is that we assume past performance is indicative of future performance, and honestly, why wouldn’t you? Unless you know something is definitely going to change measurable performance, you would assume that work is going to continue at broadly the same rate. Just jot that down as an assumption so it’s transparent to everyone.
Estimate at completion (EAC)
For me, this goes hand in hand with ETC. It’s calculated by taking the actuals and adding the ETC, so again, while it comes under the umbrella of earned value acronyms, it’s completely accessible to those who don’t work in EV setting.
Variance at completion (VAC)
As forecasting tools go, this gives interesting data. It’s the measure that shows the amount of forecasted budget over or under at the end of the project, and it’s one most project sponsors will be interested in: “Will we have any cash left to do anything else when we’re finished?”
To-complete performance index (TCPI)
I have never had the opportunity (or reason) to use this forecasting metric. Perfect for those of you working with earned value day in, day out, it’s the cost performance required to meet whatever management target you’ve set for the work. It’s a ratio, so I think it is less meaningful to execs who are used to see tangible numbers of days or money.
Now more and more tools are introducing AI features, it is possible to access regression analysis more easily. Perhaps you’ve got access to an AI-powered tool that will crunch these numbers for your automatically, removing the need for statistical knowledge.
The output allows you to predict performance going forward based on what has happened in the past, so it’s arguably more grounded than other guesstimates!
The final forecasting technique mentioned is throughput analysis. This looks at the number of items completed in a fixed time, so it’s useful for teams measuring features completed, velocity and story points. You can compare the output to those of other teams, although I’d be wary about comparing teams unless they work on very similar products or services. It wouldn’t be fair to judge a team on their throughput when dealing with very complex features against the performance of a team that has higher throughput but lower complexity.
However, the team can compare its performance against itself: that would be a worthwhile exercise. Ideally, you’d want to see that the learnings from retros have been fully incorporated and, more importantly, that the changes have actually made a difference.
Which of these are most used for your project forecasting? Let us know in the comments below!
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.
Have you got too much on your To Do list? What about the backlog – is everything in the ‘must do’ category? What about your project prioritisation process? How many projects are top priority, even when you’ve applied what should be reasonable and weighted criteria designed do rank projects based on importance?
Yes, I’ve been there. Everything is important and stakeholders want it all tomorrow.
We all know that isn’t possible, and in most cases, isn’t even desirable. Some of those ‘tomorrow’ dates will be totally arbitrary, and based on the shadow of a promise instead of fact-based, schedule-driven expectations.
But when a senior person asks you to do something, or your trying to guide the team through a prioritisation exercise, how can you manage all the things to do? Here are 3 tips for reframing your workload and helping stakeholders see what’s possible based on capacity and priority.
1. Go back to the ‘why’
What’s the benefit of doing the task, project or of delivering that feature? What’s the rationale behind it and the user impact? Think about how you can measure the success of the deliverable and what return it will provide. That doesn’t have to be a financial return, it could be a social impact return, customer satisfaction improvements or something else.
Understanding the reason for doing the task and what comes out the end of it will give you greater insight into priority. The project that has the largest return is normally worth doing over the project that has a small return. The automation task that you’ve been putting off setting up is going to free up resource time longer term, and that’s worth more to you than something tactical.
2. Yes, but…
When stakeholders are pushing for their tasks to be at the top of the list, ask for their help in prioritising. Say you can do the work, but at the expense of something else. What stops, or gets delivered later?
“Yes, I can take that on, but it means postponing delivering XYZ that you also asked for, until next week. Are you OK with that?”
“Yes, we can do that, but we’ve got a lot of other changes to work on first, so we won’t get to it until next month.”
The onus is on them to support the prioritisation effort, and it helps make them aware of the impact of juggling priorities – especially when their request impacts another stakeholder’s expectations.
3. Draw the line
One of the techniques we used in my old job was to maintain a list of changes and projects in priority order. We had a prioritisation model that everything was fed into, and the output was a ranked list of work.
Then we applied estimates to the work and reviewed the capacity of the team. That told us how much work we could take on as a department and what was next in line for when there was availability to pick up something else.
It was a spreadsheet, and it literally had a line under the work we could do. Everything under the line didn’t get worked on.
If someone expects their work to take priority, it needs to go through the prioritisation route. Sharing the list (and the line) with stakeholders helps them visualise why you can’t simply do it – even if it’s a small thing.
“Yes, that’s fine, it will take longer than normal to work its way through testing because of the volume of work the team has on at the moment. Oh, you need it sooner? Let me share the higher priority items with you if this takes precedence, so you can see what other stakeholder commitments we’d need to drop to do this more quickly. Perhaps you could talk to those stakeholders to agree the overall priorities? I’ll put a call in.”
What else do you do to help protect your time and prioritise your work? Let me know in the comments!
Metrics are an important way to learn about how the project is going and to reflect on what has happened in the past so you can do things different in the future. Or repeat the things that work well.
I learned a few lessons about project metrics when I worked on an ERP implementation a while ago now. We measured internal customer satisfaction from the angle of the stakeholders’ experience of being on the project. We used standard questions and asked them to rank our performance on a scale of 1 to 10. (I write about all of this in Customer-Centric Project Management, which I co-wrote with a colleague.)
In my experience, workstream leads scored reasonably based on the context: no one ‘played politics’ to get what they wanted. But there was always room for improvement based on our scores. We had plenty of armchair debates in the lobbies of hotels while working on the road, talking over the scores and why they were ranking project performance the way they did. They weren’t my favourite conversations, but they were extremely useful in building great stakeholder relationships and goodwill over time.
The big lesson for me came when I was asking my own colleagues in the IT department to rank the project and they scored it badly. I took it personally as the project lead as you can imagine! But it was a huge wake up call for not taking my colleagues and friends for granted: I was pouring all my stakeholder engagement effort into people outside of my own team.
Luckily it was easy to fix. I set up conference calls for team Q&A and made time for regular communications. If you listen to what people want and give it to them, you can make a quick difference to perceptions and how easy it is for them to do their jobs.
The takeaways for me, specifically around metrics were these.
Identify stakeholders in the process
Put some time into identifying stakeholders and don’t miss the obvious ones like I did!
Ensure the measures are representative of all stakeholders
If your measures are not objective and are not representative of all stakeholder, consider having different versions of the measures for different things. That’s OK as long as there is some longevity baked in for comparison purposes.
Decide on how to record results
In my case, it was better to keep individual stakeholder results separate instead of creating an aggregate of stakeholder satisfaction scores. That gave us greater insights into how each workstream was feeling. An average would be unrepresentative of the community overall.
Are the metrics telling you what your instincts are telling you? If not, why?
As project leaders, it’s important that we set up metrics to measure what matters (I’m sure you’ve heard that before). We need to know who matters and their experience influences the overall metrics on something like satisfaction or the interpretation of project value.