A job evaluation rarely fails because of the methodology itself. More often, the problem lies upstream: a poorly framed request, incomplete information, missing data or an assumption that had never actually been validated.
And the questions that come up regularly are not only technical.
Around requests there are flows, and there are questions of ownership. Who is asking? And who takes ownership of it? What information must be available before the analysis even begins?
The order in which to approach a job architecture, its descriptions and its evaluations, I covered in “Job architecture, descriptions, evaluation: where to start to save time?”. What follows sits alongside the analysis itself: how are incoming requests handled?
Who takes ownership of it
An evaluation request often arrives as a recruitment need, a reorganisation, a request for revision. It comes from the manager, the recruiter, the business, the transformation team.
Before anything begins, someone must take ownership of it. Not carry it out, take ownership of it, meaning gather enough to understand it and establish whether an evaluation is in fact the right action. A full submission comes later, and only if it is genuinely useful.
The request needs an entry point and a clearly identified coordinator.
In the model I advocate, this role sits with the HR business partner, strategic partner to the business and to HR. They act in turn as investigator, gathering the elements and checking the frame, as project manager, following the request through, and as communicator of the result to the manager and, subject to internal rules, to the employee. The evaluator owns the methodology and recommends the level. Final approval rests with the appropriate governance body, according to the rules of the organisation. Payroll and HR systems are involved only when implementing the result requires it.
Does the request concern the function?
This is the first decision point, and sometimes the least investigated. The most frequent request is phrased like this: this function needs to be evaluated.
Before anything else, you have to establish what is actually being discussed. Is this about the function or about the person? Does the function exist? Has it changed, or is this an employee who has grown beyond the frame of their function, or whom the company wishes to reward?
These are different requests. They do not call for the same response. If the request concerns the development of the person without a demonstrated change in the function, it falls outside the evaluation process: it belongs to career, mobility, development, or to pay and its various components.
Framing the request within governance
When the request does concern a function, it needs framing: is it authorised under the internal rules? Has the creation of this function been approved, is it planned in the workforce planning, the budget, the organisational blueprint, or in a planned reorganisation?
Is the function permanent?
It is sometimes worth suspending the request until you are sure it complies with internal governance.
Building a job architecture takes considerable effort. What comes afterwards is rarely organised with the same care, and that is how levels drift, as I explained in “The life of levels”.
Yet once the career framework is in place, whatever method was used to build it, every request that comes in afterwards must first be read in the light of that architecture.
Requests are not all of the same nature, and that is the first thing to clarify.
The function exists and has not substantially changed. There is nothing to reassess. You need to confirm that it does match the reference function, then attach it, map it or slot it, depending on the terminology in use. That attachment confirms the level already assigned to the reference function. This positioning by comparison will be the subject of a later article in this series.
The function exists, but its content has changed. The comparison is not made against a similar function, it is made against the previously evaluated version of the same function. A reassessment is justified when the changes affect scope, impact, complexity, autonomy, accountability or working conditions.
The function is new. This is where the judgement is made, and it deserves to be estimated. In my practice, an overlap of around 70% with an existing function is a common reference point: below that, the function is probably distinct enough to warrant its own place in the architecture; above it, it is normally mapped across. This is not a standard, it is a rule of practice, and its value lies not in its precision but in forcing an explicit comparison. Where the function is genuinely new, a full analysis is warranted, and its result enriches the framework.
A whole career ladder is missing. This is no longer an evaluation request, it is an extension of the architecture. A career ladder is not added because one function steps outside its frame, it is added because a segment of the business has differentiated to the point where it no longer reads within the existing ladders. And that usually shows in the figures before it shows in the requests. Reading those indicators is part of the profession, and I devoted an entire article to it, “Numbers and human resources”. Extending a career ladder is not day-to-day management. The people involved are usually different, because it commits the business on another scale, and it is not decided on the same timeline. It is verified at several levels of analysis, from the overall view of every career ladder in the company down to the specific deployment within the department and its other ladders.
What information needs to be shared?
The full submission is only built once an evaluation or a reassessment is required. It rests on precise elements, and each has its owner.
Job descriptions do not always have a clearly defined owner in the organisation. Clarifying that ownership matters. Depending on the company, they sit with the manager or the business partner, and more rarely with the recruiters.
An org chart showing the function to be evaluated and the roles above it, below it and alongside it is usually held by the business or the transformation team.
The context of the request, growth, reorganisation, replacement, creation, is gathered by the business partner who supports that business and knows its challenges.
The relevant figures, where they exist, revenue linked to the activity, headcount supervised, volume of projects or files, budget managed, are held by the business, by finance or by the reference systems concerned, then collated by the business partner.
For a reassessment, add the previous evaluation, its rationale, and what has changed since.
The submission also identifies the version and date of the documents used, the comparable functions selected and the requested effective date. The information must be precise, current and comparable enough to allow a consistent and neutral application of the methodology.
Organising the sequence
A request moves through several stages: qualification, assembling the submission, evaluation or reassessment, consistency checks, approval, communication and, where necessary, updating the systems concerned.
The business brings field knowledge, the business partner coordinates the request, the evaluator owns the methodology and the appropriate governance body approves the result. The role of whoever accompanies the request is to move it between these owners, to challenge how the request was initially framed and to check compliance with internal rules.
That sequence is not rebuilt for every request. It is defined upstream, with the responsibilities, the approvals expected and the conditions for implementation.
The essentials
The quality of an evaluation is determined before the evaluation. It starts with qualifying the request: development of the person, attachment to an existing function, reassessment of a function that has changed, creation of a new function, or extension of the architecture. It continues with gathering the right information, assigning responsibility and organising the path to the decision and, where applicable, its implementation. That is what separates a governed evaluation from a simple classification.
This is the preparation and framing work the HDH (HR Decision Hub) platform helps to structure, so that every evaluation rests on a clear, comparable and traceable basis.