briefing and scoping
We've all been there, haven't we? We get a request from colleagues in another team, a senior executive, or a client. We're excited, we know what needs to be done, and we do it. We show all the great work we've done at a review meeting, and we hear those dreaded words: "Oh, this isn't what we thought you'd come back with..."
Back to the drawing-board, and this time you're tired, annoyed, and just want the project to be over. You've wasted time, resources, and all this could have been avoided had they just been clear from day one!
Thing is, people (most of the time) don't set out to mislead us; we all want to do the best work that we can. Over the years of these scars, we've developed some coping mechanisms: two tools, actually, that will be free for you to download and use. One is for brief scoping, and the other for project documentation. And really, it's to help anyone who is embarking on new projects, to actually really clarify requirements, and to reduce misalignment between either stakeholders or project team members.
misalignment sucks
but what exactly is alignment?
We've talked about misalignment, and it's something that we started thinking about. What exactly does it mean? What is alignment? We've come up with three basic definitions of the three stages of alignment, if you will. And we thought it would be quite interesting to share that early on, so that there's no misalignment between you and us (sorry, we're not professional comics).
Aligned
Imagine someone has requested you to develop a training toolkit. There's alignment when both of you know and agree on what constituted a toolkit. For example, it should have a training manual, some templates, and an instruction video, okay. And when everyone says, yes, these three items are what we need for the toolkit, we have alignment.
MisAligned
But now imagine where you think everyone agrees on what a toolkit is - however, you don't see a need for a training video, while the requester does.
This is what we call misalignment - when people don't actually share the same point of view, but they think they do.
This results in wasted time and resources, only to realise too late that we've all been moving in different directions.
UnAligned
We came up with a third category: where people don't agree, and they know that they don't. This awareness of a lack of alignment is still less than ideal, but much better than not knowing. You can use all your talents and experience to get everyone to align when you know something is wrong, even before starting any further work.
While we won't promise that these tools will guarantee alignment, we are very confident that they will prevent misalignment. Any significant differences in how people (who matter) are thinking about the work to be done will be highlighted early on, and can be dealt with.
So onto the first tool itself, which is very straightforward: it's a list of questions that we've designed. And when we designed them, we had in mind specific areas where we have experienced misalignment - which we'll highlight as we go through the questions. There are also two sections: the first set of questions you can answer together with whomever it is that is requesting you or your team's time. The second is specifically for you (and the team responsible for doing the work) to answer.
When you're trying to answer these questions will all the right people, you'll probably get very many different answers: you'll identify points where you're unaligned. Hopefully, you're able as a group to have the discussion and compromises needed to get to a singular answer: alignment.
Into the questions!
scoping tool
Who is asking?
It might be really obvious, but the first thing we wanted to understand was, who is asking this particular request? And it's really for us to make sure that we have the right people in the room.
We've all been in situations whereby you ask a clarifying question, but they can't answer you: they either don't have the information or can't make a decision - "I'll need to check with my boss."
You definitely want to be asking the person making the request these clarifying questions, and not the messenger! Of course, if you have certainty that they can in fact speak for their managers, then go right ahead.
What are they asking for?
Once you're sure you're talking to the right people, you want to confirm what exactly they are asking for. Do they have an output in mind? (a toolkit) What is their definition of that toolkit being done? (manual, templates, and video).
What is it meant to achieve?
Next is a higher-order question: why are they asking what they're asking for? There are many different ways that a particular objective could be achieved - you as an expert might be able to propose an entirely different approach than the one the requester thought of.
An easy way to ask this question is "what does success look like?" What are the metrics that measure success? What targets do they need to hit?
Also, ask if this success is tied to an organisational OKR/KPI; this allows you to understand the larger context of the request.
Equally importantly, it lets you later decide if this is something that should be a priority for your team - if it doesn't contribute to a target that needs to be hit, and you already have too much on your plate (as we're sure you do), this may not be the best use of your time.
What decision is it meant to inform?
This is particularly useful if the work entails an analysis, report, and/or recommendation. If you understand what decision management needs to make, you can figure out the best way to support it.
Also very important is confirming if the person making the request can also make the decision. We've been in situations before whereby well-intentioned requests stemmed from curiosity instead of the ability to make an impact to the organisation based on the output. This doesn't mean we immediately chuck the request, though! If it's a great idea, let's find the person who can make the decisions.
It's also good to find out if anyone else is involved in the decision-making: just like the first question, this helps ensure that you have the right people in the room when you're asking these clarifying questions.
When does it need to be done by?
Pretty straightforward, but useful in deciding resource allocation: what's the priority of the request, how many people need to be working on it to get it done in the time, or if the requested output is even possible at all!
Who needs to approve?
Effectively, everyone who needs to say yes to the output - just so that the working team knows who to engage while it is working! These are also the people who need to be in the room when you're getting clarity on the work to be done.
Who can kill the output?
As important as the people who need to say yes, who can say no? Asking both questions also allows you to identify a very special subset: the people who do not need to approve your work, but have the power to kill it. You need to be very deliberate on if and how you will engage with these people!
questions for yourself or your team
Now that you hopefully have alignment (or at the very least clarity) on what the ask is, you can go on to make some decisions - either yourself (if you are delivering the work independently or you're the lead) or with your manager. Always a good idea to include the team as well!
-
Who is available to do it?
-
How much time / resource should be invested?
-
What needs to be done? (activity scope)
Your answers to these questions will effectively determine the scope of work, resourcing, and timelines - all things that you should go back to the people you have already gotten alignment with thus far to ensure they agree.
After you've answered the questions above and achieved alignment with your stakeholders, you are ready to kick off the project. That's where the second tool comes in!
The project documentation is meant to capture all pertinent information or decisions that you have elicited through the questions above. In doing so, the project team has a single source of truth that can be used to either brief new project members or update other stakeholders at any time. This also ensures that what is communicated is always consistent and clear for anyone who wants to find out more about your project.
As a best practice, it is recommended to update the project documentation if there are changes to critical information such as project objectives, deliverables, timelines, or key stakeholders.
briefing document
templates to support you
To aid you in achieving greater clarity for new projects that you embark on and effectively communicating project details, we’ve designed templates (free to download) that you can use for you and your teams.
The first - brief scoping template, consists of all the questions we mentioned above and also includes a space for you to write answers from your stakeholders as well as information you have clarified.
The second - project documentation template, has 7 structured headers for you to record all the pertinent information you have elicited through the brief scoping tool. This template can then be shared on your team’s or organisation’s shared drive.
Get the templates in your inbox. We’ll also send you new versions of the tool and any training materials for free, forever!
Don't worry: this won’t sign you up for any marketing emails, though we would love to be able to keep in touch with you via our newsletter.
View the documents on Google Drive, and download/make your own copy.
