Review a Job Description When the Work Has Changed

Recognise a genuine review trigger

A job description records a role’s purpose, responsibilities, requirements and authority. Job analysis gathers information about what the work actually requires. Job design organises tasks, responsibilities and their connections with other roles. Review therefore starts with understanding and organising the work before rewriting the document.

A review may be needed after a process redesign, a new service, repeated handover failures or a sustained workload change. A single exceptional request does not necessarily justify rewriting the role. Look for a pattern and explain why the current description no longer supports clear expectations.

CIPD describes job design in terms of roles and responsibilities and its relationship with job analysis. The job description overview covers the basic document. This article focuses on reviewing an existing role when practice has moved beyond that document.

Select a sample that reflects the work cycle

Define the period being reviewed and why it was selected. A role may appear lightly loaded during a quiet week but become busy at month-end or when a service launches. Collect examples from normal conditions and relevant peaks, and record periodic duties that did not occur during observation. Do not use a short period to represent an entire year without explaining its limits.

Ask the role holder to describe their outputs, approximate time requirements and recurring obstacles. Discuss those estimates with the manager and recipients of the work instead of turning the exercise into minute-by-minute surveillance. The aim is to understand role design and pressure points, not rank people using figures without context. Distinguish active work from time spent waiting for information or approval.

Examine interruptions too. An employee may stop planned work to answer questions that clear instructions could resolve. Adding those questions to the job description may institutionalise a process problem. First ask whether the need is genuine and recurring, who owns the information and whether rework can be reduced before assigning another duty.

Compare the document with actual work

Collect a representative sample of tasks, outputs, time demands and recurring interruptions. Discuss it with the employee, manager and roles that exchange work with them. Include periodic duties that a short observation window may miss. Avoid unnecessary monitoring or collection of personal information.

Separate the role’s requirements from the current employee’s personal strengths. A highly experienced person may absorb tasks informally that should not become an unexplained expectation for every future employee. Record where work comes from and which output the next person needs.

Find overlaps, gaps and competing priorities

For each important output, identify who performs the work, who approves it and who resolves exceptions. Look for two roles assuming the other owns a task, or two managers assigning incompatible priorities. Clarify the process before polishing the document.

In a hypothetical example for illustration, within a service team, a coordinator records requests while an account manager owns customer commitments. If the coordinator is also expected to promise delivery dates, the review must define authority and access to capacity information. Merely adding “manage customer expectations” does not resolve the decision boundary.

Decide what happens to each duty

Moving a duty on paper does not create capacity or competence elsewhere. Check workload, training, access and the effect on service before approving the change.

Test whether the proposed allocation is workable

After identifying duties, clarify priorities when demands conflict. If a coordinator receives an urgent sales request while handling an existing customer commitment, who decides which takes precedence? Define a clear route for that decision instead of leaving the employee to bear the consequences of conflicting expectations. Responsibility should be supported by the information, resources and authority needed to carry it out.

When transferring a task, check the receiving role’s training, system access and available time. Set a transition date and decide who will handle open work during the change. Test the handover on a realistic case before wider adoption and check that no essential step falls between teams. Redesigning a task or removing duplication may be preferable to lengthening another person’s duty list.

Discuss the change with neighbouring roles. One clear description is insufficient if another still contradicts it. Agree who owns the output, who approves it and which information passes between them. Keep detailed working rules in the relevant procedure and reference it where needed, avoiding several conflicting versions of the same requirements.

Write for outcomes and usable boundaries

Describe the role’s purpose, main outputs, responsibilities, reporting relationships and decision authority. Distinguish essential requirements from preferences and connect them to the work. Avoid vague demands such as being responsible for every issue in a broad department.

Keep the description stable enough to be useful without turning it into a detailed operating procedure. Link to controlled procedures where task steps change more often. If the change affects contractual terms, grading or other employment matters, use the applicable approval and consultation process rather than treating it as a wording exercise.

Implement the approved role and explain the transition

Discuss the approved description with affected employees and managers. Explain changed interfaces and provide the resources or training needed. Set a review point to check whether gaps, duplication and conflicting priorities have actually reduced. Retain the version and effective date.

Check the effect after implementation

Choose follow-up measures tied to the original problem, such as repeated requests for missing information or cases where the decision owner was unclear. Compare observations after implementation with earlier working conditions, allowing for changes in demand. Do not automatically attribute improvement to the revised document if the system or team size changed at the same time.

Ask the employee and manager to explain role boundaries using examples. If their interpretations differ, address the ambiguity and explain the agreed arrangement again. Record the review date, reason and approval owner, and define when operational changes should trigger another review. Follow-up keeps the description useful for allocating work rather than leaving it as a document that nobody consults.

Begin with a clear reason for review and evidence that represents the work. Resolve overlaps and test each role’s capacity before revising the description, implementing it and checking its effects. A written responsibility becomes workable only when authority, resources and clear handovers support it.

The Business and Operation Modelling service can connect responsibilities with the process they support. A useful job description reflects an agreed operating arrangement, not simply a longer list of duties.