It’s nice to be wanted
You've been invited to join a Project because you understand how your part of the Business works.
This seems reasonable. You've spent years learning the processes, understanding the people and discovering which apparently straightforward activities become considerably less straightforward when something changes.
The Project team is delighted to have you involved. They have questions, you have answers, and everyone feels that progress is being made. For a while, it all goes rather well.
Just one more question
The Project is planning to change some information used by your department. You explain where the information comes from, how your team uses it and what might happen if particular fields are changed.
The Project team makes notes. Someone asks whether a report will be affected. You explain that your department doesn't produce that report, although another team uses an extract of the same information. That's helpful, says the Project team. Who should they speak to? You provide a name.
A few days later, another question arrives. The other team has explained that the information also feeds a system used elsewhere. Apparently, someone there has suggested speaking to another colleague.
The Project is discovering that the information travels considerably further than anyone initially realised. And you are discovering just how many people are involved in something you thought you understood quite well.
The Business is a surprisingly large place
From the Project's perspective, there's a perfectly understandable reason for these questions arriving in your inbox. You're the Business representative. The Project needs Business knowledge, and you're the person it knows.
The difficulty is that the Business isn't necessarily one coherent group with a single view of everything. It may consist of departments with different responsibilities, processes that cross organisational boundaries, systems that exchange information and teams that depend on outputs produced elsewhere.
You know your department. You may understand several others reasonably well. But that doesn't mean you can explain every dependency or speak on behalf of everyone affected by the proposed change.
When one question becomes a workshop
As more people become involved, the Project arranges a workshop to understand how information moves between teams and what the proposed changes might affect.
One person explains where the data originates. Another describes how it is processed. Someone else identifies a regular extract feeding an important report. A further participant explains that the report supports a process nobody had previously mentioned.
The picture gradually becomes clearer. So do the boundaries. Different teams have different responsibilities, and certain decisions require people who weren't part of the original discussion.
The Project hasn't necessarily done anything wrong by discovering this. Investigating the impact of change is one reason Projects need Business involvement. But the discovery matters: the Project now knows that wider consultation and investigation are needed before proceeding.
Knowing where your knowledge ends
There's a temptation, particularly when you're new to Project life, to feel you should answer every question directed towards you. After all, you're there because you're supposed to be the expert.
But expertise has boundaries. You may be the right person to explain how your team works and entirely the wrong person to confirm how another department uses its information. You might know who manages a process without having authority to approve changes to it.
A useful response is often: ‘I can explain how this affects our team, but another department also uses that information. We should involve them before deciding what to change.’ That gives the Project something valuable: an answer within your expertise and a sensible next step beyond it.
The value of another name
Sometimes the most useful thing you can contribute isn't an answer. It's the name of someone who can provide one, a warning that a process crosses departmental boundaries, or a suggestion that several teams should discuss a change together.
But there's an important distinction between helping the Project identify other Business areas and becoming responsible for bringing all those areas into the Project. That is the Project's responsibility.
You can explain what you know, identify potential dependencies and suggest people who should be consulted. You may help with introductions where appropriate. But you shouldn't automatically become responsible for recruiting representatives from other departments, arranging their participation, chasing their contributions or securing decisions on their behalf.
The Project needs to establish which areas are affected, engage the appropriate people and ensure that responsibilities and decision-making authority are clear. Depending on the organisation, this may require support from Business management or senior sponsors.
Of course, your own role may explicitly include coordinating wider Business involvement. If so, that responsibility should be understood and agreed, rather than assumed simply because you're the person the Project already knows.
Your contribution is to help the Project recognise where its understanding or representation may be incomplete. The Project must then take responsibility for addressing those gaps.
The Project Survivors observation
Being appointed as a Business representative doesn't make you the representative of the entire Business.
Projects may begin with an incomplete understanding of the people, processes and systems affected by a change. As that understanding develops, additional expertise and representation may be needed.
Your value isn't measured by how many questions you can answer personally. Sometimes the most important contribution you can make is recognising that a question belongs with somebody else.
You don't need to know everything. You do need to know when it's time to involve someone who knows more. And if another department appears unexpectedly in the discussion, don't be surprised if it knows a few departments you haven't met yet.