Welcome aboard
It starts with an invitation.
You've been asked to join a Project because of your Business knowledge. Apparently, your experience will be invaluable, which is encouraging. You've always suspected it was valuable, although it's nice to have independent confirmation.
Your first meeting is already in the diary. The invitation includes several people you don't know, a collection of initials you don't recognise and an attachment containing a diagram with rather more arrows than seems strictly necessary.
Still, you're looking forward to contributing. You know your job, understand how your part of the Business operates and have plenty of practical experience to offer.
How difficult can it be?
An impressive amount of information
The meeting begins with an enthusiastic introduction to the Project. Someone explains the timetable, another describes the governance arrangements, and a third takes everyone through the delivery plan. There are milestones, dependencies, workstreams and a brief discussion about something called a RAID log.
Everyone is helpful. Nobody seems unwilling to explain things, and you take plenty of notes. By the end of the meeting, you've learned several new expressions and discovered that the Project has a remarkably sophisticated approach to reporting progress.
Unfortunately, you still aren't entirely sure why you're there.
You assume that will become clearer with time. After all, this is your first Project, and everyone else seems to know what they're doing.
Different people, different Projects
Over the next few days, you begin talking to people.
One person explains that the Project is about improving efficiency. Another says the main objective is to reduce errors. Someone else believes the priority is replacing an ageing system, while a fourth talks enthusiastically about improving the customer experience.
These explanations aren't necessarily contradictory. A Project can legitimately have several objectives, and different people will naturally emphasise the aspects that matter most to them.
But you're beginning to wonder which of these things is the main reason the Project exists, what success will actually look like and how your own contribution fits into the picture.
You ask a member of the Project team for clarification. They explain the delivery plan again, this time with fewer acronyms.
It's a perfectly reasonable explanation. It just doesn't quite answer your question.
Apparently, the Business was doing something
At some point, somebody asks how the Business review is progressing. It might be after your first meeting, a few days later or once you've begun to feel reasonably comfortable with the Project.
You ask which review they mean.
There's a brief silence, followed by an explanation that the Project needs confirmation of how a particular process operates. The information is required before the team can proceed with the next stage of its work.
You know the process well. In fact, you're probably one of the best people to explain it.
The difficulty is that nobody had made clear that this was something you were expected to provide, or when the Project needed it.
You'd been attending meetings, reading documents and trying to understand the bigger picture. Meanwhile, the Project had been expecting a contribution that you didn't know was on your list.
You are now considerably more familiar with Project terminology than when you joined. Unfortunately, the terminology hasn't completed the review.
When everybody is still learning
It's tempting to assume that someone in the Project team should have explained everything properly at the beginning. And sometimes that's true.
But Project teams contain people with different levels of knowledge and experience. Some understand exactly why a particular Business representative has been invited. Others may know only part of the story, particularly if they're relatively new to the Project themselves.
The person helping you find your feet may be finding their own feet at much the same time.
That doesn't make either of you incapable. It does mean that an explanation can be sincere, helpful and incomplete.
There is another complication. When you're unfamiliar with Project life, you don't necessarily know which questions you should be asking. You may assume that the important information will emerge naturally as you attend meetings and become more involved.
Sometimes it does. But familiarity with the meetings isn't quite the same as understanding the Project.
Finding your bearings
A useful starting point is to ask why the Project exists.
Not just what it is delivering, but what problem it is trying to solve or what opportunity it is pursuing. What will have changed when it succeeds? What will people actually notice?
Then establish why you've been invited. What knowledge or perspective does the Project need from you? Are you expected to explain how things work today, review proposed changes, contribute to workshops or help make decisions?
And, importantly, ask whether there is anything the Project needs from the Business right now. There may be an urgent review, a workshop to prepare for or information that someone is waiting to receive.
These questions won't tell you everything, but they will give you a useful starting point.
Don't rely on just one explanation
One of the most useful things you can do when joining a Project is speak to several people who understand different parts of it.
Ask your main Project contact who you should talk to and whether they can help arrange introductions. An organisation chart or stakeholder map may be useful, but a short conversation with the right person can often provide context that is difficult to extract from a diagram.
Listen to how different people describe the problem, the priorities and the intended outcome. Notice where their explanations agree and where they differ.
You don't need to resolve every difference yourself. In fact, some may reflect legitimate uncertainties that the Project is still working through, particularly during Discovery.
But recognising those differences helps you ask better questions and avoid treating one person's perspective as the complete picture. It may also help the Project identify something that needs clarifying.
The Project Survivors observation
Being included in a Project is not the same as being properly equipped to contribute to it.
A newcomer may receive plenty of information without enough context to understand why it matters, what is expected of them or who can help them find out.
And because different people may understand the Project differently, becoming informed isn't always a matter of finding one person who knows all the answers.
The aim isn't to become an expert in your first fortnight. It's to establish what the Project is trying to achieve, what it needs from you, who you should speak to and what remains uncertain.
You don't need to become a Project Manager. You just need to find your bearings.
Preferably before somebody asks how that review is coming along.
Explore further
Understand: You've Been Put on a Project. Now What? — a practical introduction to finding your place in Project life.
Act: Your First Two Weeks on a Project — practical preparation for asking useful questions and agreeing what happens next.