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.
Last month, I looked at 3 areas where project managers can mentor and support their team members: risk management, task management, and managing multiple projects. Today I’m looking at 3 more areas where I know people struggle – and where project managers are uniquely placed to be able to help them do a better job.
1. Managing scope
Project scope changes regularly – we all know that having a change management process in place is good project management practice. But dealing with constant changes is hard work for the team, even if the right process is followed.
Address this by:
Project scheduling is more than simply putting tasks in a list. It’s about managing dependencies and the resources to do the work. It’s understanding how to crash the schedule when you need to save some time and what risks that presents to your projects.
As a project manager, you’ve got a great set of skills to help others on the team understand how to schedule their own work. If they aren’t confident at scheduling you can coach them through it.
Address this by:
Help them use the right tools. You can’t build out a schedule in Excel, not a proper one. Get them access to the right software and show them how to use it.
Understand the flow of the project and what has to happen in what order. Help them understand the dependencies and the different ways tasks link to each other.
Make sure estimates are accurate so they are scheduling with data that’s actually going to stand up.
3. Budget planning
In my experience, project managers tend to worry about handling the financial aspects of projects, and that isn’t necessary. If you manage your household budget, the principles are pretty similar! It has also been my experience that we are expected to pick it up as we go. I don’t think I’ve ever had any specific, company-relevant training on how to work with Finance and do project budgeting.
However, junior colleagues or those who haven’t had to manage big numbers before might need a confidence boost and some support with this skill. Especially if they are in the same situation of never having been shown how to do this before.
Address this by:
There are lots of ways we can help colleagues and mentor them; these are just 3 areas that I find come up time and time again. What about you? What do you get asked about the most? Let me know in the comments!
These days, project teams are expected to do so many different things, from deep dive root cause analysis to making sure that projects align to strategy. As a team, you’re both in the weeds of the project and also trying to communicate the big picture to stakeholders.
Let’s face it, it can be difficult to have all those skills – I mean, have you seen the latest PMBOK® Guide?! Between that and the Standard for Project Management there are hardly any management and leadership skills that a project manager is not supposed to have.
However, we aren’t able to say, “I’m not very good with PowerPoint so we won’t create slide decks for status reporting.” We have to be all-rounders, even if we aren’t very good in some areas, or don’t enjoy those tasks.
Here are 3 skills for project managers that I know from my mentoring work that people in project roles have difficulty with. I’ve also included some tips for how to improve, if you choose to do so. If you lead a team and find your colleagues struggle in these areas, perhaps the ideas will help them.
1. Risk management
Large programmes may have a dedicated risk manager on the team, but if that isn’t you then you’ll have to get stuck in with risk identification, analysis and management yourself. In my experience, there are several areas that people struggle with:
Address this by:
2. Task Management
This skill is all about managing your To Do list and making sure tasks have owners. It’s also time management overall on the project, so it encompasses resource levelling and capacity planning so you don’t overload people with too many tasks.
People seem to struggle managing their workload and time, and that leads to them feeling overwhelmed and overloaded.
Address this by:
3. Managing multiple projects
These days, most people are managing more than one project. There are still people who lead one large, complex project, but many people are finding themselves running several initiatives at the same time, sometimes with the same resources.
This can lead to each project inching forward at a snail’s pace, lack of understanding about which project should be worked on, feeling overwhelmed as your To Do list encompasses several projects, dealing with conflict between stakeholders, all of whom feel their project is the top priority.
I wrote a book about this exact problem, which came out last month, so check out Managing Multiple Projects from wherever you buy your books if you are struggling with the juggling.
Meanwhile, here are some tips to help.
Address this by:
What other skills do you think are key to project management but are actually pretty hard to do? Let me know in the comments!
Q1 tends to be a time when new budgets are approved and that means we’re starting to see requests for contracts with suppliers trickle through the PMO. It always takes a few weeks for budgets to get released, even if the intention is to start the work in January. By February, project teams are ready to get started, knowing that any further delay in the admin is going to put pressure on their ability to deliver by the dates from the business case. And that’s why all the supplier agreements seem to be floating around at the moment.
The infographic below talks about the major groups/people involved in putting together and approving supplier contracts for new third parties, but it’s the same people involved in renewing deals and reviewing an existing supplier to see if we want to give them more work.
As with any internal process, this is probably a bit specific to certain environments and types of contract, and you might not see all of these roles in your business.
Equally, there might be some other key positions that have a part to play – I know that in one set of contract negotiations for a multi-million software project, my project sponsor attended every conversation, along with the technical architect. And just as well they did too: it created a great sense of common purpose and everyone was on the same page from the beginning.
Take the suggestions below as a starting point for opening up the conversation with your colleagues if you are creating new supplier agreements, so you can make sure the right people are involved from the start.
Your sponsor has asked you to get the work done faster… who hasn’t been in that situation?! That’s one reason why you may want to crash your project schedule, but there are others. In the past, I’ve written about 7 reasons to crash the schedule, and in this video, I pick out my top 5 to discuss in more detail. I talk about schedule compression (obviously), when part of the project has the potential to put the overall project at risk, when you’ve got a fixed deadline, when the team is needed for other work and when there’s a general delay which affects your ability to hit your expected deadlines. Crashing can help in all of those situations, used sensibly. Engage professional judgement before you go for it!
What are your thoughts on crashing? Personally, I try not to do it too often because it’s a lot of effort and it doesn’t always give you the results you were expecting, but it is a useful skill in the toolbox for predictive project managers, so it’s worth knowing when you would consider to use the technique.