I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

The Team Doesn’t Know Why It’s Doing the Project. Where the PM Gets the Answer

A kick-off for a new project. On the screen there is the schedule, the scope and the milestones, all prepared the way it should be. Near the end of the meeting someone from customer service speaks up, a person “borrowed” for the project two days a week: “Why are we actually doing this?”

There is a silence, and then someone answers that the board approved the project last quarter. That is true, but the person who asked goes back to their desk with the same question.

I’ll give you the most important point of this article straight away: a project manager can’t invent a purpose the sponsor never gave them. What they can do is get it out of the sponsor before the schedule starts running, and then translate it into something a team member will see in their own working week. Those are two separate jobs and both belong to the PM.

It happens most often with processes that already work but have to be changed for some reason. Perhaps new legal requirements have appeared, perhaps the project’s environment has changed, and then people ask a very simple question: why touch it if it works? One current example is implementing the requirement that a customer can withdraw from a contract in the same way the order was placed. In theory the process works, because the user can already cancel an order, for example by sending in a completed form, but the new requirements set by the EU are that cancelling should be easier for the user. The people on the project team don’t have to be up to date with this kind of information, so it is worth answering the question of why we are doing this at the meeting.

To start with, purpose gets discussed in projects less often than it seems

You might think the kick-off scene is an exception. Brown, Hyer and Ettenson, in “The Question Every Project Team Should Answer”, published in MIT Sloan Management Review, described project teams that had run into trouble, and noticed that many of them had never discussed why they were doing the project at all.

In my experience a team like that usually knows what it has to deliver and by when, while the question of which problem is supposed to disappear once the project is over stays unanswered.

Why does that happen? The sponsor usually knows the answer, only nobody has asked them for it in a way that could be repeated to the team. The business case says “optimisation of the order handling process”, and a person on the team has no idea what to do with that sentence on Monday morning.

The people who ask most often are the ones “borrowed” for the project

While we are here, it is worth looking at who asks about the purpose. It is rarely a developer or an analyst who has been in the project since the first conversation. More often it is someone from accounting, customer service or the warehouse, whom their manager has assigned for two days a week.

That person wasn’t in the meetings where the project took shape. Their own work is waiting in their home department. For them the project is an extra duty they didn’t ask for, so “why” is a perfectly reasonable question coming from them.

If the PM leaves it unanswered, they will get from that person exactly as much as the task list requires. It is hard to hold that against them.

The PM’s first job is to get the “why” out of the sponsor

Before the PM starts convincing the team of the purpose, they have to hear it themselves in a version that can be said in one sentence at the table. At the start of a project I ask the sponsor three questions for that.

1. Who will use the result of this project? It should be a specific group, ideally one you could invite to a meeting: salespeople, the warehouse, customers placing orders.
2. What will change for those people on the day we finish? A good answer describes their work, for example “the quote goes out to the customer the same day”. The answer “a quoting module implemented” describes our system and tells the team very little.
3. How will we know it is done? One observation is enough, as long as everyone on the team would recognise it the same way.

If the sponsor answers these questions without hesitating, the PM has material ready for the team. If the sponsor can’t answer, that is valuable information too, and it is better to find out in week one than on acceptance day.

The sponsor’s answer alone changes nothing in the team yet. A sentence written in the kick-off notes lives for a week, so there is a second job to do.

The second job is to show that purpose in the team’s working week

The PM has three things within reach here that need no extra budget. The first two are backed by research in work psychology, the third comes from practice.

Contact with the person who receives the result. Adam Grant studied call centre workers who were raising donations for scholarships. After a short meeting with a scholarship student, someone who was actually benefiting from that money, they worked with noticeably more persistence. It was one organisation and a small group, so I wouldn’t turn it into a law of nature, but the direction is clear enough for a PM. A person “borrowed” from another department looks at their tasks differently once they have seen the person who will use the result. In a project that can be fifteen minutes in a sprint review, with a salesperson showing how they put a quote together today.

Visible progress. Teresa Amabile and Steven Kramer, in their book “The Progress Principle”, described that what was most strongly linked to a good day at work was a sense of progress in work that has meaning. That is a relationship, not proof of a cause, but it gives the PM a simple move: at the Daily and in the status report, show progress in the language of the purpose. The sentence “we closed fourteen tasks” tells the team very little. The sentence “a salesperson can now put a quote together without retyping data from a spreadsheet” tells them we are closer.

A shared picture of what “done” is. This is where the third question to the sponsor comes back. When the analyst, the developer and the tester carry three different pictures of the end in their heads, each of them works conscientiously and each delivers something different. It is worth writing down the sponsor’s answer to the question of how we will know we have finished, in a place the team looks at every day, and coming back to it with every decision about scope.

What this approach doesn’t fix

There are three things this approach doesn’t fix.

The first is about vision itself. The popular belief that a team will be pulled along by a charismatic leader with a stirring vision stands on weaker scientific ground than the handbooks suggest, and research on leadership built on vision and charisma has drawn serious criticism. For us that is good news, because the PM doesn’t have to be an orator. It is enough that they know the sponsor’s answer and can show it in concrete terms.

The second caveat: if the sponsor doesn’t know the answers to the three questions, no technique for working with the team will make up for it. The PM can then tell the sponsor plainly that the team will start without a purpose, and ask who in the company does know the answer.

The third caveat: a clear purpose gives nobody more time. The person “borrowed” for two days a week still has their own job in their home department, and the project will be an extra load for them. The conversation about how much time that person really has remains a separate conversation with their manager.

What you can do on Monday

Before the kick-off, ask the sponsor three questions: who will use the result, what will change for those people, and how we will know it is done.

From the three answers, put together one sentence for the team: “We are doing this for (who), so that (what will change), and we will be finished when (how we will know).”

In the quoting example it would sound like this: “We are doing this for the salespeople, so that a quote goes out to the customer the same day, and we will be finished when the first quote goes through the new system without any data being retyped.”

You say that sentence at the kick-off and come back to it when a decision about cutting scope comes up. The next time someone “borrowed” asks why we are doing this, the answer will be ready.

What would that sentence sound like in the project you are running now?

The kick-off scene and the example with quotes for the sales team are illustrations, not a description of a specific project.

What I’d Tell a PM Whose Project Just Got a New Owner from the Outside

The director asks you in for a conversation and says that from Monday, for two weeks, there will be someone from outside in the project. They are there to “help sort it out”. You stay on as project manager, nothing changes.

You leave the room knowing that everything has changed. Someone has decided you can’t cope on your own. The team will find out tomorrow. The client probably already knows.

I have been that person from outside. Below is what I tell the project manager on day one, and a few things I usually don’t say and should.

This is not an assessment of you

I know that is how it looks. In most cases the decision to bring someone in is made for a different reason: the sponsor has a leadership review in two weeks and nothing to walk in with. They need a picture the room will believe. A picture from someone with no history of their own in the project is easier for them to defend.

Projects rarely get stuck because of one person. They usually get stuck on things the PM has no influence over: decisions that don’t get made, scope nobody defends, and people split between three subjects. Often the PM has been saying so for months and nobody listened.

What that person really needs

For the first few days someone from outside knows less about the project than anyone on the team. The only person who can change that quickly is you.

They need three things from you. A list of what has been promised, and to whom. A list of the decisions you are waiting for, with the date since which you have been waiting. Your own answer to the question of what you would change if you had the mandate to do it.

The third is the most valuable. Nine times out of ten the project manager knows what is wrong. They just had nobody to say it to in a way that would be heard.

What you can get out of it

The person from outside has something you don’t: for two weeks the sponsor listens to them. That ends when they leave, so it is worth using.

If you have been asking for a decision on scope for a quarter, say so on day one. If you are missing a person who was promised at the start, say that too. These things will go into the report as the findings of someone independent and will suddenly become urgent. The report itself will most likely follow the structure a sponsor update needs, so it helps to hand over your points in that shape.

Outside help done well ends with the PM holding more than they held before: a closed scope, decisions made, clear rules with the client.

What not to do

Don’t prepare a defence. A presentation showing that everything was done correctly takes two days and changes nothing, because nobody is asking about blame.

Don’t hide what is uncomfortable. The person from outside will find it anyway, usually on day three, in a conversation with someone from the team. Better that they hear it from you, along with the context.

Don’t disappear. Some project managers step back for those two weeks so as “not to get in the way”. Then the findings are made without them and are hard to put into practice afterwards.

What to ask on day one

You have a right to know the terms on which this is happening. Ask three things outright.

Who runs the project after the two weeks? If the answer isn’t “you”, it is better to know straight away.

Who tells the team and the client why this person has come? Ideally you say it together, in one sentence.

Will you see the findings before they go to the sponsor? Help that is run honestly shows them to the project manager first. If you hear “no”, that tells you how this cooperation is going to look.

What is left after two weeks

The person from outside leaves. The project stays with you, together with the decisions that have finally been made and a plan that now has to be carried out.

If those two weeks went well, you are in a better place than before them. If they went badly, it is usually because both sides spent the first week checking whether they could trust each other instead of working.

One question for this week

If tomorrow someone independent asked you what you would change in your project with a full mandate, what would you answer? Who can you say that to today?

All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.

Closing a Project That Refuses to Close

The system has been live for three months. Users are working in it, half the team is already on something else, and in the status report the project is still “in progress”. There are eleven items left on the list. Two weeks ago there were nine.

Nobody can say when it will end, because everyone understands the end differently. For the team the project ended on go-live day. For the client it will end when the last remark disappears. For the sponsor, when they stop paying for it.

The last five percent of a project can take longer than the first ninety-five. That rarely comes from the difficulty of the work that is left. More often it comes from nobody having agreed what “finished” means.

Why the tail drags on

There are four reasons, and they usually come together.

A list that grows. Every closed remark gives birth to two new ones. The client looks at the system more closely than during testing and reports things they didn’t see before. Some of them are bugs, and some are new wishes written down as bugs.

A team that is no longer there. The best people have been moved to the next project. The fixes are done by someone who comes back to the subject for two hours a week and each time has to remind themselves how it works.

A signature nobody wants to give. For the client the acceptance report means the end of being able to raise remarks. As long as they haven’t signed, they have the supplier at hand. Delaying is reasonable for them. It is the last and most expensive form of the gap between the client’s “done” and the team’s “done”.

A sponsor who isn’t hurting. A project that works stops being urgent. The sponsor has new matters to deal with, and the tail of the old project doesn’t hurt anyone enough to be dealt with.

Close the list before you start shortening it

In my experience one move unblocks the tail: the list stops accepting new items.

It takes a conversation with the client and one date. Until that day we collect everything that needs fixing. After that day the list is closed, and every new thing goes on a separate list, to be handled by operations or by the next phase.

The client usually agrees if they get something in return: the certainty that the closed list will be done in full and by a set date. Until now they had neither.

While you are at it, go through the list once more and put each item into one of three groups: a bug that blocks work, a bug people can live with, and a new wish. Only the first group has to be done before closing.

Define “the end” on one page

A project that is to close needs a definition of closure written out plainly. Four sentences are enough.

What has to work. What is handed over to operations, and to whom. What was deliberately not done, and why. Who signs, and when.

The third sentence is the most important and the one most often left out. A list of things not done, written down and accepted, closes a project more effectively than an attempt to do everything. A project without such a list always has something left to finish.

Give the tail an owner and a date

The last stretch needs the same thing the whole project needed: one person responsible for it, and a deadline.

A short, separate closing phase works well. Two or three weeks, specific people assigned to it full time for that period, a daily review of the list. That costs less than three months of fixes done an hour a week.

It is worth showing the sponsor this calculation in time, not in money: the team has been going back to the old project for a quarter, and the new project is standing still because of it.

Closing is an event too

A project that ends quietly leaves people feeling that nothing ended. One short meeting makes a difference: what we delivered, what we are handing over, what we didn’t do and who we thank.

After that meeting the project disappears from the status report. It is a small thing, but only then does the team really move on to the next piece of work.

One question for this week

Do you have a project that works and is formally still running? What would have to be written on one page for it to be closed this month?

All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.