You've Been Put on a Project. Now What?

First, you haven’t changed jobs. But your job may have changed.

One of the peculiar things about being assigned to a Project is that it doesn't always feel like a formal change of role. Your normal responsibilities are still there: customers still need serving, colleagues still need support, and your inbox hasn't become any smaller. But now the Project needs you too. Perhaps you're expected to attend workshops, explain Business processes, review proposed changes, test a new system or help colleagues prepare for a different way of working. Sometimes nobody has explained quite how you're supposed to fit all that in.

Being involved in a Project isn't necessarily a full-time assignment, but it does require time, attention and sometimes decisions. It's worth asking early: ‘What will you need from me, and how much time should I expect to spend on it?’ That's not being difficult; it's being practical.

Why you?

You might reasonably wonder why a team of Project specialists needs someone like you. Surely they already know what they're doing? In many respects, they do. They may understand how to organise a Project, manage schedules, coordinate activities, control costs and deal with risks. But there's something they may not understand nearly as well as you do: your Business.

You know what happens when a customer calls with an unusual problem. You know which procedures work beautifully on paper but require a little interpretation in real life. You know which colleagues are quietly keeping things running, which exceptions matter, and which apparently small changes could create considerable disruption. A Project can deliver a technically impressive solution that doesn't work particularly well for the people expected to use it. Your involvement helps prevent that. You're not there simply to answer questions; you're there to bring the reality of the Business into the conversation.

You don’t have to understand everything immediately

Projects have a language of their own. Some terms are genuinely useful; others seem to have survived because everybody has become accustomed to using them. Either way, it's easy to feel at a disadvantage when everyone else appears fluent. But familiarity with Project terminology isn't the same as understanding the Business, and asking for clarification is not an admission of incompetence.

If someone says, ‘We need to baseline the requirements before the next governance checkpoint,’ it's perfectly reasonable to ask: ‘What does that mean in practice, and what do you need me to do?’ Good Project colleagues should be able to explain what they mean in ordinary language. If they can't, the problem may not be your understanding.

Find out what sort of involvement you’re being asked for

Not every Business representative has the same responsibilities. You might be asked to contribute specialist knowledge, represent a team, help make decisions, review documents, participate in testing or support the introduction of a new way of working. These are different activities, and they don't necessarily come with the same authority. Being asked whether a proposed process would work is not quite the same as being authorised to approve it on behalf of an entire department.

Before accepting a significant responsibility, establish what you're expected to contribute, whether you're advising or deciding, who else needs to be consulted, what authority you have and who can help if you're uncertain. You don't need an elaborate role description, but you do need enough clarity to avoid discovering, three weeks later, that somebody thought you'd agreed to something you hadn't.

Get to know the people around you

One of the most useful things you can do early in a Project is discover who does what. The Project Manager will usually be concerned with organising and coordinating the work. A Business Analyst may help explore what the Business needs and describe those needs in a form the Project can use. A Sponsor may provide senior-level direction and support. Other Business representatives may bring experience from different departments or processes. Titles vary, and one person may fulfil several roles.

What matters is knowing whom to approach. Who can explain a confusing document? Who can help resolve a disagreement? Who can clarify whether something is within the Project's scope? Who can help you obtain the time or support needed to do your part? You should understand not only why these people need you, but why you might need them. Project participation should be a two-way relationship: you bring expertise, and the Project should provide information, explanation and support. Our Who's Who in Project Life guide is a useful starting point.

Be careful with the word “agreed”

Here's a small warning. In ordinary conversation, saying ‘Yes, that sounds reasonable’ can mean you're following the discussion and broadly understand the suggestion. In a Project meeting, somebody may interpret it as agreement. And agreement has a habit of finding its way into meeting notes, action logs and decisions. This doesn't mean you should become suspicious of every conversation; it means being clear about what you're agreeing to.

If something sounds promising but you need to check with colleagues, say so. If you're comfortable with the general approach but haven't reviewed the detail, explain that distinction. A useful phrase is: ‘That sounds sensible in principle, but I need to check the practical implications before confirming.’ It's much easier to clarify an understanding during a meeting than to unravel a misunderstanding afterwards.

Remember the people who aren’t in the room

Projects often involve people who spend a great deal of time discussing how things will work. But the people who will eventually use the new system or follow the new process may not be present at those discussions. You may be their connection to the Project. That doesn't mean you're expected to know every opinion or speak for every colleague; it does mean you can help the Project recognise when it needs to involve others.

Ask who will be affected by the change, what they will need to know, and whether there are exceptions or practical constraints that haven't been considered. Perhaps most importantly, ask: ‘Have we spoken to the people who actually do this work?’ It's a remarkably useful question.

You are allowed to ask for help

There can be an unspoken expectation that experienced Business professionals will simply adapt to Project life. After all, they're capable people, they know their work, and they'll work it out. Sometimes they do. But being good at your existing job doesn't automatically make you familiar with Project procedures, documentation, responsibilities or decision-making arrangements.

You may need explanations, time to prepare, or support from your manager or colleagues. None of that diminishes your contribution. In fact, asking for what you need is often the best way to make that contribution worthwhile.

Five things to establish at the beginning

If you've just been invited onto a Project, start with five straightforward questions. You don't have to resolve everything on day one, but you should begin to understand the territory.

1. What is this Project actually trying to achieve? Not the technical description; the practical outcome.
2. Why have I been asked to get involved? What knowledge, experience or perspective are you expected to bring?
3. What will I be expected to do? Meetings, reviews, decisions, testing, communications — and how much time might they require?
4. Who can help me? Find the people who can explain, clarify and support your involvement.
5. What happens next? Identify your immediate actions and any decisions or deadlines that matter.

Same you. Different world.

Being placed on a Project can feel rather like arriving in a country where everyone speaks your language but uses the words differently. You recognise some of what's happening; other things seem unnecessarily mysterious. Gradually, though, the patterns become clearer. You begin to recognise the people, understand the conversations and see where your experience fits.

And something important becomes apparent: you weren't invited because you needed to become a Project expert. You were invited because you already know something the Project needs. You don't need to become a project manager. You just need to understand what's happening, what's expected of you, and how to contribute with confidence. That's a very different proposition — and a much more manageable one.