A technical assistance engagement starts with a document that is often short: the statement of need. It is sent to approved suppliers, who put forward profiles on that basis. Its quality determines the quality of the responses, the accuracy of the choice and how well the engagement starts.
A well-written request lets the provider put forward few profiles, all of them relevant. A vague request produces many submissions that are hard to compare, and a longer selection process for the IT department.
Below are the sections we recommend, and the mistakes we see most often.
Context
The context explains why the engagement exists. A few lines are enough:
- the business area (payments, lending, insurance contracts, regulatory reporting, and so on);
- the project or programme the engagement belongs to, and how far along it is;
- the main technical environment;
- how the team the consultant will join is organised.
Context lets the provider judge whether a candidate has worked in a comparable situation. The same job title covers very different realities depending on whether the project is starting up, in acceptance testing or in application maintenance.
Tasks
Tasks describe what the consultant will actually do. They are best written with action verbs: write functional specifications, run workshops with business teams, track the workstream plan, develop changes, prepare steering committees.
A list of five to ten tasks gives an accurate picture. Beyond that, it becomes hard to tell the essential from the incidental. It helps to indicate the one or two tasks that will take up most of the time.
Deliverables
Deliverables are what the engagement must produce: documents, code, test plans, dashboards, progress reports. Naming them precisely has two benefits.
First, they allow the engagement to be assessed on observable results. Second, they support a sound contractual framework: in a technical assistance engagement, the provider retains line management of its consultant, and the client expresses its expectations in terms of work and deliverables.
Seniority
Seniority is better described through situations than through a number of years. A few questions help pin it down:
- Will the consultant need to work autonomously from the first weeks?
- Will they run meetings with business heads or directors?
- Will they make decisions, or prepare decisions for others?
- Will they coordinate other contributors?
A number of years of experience can complement this description. On its own, it says little about a person’s actual ability to do the job.
Skills
It helps to separate essential skills from desirable ones. A list where everything is mandatory artificially narrows the pool, and sometimes pushes providers to submit profiles that tick every box on paper.
For technical skills, precision helps: a technology version, a specific tool, a type of architecture. For functional skills, knowledge of a business area or a regulation is described the same way, with the expected level.
Duration, start date and rhythm
These practical points are often underestimated, yet they determine which profiles are available.
- Start date: preferred and latest. A consultant currently on assignment often has a notice period or an engagement to finish.
- Duration: initial term and likelihood of renewal.
- Rhythm: full-time or part-time, number of days per week.
- Location and remote work: site, number of days on site, remote access conditions.
- Specific constraints: on-call duty, work outside business hours, travel.
Selection process
Explaining how selection will work helps the provider organise itself: response deadline, expected format of submissions, maximum number of profiles, planned interviews and who will conduct them.
Common mistakes
A job title with no description
“Senior project manager” or “Java developer” is not enough. Without context or tasks, each provider interprets the need in its own way.
A skills list that is too long
Fifteen mandatory skills rarely describe a real person. Three or four firm requirements, plus clearly identified complementary skills, work better.
One request covering several roles
Asking one person to manage a project, write specifications and develop leads to compromises. If the workload justifies it, two distinct profiles often deliver a better result.
Constraints revealed late
A number of on-site days, a security clearance or on-call duty discovered at interview stage wastes everyone’s time. These points belong in the statement of need from the start.
An unrealistic start date
A start within a few days limits the choice to consultants who are immediately available. That is not always the best selection criterion.
What we do with your request
When we receive a statement of need, we read it with these sections in mind. If information is missing, we ask before putting forward a profile. We would rather submit one well-matched profile a little later than several approximate ones quickly.
A clear statement of need saves time for the IT department, the purchasing team and the provider. It is also the first document in the follow-up of the engagement: the tasks and deliverables it lists serve as the reference at each review point.