What a project manager is really there to do
Strip the job back and it comes down to one question: how do we deliver what's been agreed, with the money and people we've been given, by the date we promised? That's what separates it from product management, which is about working out what to build and for whom. A project manager is handed an outcome, a budget and a deadline, and owns everything that happens between kick-off and closure.
The setting changes from one sector to the next (IT, construction, engineering, events, consultancy, the public sector), but the shape of the work is familiar: breaking the job into workstreams and milestones, building a plan that will survive contact with reality, keeping a RAID log of risks, assumptions, issues and dependencies, preparing for the steering group, managing suppliers, running user acceptance testing, planning the cutover and closing the project with a proper lessons learned session.
Around all of that are people. A sponsor who wants straight answers. Team members on loan from other departments, each with a line manager pulling the other way. Suppliers who need holding to account without being alienated. End users who often see the result later than they should. That's where you see the difference between someone who tracks a project and someone who actually runs it.
Good versus great: where the gap shows
A good project manager keeps the plan up to date, runs tidy meetings and sends a clear weekly status report. A great one does all of that too, but you really notice them when the plan stops working. Here's what the people around them tend to pick up on:
- Bad news travels early. A supplier slip goes to the sponsor the day it becomes likely, with two costed options, not the night before the steering group.
- Scope is protected without being frozen. New requests are welcomed, then turned into a clear impact on time and cost, so the decision lands with the person who should make it.
- The risk log is a working document. It changes every week, each risk has an owner, and there's a fallback ready before it's needed.
- Decisions get written down. A short note of who agreed what, sent the same afternoon, saves the team from reopening settled questions a month later.
- The steering group makes decisions. The agenda puts specific questions to the sponsor instead of reading out a status update everyone has already seen.
- The team is shielded. Last-minute asks go through the project manager rather than straight to whoever on the team happens to look least busy.
The skills that never appear on a Gantt chart
A lot of what makes a project manager excellent leaves no trace in the deliverables. Yet it's exactly what colleagues mention when you ask them why a project went well.
First, spotting the early signs. A team that's stopped asking questions, a supplier whose replies are getting slower, a business area that keeps missing test sessions. Great PMs pick these up before they turn into delays, and they walk over and talk to people rather than waiting for the next status meeting.
Second, influence without authority. In most organisations, the people on a project don't report to the person running it. Getting time, decisions and commitment out of line managers who have their own targets, and going back for more without wearing out the goodwill, is a skill in its own right.
Third, a firm grip on the money over months, not just at the end: knowing what's been committed as well as spent, telling a one-off overrun from a trend, and raising it before finance does. And fourth, the one that's rarest: closing well. Documenting, handing over properly to the people who'll run what's been built, thanking those who helped, and drawing real lessons instead of rushing to the next project.
Mistakes even capable project managers make
These rarely come from a lack of method. They come from deadline pressure and a genuine wish to keep everyone happy, which is why they're so hard to see from the inside.
- The watermelon project: green on the outside, red in the middle. The RAG status stays green until the day the delay can't be hidden any longer.
- Saying yes to every request to keep relationships smooth, without spelling out the effect on the deadline, then finding the scope creep at testing.
- Mistaking activity for progress: lots of meetings and minutes, very few milestones actually passed.
- Carrying everything alone to protect the team, until every decision has to go through one overloaded person.
- Rushing the close: no lessons learned, no handover to the team that'll support the result, and the same problems turning up on the next project.
- Presenting a plan you already suspect is unachievable at kick-off, so as not to disappoint, and hoping to claw the time back later.
What hiring managers look for
Someone hiring a project manager will first look at the scale of what you've delivered: the size of the team, how many suppliers, the budget you were responsible for, how long it ran and how much it mattered to the organisation. Then they'll want evidence a CV can't give them: what happened when things went wrong, how you handled your stakeholders, and whether your sponsor would hire you again.
A project management qualification tells them you know a method, which helps, particularly in larger organisations and the public sector. It says nothing about how you handle a tense steering group or break the news of a slip. Only the people you've worked with can speak to that, and a sponsor or client carries more weight with a hiring manager than a peer.
That's where a Take Your Skills profile earns its place. Your references sit together under your name, each showing the job title and organisation of the person who wrote it, and you can share them through a link on your CV or as a PDF attached to your application. If you're further along, our guide to what employers ask your referees covers the reference check itself.
Getting references that show the right things
The best time to ask is at the end of a project: just after go-live, or at the closure meeting, while everyone still remembers the hard weeks and how you got through them. Ask two years later and you'll get something much vaguer.
Aim for a spread of viewpoints. The same project looks different depending on where you sat, and that variety is what makes references convincing. Think about asking:
- your sponsor, for clear decisions and commitments that held;
- the client or the business area receiving the change, for a smooth go-live and how well you listened during testing;
- someone from the project team, for how you organised the work and kept it protected;
- a supplier or contractor, if the relationship allows, for being firm but fair;
- anyone you've coached into running projects themselves.
Helping people write something specific
Most people remember that a project went well but struggle to say why. On Take Your Skills, the “Ask for a recommendation” button on your profile gives you a link to send by email or message. In your note, remind them of one or two moments: the week the main supplier slipped, the steering group where scope had to be cut, the cutover weekend.
Once they've signed in with a code sent to their email, they can use an assistant that asks one question at a time about real situations they shared with you, then suggests a draft they can edit before it's published. Their answers are never published, and they can always write it themselves. Want to recommend a project manager who isn't on Take Your Skills yet? Their email address is enough: they'll get an invitation to claim their profile, with your reference already waiting.
As your public recommendations build up, your professional portrait, written by AI from what they say, draws out the skills mentioned most often. For a project manager, seeing several people independently mention foresight, reliability or a calm head in a crisis says more than a list of methodologies on a CV. For the wording of the request itself, see our guide on how to ask for a reference.
Project manager reference examples
These eight examples are written from different seats around a project. Fill in the brackets and, above all, add one detail only you would know. That's what makes a reference believable.
- From a sponsor: I asked [Name] to deliver [project] against a deadline most people thought was unrealistic. What stood out was that I never had a nasty surprise at steering group. When our supplier warned of a delay, [Name] was in my office that afternoon with two costed options and a clear recommendation. I made the call in one meeting rather than three.
- From a team member: Throughout [project], [Name] was the person every last-minute request had to get past. New ideas came back with their impact on the plan spelt out, which meant the rest of us could get on with the work. We always knew on a Monday what mattered that week.
- From a client: We worked with [Name] on rolling out [project] across all our sites. Their status notes fitted on one page, with every decision, owner and date written down. During testing, [Name] took the time to listen to our frontline teams, and go-live happened without any disruption to the business.
- From a supplier: Working for [Name] isn't always comfortable, and I mean that as a compliment. Commitments are precise and slips get picked up straight away, but [Name] never goes looking for someone to blame. When we hit a genuine technical problem on [project], they argued for a fair solution at their steering group instead of leaving us to deal with it alone.
- From a line manager: [Name] took over [project] after it had already gone off track. Within three weeks the scope had been reset with the sponsor, the risk log rebuilt and a realistic plan signed off. It was delivered within the revised budget and, just as importantly, the board's confidence was back.
- From a finance director: On [project], [Name] always knew exactly where committed spend stood. I never found an overrun at quarter end: [Name] flagged each trend as soon as it appeared, with the reasons and the options to bring it back in line.
- From someone they mentored: I learnt to run projects by shadowing [Name] on [project]. What stuck with me most was how they prepared for steering group: never a status update for the sake of it, always two or three decisions to secure, talked through with each member beforehand. I still do it exactly that way.
- From an end user: We were dreading the new system. [Name] ran demos before testing started, collected our comments and told us honestly which ones would make it in and why. On go-live day they were on the floor with us. Nobody felt forgotten.
Which personality profiles thrive in this role?
No personality type is born to manage projects. Every profile can excel at this job in its own way. The Peacemaker, for instance, isn't the first person you'd picture chairing a steering group. Yet the knack of taking the heat out of a tense meeting without raising a voice, and noticing quickly when someone on the team is struggling, protects a project from a risk no dashboard shows: the people carrying it burning out.
Still, some of the dispositions described in our personality test for work line up closely with what the job asks of you week in, week out:
- The Organiser makes it clear who's doing what by when, then sees every commitment through. That's close to a definition of a decision log followed up to the last action.
- The Builder keeps every promise and hits every deadline. On a long project, that steadiness means the sponsor and the team know what they can count on when the timeline gets tight.
- The Pilot sets a clear course and makes the calls that get the team there. Invaluable when scope, budget and deadline have to be traded off and nobody else wants to decide.