KEVOS · Templates & Examples · Project Templates
Workshop Task Register and Priority Workflow
A reusable workshop task register for engineering support jobs, including priority, readiness, assignment, due dates, actual hours and close-out.
Executive summary
The workshop-task workbook contains 186 nonblank task rows and manages small engineering/manufacturing jobs using priority, due dates, readiness checks for materials/drawings/CAD, assignment, status, actual hours and comments. Most historical jobs are complete, with a small number cancelled, in progress or not started. The reusable lesson is a simple demand-control system that prevents informal workshop requests from bypassing visibility and priority.
Why a workshop task register is different from a project schedule
A project schedule manages a defined project outcome and its dependencies. A workshop register manages a stream of short jobs from many requesters: prototype machining, gauges, jigs, rework, sample preparation, repairs and similar support work. Trying to put every small job into a full project plan creates excessive maintenance; handling them only by email or verbal request creates invisible queues and conflicting priorities.
The source register solves this with one row per job plus readiness, ownership and status fields. It also contains an instruction that jobs must be formally submitted to designated coordinators so the queue remains visible and can be prioritised. The names are confidential, but the control principle is reusable.
Recommended register fields
| Field | Why it matters |
|---|---|
| Task name | Concise description of the workshop deliverable. |
| Raised by / requesting role | Provides a contact for clarification and acceptance. |
| Project/reference ID | Links the job to a parent engineering project where applicable. |
| Priority | Creates a visible queue order. |
| Received date / due date | Shows demand age and requested need date. |
| Materials delivered | Prevents assignment before required stock/parts are available. |
| Drawing received | Confirms the shop has controlled dimensional information where required. |
| CAD model received | Confirms digital geometry availability where relevant. |
| Assigned to | Identifies current workshop owner. |
| Status | Not started, in progress, complete, cancelled or another controlled state. |
| Hours consumed | Supports capacity and estimating feedback. |
| Date completed | Enables throughput and lead-time analysis. |
| Comments / notes | Captures setup, rework, missing information or acceptance notes. |
Submission and triage workflow
Readiness states prevent false queues
The source separately records whether materials, drawings and CAD models have been received. This is more useful than a single “ready” flag because the missing prerequisite can be seen immediately. Some jobs legitimately mark a prerequisite as not applicable; others are waiting on one or more inputs.
A workshop should distinguish “not yet assigned because capacity is full” from “cannot start because the requester has not supplied the required information”. Without that distinction, workshop performance can appear poor even when much of the queue is not actually executable.
Priority rules
The source uses priorities 1 to 5, with priority 1 appearing most often. It does not contain a formal written definition of each number. Therefore, do not copy historical numeric meaning blindly. Define a local priority matrix.
| Priority factor | Questions to ask |
|---|---|
| Safety / production impact | Is production stopped, a safety control unavailable, or a critical quality containment required? |
| Project critical path | Does the job directly block a committed prototype, test, tooling or customer gate? |
| Due-date consequence | What happens if the requested date is missed? |
| Readiness | Is the job actually executable now? |
| Effort / fit | Can a short urgent job be completed without materially disrupting a higher-value task? |
| Requester escalation | Is the escalation authorised under the agreed priority rules rather than informal seniority? |
Actual hours as estimating feedback
The source includes “Hours Consumed” for some jobs. This is valuable because it closes the loop between requested work and real workshop effort. However, actual hours are incomplete in the historical data, so they should be used carefully.
For future use, record actual productive hours separately from calendar waiting where practical. Over time, similar job families—simple gauge modification, CNC sample, jig manufacture, rework—can provide estimating ranges. The goal is not to force every small task into exact standard hours, but to improve capacity planning and identify recurring work that may deserve a standard process or reusable fixture.
Workshop control metrics
Count of not-started/in-progress jobs whose prerequisites are available.
Jobs completed per week or month by type/priority.
Completion date minus received/ready date.
Completed on/before agreed due date ÷ completed jobs.
Hours consumed by job family, project or priority.
Jobs reopened or repeated because information or workmanship was inadequate.
Common failure modes
- Verbal bypass: a job is handed directly to a workshop employee and never enters the queue.
- False urgency: every requester labels the job top priority, making priority meaningless.
- Unready assignment: the job is allocated before material/drawing/CAD is available.
- Uncontrolled revision: the workshop uses an old drawing or model because the request does not identify the current information.
- No close-out: the physical job is returned but completion date, actual hours or comments are not updated.
- No project link: a prototype or test-support job cannot be traced back to the project it affects.
Related KEVOS templates
Establishing a fair and executable workshop queue
A workshop register only works if all requesters use the same intake path. The source explicitly reinforces formal submission so work remains visible and prioritised. Make the rule practical: the request should contain the deliverable, project/reference, requested date, priority reason and the readiness information needed to start. Urgent verbal work can still occur when necessary, but it should be entered immediately so the queue and actual workload remain truthful.
During triage, separate priority from readiness. A critical job with no material or drawing may be the highest business priority but still cannot be executed. Keep it visible as blocked and assign available capacity to the highest-priority ready job. This prevents staff from appearing idle or repeatedly switching tasks while waiting for inputs.
Daily or short-interval control
- Review newly submitted jobs for completeness and duplicate requests.
- Confirm blocked jobs and the person responsible for supplying each missing prerequisite.
- Allocate ready work according to the agreed priority rules and available skills/equipment.
- Update in-progress status when the physical work genuinely starts.
- Record actual hours and completion when the deliverable is returned or accepted.
- Escalate only genuine priority conflicts rather than allowing informal queue jumping.
Over time, use the register to distinguish demand problems from execution problems. A large blocked queue suggests poor request readiness; a large ready queue suggests insufficient capacity or prioritisation; repeated high actual hours for a job family may justify a standard fixture, process or outsourcing decision. These are management insights that cannot be obtained reliably from an informal verbal workshop queue.