You have two choices. You can either invest a little time in creating a cast-iron brief, or you can increase the risks of failure. Your consultant can return significant value – but only if they’re properly briefed at the outset.
The risks of poor-quality or incomplete briefs include increased costs, delayed or aborted projects, stakeholder disengagement and missed opportunities. In this article we consider the make-up of an effective project brief. This list is not exhaustive. Only you can decide what your consultant needs to know in order to fulfil your requirements.
Briefing a consultant: an overview
Your consultant needs to know everything they need to know. You must remember that your consultant knows business; they don’t know your business. So any acronyms, internal jargon or idiosyncrasies that are unique to your organisation need to be explained. Your consultant needs to know what you want and how you want it. Don’t scrimp on the crucial details, but remain mindful that you don’t need to overload the consultant with unnecessary details.
Ask yourself: if I was this consultant, what would I need to know to deliver this project? By thinking about the challenge from the consultant’s point of view you can often create a more effective brief.
Ask yourself: if this project fails for some reason, what facts, details, requirements
and mandatories would I hate myself for not including? By thinking about how you might cover yourself in the event of the project failing or a dispute with your consultant you can often uncover things that matter a great deal to the project.
Of course, failed consultancy projects are relatively rare – especially when a clear
and accurate brief exists at the outset. This thought process is merely an approach to help you draw out important details. Let’s look at the content that your brief might include...
What do you want? What does your business need from the consultant?
Quantify your requirements – give numbers where appropriate. If you have specific requirements, be clear about them.
Qualify your requirements – explain what the project should look or feel like. Use enough clear descriptive words so that the consultant understands your vision of the project.
Objectives and background
Why is your organisation undertaking this project? What are your goals? And what is the backstory to this project? For example: is the project the result of redundancies – or a restructuring? Is the project the result of new competition or an expansion into new markets?
Give your consultant the whole story, and they will be better positioned to meet your objectives – and to think laterally about your project.
How should the project be conducted? Are you flexible regarding the methodology, or do you expect the consultant to follow a strict plan?
Whether you have a firm deadline or not, it’s usually wise to explain your expectations regarding timeframes. Even when there’s no real urgency about your project, you want to make sure your consultant remains focused on your project and never lets it drift.
For longer projects, you may want to include milestones along the way. So after two weeks you might expect interviews or initial research to be concluded. And after four weeks you might expect to see a first draft of the report.
If you need to review documents or statistics, give an indication of how long you need to provide feedback.
How much information are you giving the consultant? Will you hand over reports,
data, or guidance on locating resources? If the consultant needs to reference your database, directory or other assets, who will grant them access?
Stakeholders and contacts
Who will your consultant need to liaise with in your organisation? If some of your internal stakeholders need to get involved – or provide information – then you may need to check that they are prepared to offer time or assistance to the consultant. Will you make the introductions and explain the consultant’s task? Make sure the consultant knows who to contact, how to contact them and anything else they should be aware of. You can often avoid internal irritation by making sure the consultant doesn’t step on any toes or trouble the wrong person with the wrong query.
Checking-in with your consultant takes little time but can easily improve your chances
of success. Weekly – or daily – reports can help to flag roadblocks or potential challenges. And if you know about problems you stand a chance of avoiding them.
Do you have a standard reporting procedure? Or are you happy for your consultant to report using their own preferred methods? How should minor
and major problems be flagged?
What do you want to receive from the consultant? Are you expecting a report, a presentation, some statistics – or all of these?
Again, it’s best to enumerate your expectations. If you want a report with fifteen chapters and twenty factors plotted on ten graphs, then say so. How many copies of the report do you want? And what software should the consultant use to complete the project?
How will the consultant’s work be judged? What does a satisfactory project look like? What factors will you assess – and what criteria are most vital to you? Will the consultant’s work be tested? How will the deliverables be expected to perform?
We all make assumptions. See? For a water-tight brief, make sure you list all the assumptions you have made about your project.
Example assumptions include:
- The consultant will use their own IT equipment to produce these deliverables.
- The consultant will work remotely.
- The consultant will save their presentation as a PowerPoint (.ppt) file
- We expect to receive the sources of all numbers used in calculations, as well as details of how they were calculated and rounded.
- The client expects to transfer ownership of copyright upon completion and payment.
Work in progress...
It’s worth remembering that your brief may evolve over time – particularly in the early stages of your project.
In fact, you may need to amend your brief or add details once you’ve recruited a consultant. In many cases the precise methodology and deliverables may be defined by your consultant. So treat your brief as a work in progress.
Ready to get started? Post a project today.
About the AuthorFollow on Twitter Follow on Linkedin More Content by Rebecca White