If I could somehow send a fax to a younger version of myself, there are a few things I would tell him about project teams.
Yes, a fax. It would probably be more appropriate for the time.
When we talk about projects, we can speak about higher purposes. Delivering business value. Putting organisational strategy into life. Transforming the IT landscape. Building competitive advantage.
All important. But none of this happens without people.
Somewhere underneath our strategies, roadmaps, milestones and steering decks, there are people doing the actual work. Designing. Building. Testing. Solving problems. Making decisions. Sometimes arguing. Sometimes helping each other. And eventually transforming our project vision into something real.
For me, the team is the basic unit of project delivery.
And there is something interesting about a project team. It is temporary by nature. One day it does not exist. Then a group of people comes together around one purpose. Hopefully, at some point, they become a team. They deliver. And then the team disappears again.
Once upon a time there was a Team.
Names in a resource plan
At the beginning of a project, as the scope and delivery approach start taking shape, one of the early jobs for a PM is securing the resources needed to get the project moving.
We identify what we need. An architect. Business SME. Infrastructure specialist. Developer. Tester. Operations. Whatever the project requires.
Names appear in the resource plan. Capacity gets agreed. Maybe everything is carefully captured in the project documentation.
Looks good. But having resources allocated on paper does not mean you have a team. There may still be quite a long way to go.
There are rare projects where the PM has full influence over team selection. Usually we work with the specialists available in the organisation at that particular moment, taking into account other projects, priorities and BAU activities. And there is nothing wrong with that.
If you have worked in the same organisation for some time, you will probably know specialists or SMEs who would be a particularly good match for your project. Negotiate for them. Talk with the line or resource manager. For some crucial resources, it may even be worth taking the discussion to Project Board level.
A couple of experienced people in the right places can make a huge difference. They may not decide project success on their own, but they can certainly make the journey more productive and less risky.
Still, we rarely get to build our dream team. And perhaps that is not even necessary.
A team built entirely from superstar SMEs is not automatically the best team. A combination of people who have been around the organisation for years and people who have just joined can work extremely well. Experience combined with fresh eyes and new energy.
The PM needs to work with what is realistically available and build from there.
And people will change during the project too. Someone leaves. Somebody else joins. On paper, replacing 1 FTE with another 1 FTE may restore the capacity.
In reality, it doesn’t immediately replace months of project memory, relationships and context.
People are not interchangeable cells in a resource plan.
From resource plan to team
One of the classic models tells us about forming, storming, norming and performing. We know it. Experiencing it in a real project is another thing.
You may have ten names in your resource plan and still have ten individuals rather than one team.
For me, one of the best ways to start changing that is a proper project discovery workshop. Of course, there is an official agenda. How do we translate the project goal, vision and targets into actual products? What needs to be done? What are the dependencies? What are the risks?
But I usually have another agenda as well.
Team forming.
We break the ice. We learn who is who, how people communicate, where they come from and what experience they bring.
During an introductory roundtable, apart from the usual name, organisational area and role, I like to add one more question:
“What is your role in this particular project? What do you bring to the table?”
There is a little more behind it. I am not only asking people to introduce themselves. I am asking them to say, in their own words, how they are going to contribute. In a way, it is a small commitment made in front of the rest of the team.
Slowly, “the project” starts becoming “our project.”
We are no longer looking at ten names from different organisational boxes. We start seeing how those people fit together, what each of us brings and how we are going to deliver this together.
Because a group of experts is not automatically a team. You can have a brilliant architect, developer, infrastructure specialist, business SME and tester and still have a project team that does not work particularly well.
Technical competence matters. But so does the space in which those people are expected to work together.
And people don’t necessarily come to the project from equally mature and well-established teams. One resource may come from a team that has worked together for years. Roles are clear and everybody knows how things work. Another may come from a newly created team still finding its feet. Somewhere else, there may already be internal tensions or conflicts.
You could say:
“That’s not my business. That’s the line manager’s job.”
And to some extent, that is correct. We should not become the line manager of people who don’t report to us or start fixing every organisational problem around the project.
But for the lifetime of the project, those people are also part of our team. If something in their formal organisation starts affecting their ability to deliver, sooner or later it becomes our business too.
If a newly created team needs some help getting established and I know how our organisation works, why wouldn’t I help? If a conflict starts affecting project work, perhaps I can facilitate a conversation and help people find a way forward.
Not because I want to take over somebody else’s management responsibility. Because it affects the project and the people trying to deliver it.
I think PMs operate in quite a lot of this grey land.
Not everything that affects a project fits nicely into one box of responsibility. Sometimes an issue sits somewhere between teams, managers, functions or workstreams and nobody clearly owns it.
If it is going to affect the project, sometimes the PM simply needs to pick it up. Maybe only temporarily. Maybe only to connect the right people or make sure somebody eventually owns it.
Leaving it there because formally it belongs somewhere else doesn’t make the impact on your project disappear.
Make your project a good place to work
One of the realities of a matrix organisation is that allocated does not always mean available.
Someone can be allocated to your project at 50%. Excellent. Except that their line manager needs them. BAU needs them. Another project needs them. And probably another PM has exactly the same 50% written in another resource plan.
The most experienced people are often the most stretched people.
So how do we make sure they actually spend time on our project?
Some things are outside the PM’s control. Organisational priority matters. Line-management decisions matter. Senior-management direction matters.
But I think we sometimes underestimate another factor.
Make your project a good place to work.
Create a well-organised project space. Have a clear plan. Make roles and responsibilities understandable. Set reasonable communication rules. Run useful meetings. Keep workflows clean. Make decisions visible. Give people clarity about what they own.
Don’t waste their time.
Among organisational chaos, a well-structured project can give people some certainty. And I think that can attract people.
Who doesn’t want to be part of a well-organised endeavour?
We don’t have formal line authority over most of our project team. We have the PM mandate to run the project, but those people usually report somewhere else. That makes relationships, credibility and the environment we create even more important.
Meet Mr. Wolf
If you run projects and programmes for long enough, you get the opportunity to work with a whole spectrum of personalities. Every person from every project I have had the privilege to run was different.
But after some time, you start recognising certain types. I have my own names for some of them.
One of my favourites is Mr. Wolf.
Those who have seen Pulp Fiction will probably remember the situation. Jules and Vincent have a serious problem. A very serious one. There is a dead body in the car and they need help.
Then comes the message that Winston Wolf is on his way. Jules knows exactly what this means.
Relief.
The guy who knows how to handle the situation is coming.
I sometimes have a similar feeling when I see a particular name appearing in my project resource plan.
Mr. Wolf is joining the project.
Good. We have somebody who knows this stuff.
Your project Mr. Wolf is usually a top SME in one of the crucial areas. He knows his subject. He knows what needs to be done. And if he doesn’t know something himself, he usually knows who to call.
If you are lucky enough to have such a person assigned to your project, identify them quickly. Build a good working relationship. Listen. And use that expertise.
Please don’t act like Vincent.
If your Mr. Wolf gives you good advice, there is little value in wasting three weeks before eventually discovering that he was right.
And particularly at the beginning of the project, don’t waste his time.
Mr. Wolf normally has plenty of other things to do. BAU problems, other projects, operational urgencies. He wants to understand the problem, do the job properly, keep professional standards and move on to the next place where his superpowers are needed.
But there is an important distinction here.
You are not passing the project steering wheel to Mr. Wolf.
He owns his expertise. You still own the project.
That combination can work extremely well. Mr. Wolf stays focused on what he is really good at. The overall responsibility stays with the PM.
The PM does not need to be the smartest technical person in the room. Quite the opposite. I am very comfortable having people around me who know far more than I do about their specialist areas.
My job is different.
Not everyone is Mr. Wolf
Of course, not everybody joining the project will give you that Jules smile. And that’s fine.
There is another character I have met more than once. In a way, he can even be Mr. Wolf’s difficult brother.
A very experienced specialist. Knows the organisation. Knows the technology. Knows the history. And quite possibly wanted to run your project himself.
Maybe he thinks management selected the wrong person. Maybe he thinks he knows how the project should be run better than you do. And perhaps, in some areas, he really does.
This person could become one of your strongest supporters. But sometimes, at least initially, he won’t.
I wouldn’t automatically label such a person as difficult. There is usually something behind it.
Perhaps they were not recognised. Perhaps they expected a development opportunity that never came. Perhaps their management changed several times. Perhaps they have been permanently sitting in the number two position waiting for somebody to give them a chance.
That doesn’t mean we should give away the PM mandate. But understanding what sits behind the behaviour may help us turn resistance into cooperation.
And sometimes there is another person sitting quietly in the same meeting.
The shy star.
Maybe the camera is off. Maybe they don’t speak unless somebody asks them directly. Maybe somebody louder gets noticed first.
But then you start seeing the work. Good analysis. Good questions. Reliable delivery. Knowledge you didn’t expect.
And suddenly you realise:
We have something here.
I have been genuinely impressed watching some of these people grow during the lifetime of a project.
Give them space. Ask what they think. Give them something to own. And recognise what they deliver.
Because if their own organisation doesn’t notice them, another organisation eventually may.
These are only a few examples. Some people need detailed direction. Others need only the destination. Some will ring the bell as soon as they see a problem. Others will fight with it themselves until the last possible moment. Some need encouragement to speak. Others need a little encouragement to listen.
You don’t manage a project team by applying exactly the same management style to every person in it.
Humans are humans. Not machines.
Instant full productivity can go onto the shelf with some of the other corporate stories we like to tell ourselves.
Protector and enabler
For me, one of the most important PM roles towards the team is being its protector and enabler.
Protector does not mean hiding reality from people. It does not mean protecting them from accountability. And it definitely does not mean blocking communication from the Project Board or senior management.
It means protecting their ability to deliver.
There is usually plenty of noise around a project. Stakeholder pressure. Changing priorities. Escalations. Organisational politics. Last-minute requests. Another urgent meeting. Another person who suddenly needs a status update.
Some of that absolutely needs to reach the team. Some doesn’t.
I don’t believe that passing every piece of pressure and every bit of management tension directly downwards is transparency. Sometimes it is just transferring stress.
Particularly during fragile moments, before an important milestone or Go-Live, unnecessary noise can block the very people we need to perform at their best.
The PM stands somewhere between organisational complexity and the people doing the project work.
In that sense, I see the PM as a kind of ambassador between the Project Board and the project team.
Bring direction, decisions and the right level of context downwards. Bring reality, risks and the team’s needs upwards.
Absorb some of the noise. Translate it. Get decisions made. Remove blockers. Connect people. Clarify priorities. Manage dependencies.
And sometimes pick up something from the grey land between organisational boxes because nobody else has picked it up yet.
A PM should not become another layer of complexity around the team.
We should reduce complexity for the team.
Create space for professionals to deliver professional products.
This is especially important with your Mr. Wolf. Good specialists can quickly lose motivation when they see that the PM does not care, does not listen or allows the project environment to become unnecessarily chaotic. Their time is precious too.
The project manager does not deliver instead of the team.
The project manager makes it easier for the team to deliver.
Your project is not the only project
Then comes one of my favourite resource-management situations.
Two projects. Overlapping timelines. The same crucial resource. Both formally allocated. Both with similar priority.
Perfect.
Which project gets the person? The one whose PM can escalate higher?
I don’t think so.
This is where we need to get outside our own project bubble.
Put both schedules on the table. Look at the milestones and dependencies. What happens if the resource moves from one activity to another? Can one schedule absorb the conflict? Can something be moved? What is the actual impact on each project?
If a management decision is required, both PMs should be able to prepare that decision together, based on facts and impact rather than on who can shout louder.
And if my schedule can absorb the change, why shouldn’t I help the other project?
Today I am helping you. Tomorrow somebody may help me.
We are not employed to win a competition between Project A and Project B.
The organisation needs to win.
The team has a life outside your project
There is another thing I would put into that fax to my younger self.
The fact that people work for the same company, use the same collaboration tools and appear in the same Teams meeting does not mean they work in the same environment. Especially in global organisations.
People may be working in different time zones. Their normal working day may overlap only partly with the project. Your comfortable 3 PM meeting may already be somebody else’s evening.
There are cultural differences, but there are also simply differences in daily life. And then there is everything outside work.
We cannot know everything. We cannot fix everything. And we should not pretend that we can.
But we can be aware.
If somebody who has been delivering reliably suddenly drops in productivity, perhaps the first question shouldn’t always be:
“Why is this task late?”
Sometimes it is worth asking if everything is OK.
We are working with people.
Stop and recognise
This is another message I would definitely send to my younger self.
Recognise people.
I see this as one of the important responsibilities of a Project Manager, and I think it is sometimes skipped because of a simple argument:
“I am not their line manager.”
Exactly.
Their line manager usually sees them primarily through their permanent role and BAU responsibilities. You may be the person who has just watched them spend nine months solving problems, handling difficult milestones and getting your project across the line.
Who is better positioned to recognise that contribution?
Recognition doesn’t need to wait until project closure. An important milestone is a good opportunity. Go-Live definitely is. And formal project completion should not pass unnoticed.
In today’s high-paced organisations, it is surprisingly easy to deliver something, close the actions and immediately run towards the next urgent thing.
Stop. Even for a moment.
If geography and budget allow, bring people together. Have a cake. If they don’t, written recognition still matters.
But make it real.
Don’t send:
“Great job everyone. Thanks for your support.”
Say what actually happened. What did we deliver? What did we overcome? Which teams were involved? What made this project different?
Give people the espresso version of the journey they have just completed.
For larger projects, prepare this communication before Go-Live. Build the stakeholder list during the project.
And remember the wider circle around the core team. Security. Operations. Procurement. Legal. Infrastructure. Architecture. Business teams. Vendors. Whoever helped your project get there.
Some may have contributed only a small piece of the overall journey. But perhaps without that piece, you wouldn’t be going live.
Cross-check the list with workstream or team leads so nobody gets forgotten.
I also like to give the core team a little extra space in the communication. Something along the lines of:
“One more thing. Let's make sure the project core team doesn’t stay behind the scenes. You are the people who made this delivery happen.”
And I list the names alphabetically.
There are no better ones.
And when somebody really did something exceptional, say that too.
We may not have the authority to promote them or change their salary. But we can send meaningful feedback to their line manager.
Be specific. Explain what they did, how they supported the project and why it mattered.
Sometimes that feedback may become one of the starting points for a line manager to recognise that the person is ready for the next step.
Every project probably has its MVP.
And I mean the basketball MVP here, not Minimum Viable Product.
The person who, like the key player in an NBA game, made a particularly important contribution and helped push the team towards a successful end.
But even the best basketball player doesn’t win games alone. There are teammates defending, creating opportunities, doing the less visible work and making sure the whole team can perform.
Projects are not so different.
Sometimes one person makes an exceptional contribution. Perhaps they solved a problem nobody else could solve, took responsibility at a critical moment or simply went far beyond what was expected.
Recognising that person doesn’t take anything away from the rest of the team. We can appreciate the collective achievement and still recognise somebody who made a particular difference.
And if you have your project MVP, make sure somebody knows.
Your team put their hard work into your project. Appreciate it.
Because if you don’t do it, there is a fair chance nobody else will.
And then the team disappears
Eventually something slightly strange happens.
The thing you spent months or sometimes years building starts to disappear. The project is completed. The structure is disbanded. People return fully to their teams. Others move immediately to another project.
Meetings disappear from calendars. The chat becomes quiet.
Your Mr. Wolf is already solving somebody else’s problem.
Once upon a time there was a Team.
Hopefully, something remains.
People who worked well together may meet again on another project. You probably won’t get exactly the same team. That almost never happens. But perhaps you get some of the same people.
A little bit of leaven from the previous team.
You already know each other. You know how you work. You know who will speak first and who needs to be asked. You know who will ring the bell early and who will quietly fight with a problem for two days before saying anything.
Starting the next project becomes a little easier.
And something remains with us as PMs too. Every team changes us.
What worked? What didn’t? Who surprised me? Where did I interfere too much? Where should I have stepped in earlier? What can I do differently next time?
Projects deliver products.
But project teams also leave experience behind.
Maybe that is why I don’t particularly like thinking about people simply as “resources.”
Of course, we need resource plans. We need capacity. We need allocations. We need RACI. We need to know who is doing what and when.
But 1 FTE in a spreadsheet does not design anything.
It doesn’t solve a problem. It doesn’t stay late before Go-Live. It doesn’t challenge your assumption. It doesn’t help another team. And it doesn’t turn a project vision into something real.
People do.
Our job as Project Managers is not to deliver instead of them.
Our job is to create the conditions in which they can deliver. Protect when protection is needed. Enable when something is blocking them. Connect people when they need connecting. Bring some order when things around them become complicated.
And when the work is done, stop for a moment and make sure they know it mattered.
Then let the team go.
Until the next project brings another group of people together.
Over and out.