Workstream Scoping: Showing One Client Contact Only Their Part
The finance lead should not read the human resources workstream, and building a separate portal for each is not the answer.
On a small engagement every client contact can reasonably see everything, and scoping is a solution to a problem you do not have. On a large one it becomes necessary quickly. A transformation programme with workstreams for finance, technology, operations and people has contacts who belong to one of those and should not be reading the others, sometimes for confidentiality and sometimes simply because the noise makes the portal useless to them.
The clumsy answers are to run a separate portal per workstream, which multiplies the administration and fragments the client relationship, or to give everybody everything and rely on discretion, which is not a control. The workable answer is a grant that carries a scope, and a portal that honours that scope on every read.
What scoping has to reach
A scope that applies to documents and not to messages is not a scope. The property that makes it trustworthy is that every read narrows, without exception, and that the exceptions are the ones you deliberately chose rather than the ones somebody forgot.
- Deliverables: a contact scoped to finance sees finance deliverables and does not know the others exist.
- Information requests: they are asked only for what their workstream owes, which also improves response rates because the list is short and relevant.
- Meetings and minutes: workstream meetings narrow, while a programme-level steering committee is visible to those admitted to it.
- Threads and messages: a question raised on the technology workstream is not readable by a finance contact.
- Documents: the library narrows, and a document not in scope is absent rather than locked.
The unscoped grant, and why it should be the default
A grant with no scope should mean the whole engagement, and that should be what a grant means unless somebody narrows it. This sounds like a small design decision and it prevents a specific and unpleasant failure: a scoping model where an empty scope means nothing produces contacts who can sign in and see an empty engagement, which reads as a broken product rather than a permissions state.
It also matches how firms actually work. Most contacts on most engagements are entitled to the whole thing, and narrowing is the exception. Making the exception explicit and the norm implicit means the common case requires no decision and the uncommon one requires a deliberate act.
Scoping is not the same as an information barrier
These two are frequently conflated and they solve different problems. Scoping is about relevance and routine confidentiality within a single client relationship: the finance lead does not need the people workstream. It is administrative and it is adjusted often.
An information barrier is about a conflict: a party who must be prevented from seeing an engagement even though they might otherwise be entitled to it, because the firm also acts for their counterparty. It is not administrative, it is not adjusted casually, and it must deny rather than merely narrow. A product that implements one and calls it the other will eventually fail in the way that matters, because scoping is designed to be relaxed and a barrier must not be.
Operating it without creating an administrative burden
- Set the scope at the moment of invitation, when the reason is known, rather than as a follow-up task that will not happen.
- Scope to workstreams rather than to individual items. Item-level permissions are seductive and become unmaintainable within one engagement.
- Review scopes when the engagement is re-shaped, because a workstream that splits leaves every grant pointing at the old structure.
- Show the firm-side team what a given contact can see, plainly, so the question of whether somebody can read something is answered by looking rather than by reasoning about rules.
- Revoke at closure as a step in the closure process, and let a grant carry an expiry so that forgetting is bounded.