Ticket triage: deciding what gets answered first
Triage sorts incoming requests by urgency and owner before anybody starts work. How to set priorities that hold, who should do it, and why first-in-first-out fails.
Scope creep is rarely one big change. It is twenty small favours, none worth an argument, that together consume the margin and the timeline.
Scope creep is the gradual expansion of a project beyond what was agreed, without a corresponding change to the timeline, budget or team. The word suggests something happening to you, which is part of why it persists — in practice it is a series of small decisions, each individually reasonable, that nobody recorded as a decision.
It almost never arrives as a request for something large. It arrives as "while you're in there, could you also…", as a stakeholder who was not consulted appearing in week six, and as a deliverable that was described vaguely enough that the client's reading is larger than yours.
The most common source is not the client. It is the individual contributor who agrees to a twenty-minute favour twenty times, because each refusal would seem petty and nobody has told them that logging it is not the same as refusing it. Give people a way to say "yes, and I'll log it as a change" — that sentence solves most of the problem, and it needs to be explicitly sanctioned by whoever manages the relationship.
Refusing everything is not scope management; it is a way of being unpleasant to work with, and clients remember it. Small accommodations build the relationship, and the goodwill is real. What matters is that they are recorded as accommodations rather than absorbed silently, so that when the timeline slips the conversation is about a documented list rather than a feeling. A supplier who can show fourteen logged extras delivered at no charge is in a strong position; one who says "we did lots of extra work" is not.
Ettex Board makes the accumulation visible: columns and cards with drag-and-drop, a label for anything outside the original scope so a filter shows the whole list at once, assignees so requests are not absorbed silently by whoever was asked, due dates, checklists inside cards, and WIP limits that make the cost of extra work visible in flow rather than in a spreadsheet. Every move and edit is logged per card. The agreed scope lives in Ettex Docs with version history, incoming requests arrive through Ettex Forms rather than by message, and the cumulative impact on time and money is easiest to show from Ettex Sheets at the status meeting.
Said plainly: Ettex has no project-management engine. There is no baseline versus actual tracking, no earned value, no critical path, no automatic variance reporting and no scope-change workflow. A label on a card and a logged request are conventions you maintain. That is enough for a small team; formal change control across a programme wants dedicated PM software.
The gradual expansion of a project beyond what was agreed, without matching changes to timeline, budget or resources — usually through many small unrecorded additions.
Vague scope, missing acceptance criteria, requests made directly to individuals, late-appearing stakeholders, false assumptions, and a change process slower than simply doing the work.
Log everything and price the accumulation, not each item. Small accommodations are often worth granting — what matters is that they are recorded as accommodations rather than absorbed silently.
No. Discovery sometimes shows the original plan was wrong, and adapting is correct. The failure is doing so without re-planning the timeline and budget.
A change request is a decision made visibly, with an impact assessment. Scope creep is the same expansion happening without anyone deciding.
Most often the supplier's own team, agreeing to small favours individually. Giving people permission to say "yes, and I'll log it" removes most of the problem.
Scope creep is unrecorded decisions. Write the exclusions, give deliverables acceptance criteria, route requests through one channel, and log every yes — then price the accumulation rather than arguing about half-days.
Triage sorts incoming requests by urgency and owner before anybody starts work. How to set priorities that hold, who should do it, and why first-in-first-out fails.
A milestone marks a verifiable completion, not a point in the calendar. How to choose them, how many to have, and why percentage-complete reporting replaced them badly.
The critical path is the sequence that sets the end date. How to find it without software, why most status reports chase the wrong tasks, and what float really means.