A practical structure for describing a consulting assignment clearly enough to attract relevant senior experts and compare them fairly.
Describe the outcome before the skill list
Strong consultants evaluate an assignment by the problem, the authority they will have and the result they are expected to produce. Start with two or three sentences explaining what needs to change and why the work matters now.
A title such as “Senior Full-stack Developer” is useful for discovery, but it does not explain whether the person will stabilise an existing service, lead a migration or build a new product. The outcome gives the skill requirements context.
Put the decision-making facts near the top
Candidates should not need a meeting to learn the basic commercial and practical conditions. Clear facts reduce unsuitable applications and avoid late-stage surprises.
- Expected start, duration and weekly allocation
- Location, remote-work expectations and time-zone needs
- Working language and any formal eligibility requirements
- Rate range or pricing model
- Interview stages and target decision date
Separate evidence from preferences
Divide requirements into three groups: evidence that must be demonstrated, experience that is useful, and technologies that can be learned during the assignment. A long undifferentiated list makes every item look mandatory and can exclude capable candidates.
Ask for evidence that predicts success. “Five years of React” is easy to count but may be less useful than evidence of improving a high-traffic product, leading a difficult upgrade or coaching a team through a new architecture.
Explain the environment and constraints
Include the team shape, decision makers, current architecture and the main constraints. Mention whether the consultant is expected to lead, implement, advise or combine these roles. If the work involves regulated data, public procurement, security clearance or accessibility requirements, say so early.
Confidential client details can remain private while the brief still explains the sector, scale and working context. Specificity does not require exposing sensitive information.
Turn the brief into a scorecard
Before publishing, convert the most important requirements into a short scorecard and agree who makes the decision. Use the same core questions for every candidate. This improves speed and makes the final choice easier to explain.
After the first conversations, update unclear parts of the brief. Repeated candidate questions are useful evidence that the assignment needs a sharper description.