Delivery became predictable once every request passed through one intake.

Requests reached design without the detail to scope them

The design team ran its work in Wrike, then moved to Jira. In both, a request could come from a product manager, or from a designer or team lead who wrote it up during or after a meeting. Nothing reviewed it on the way in. Team leads accepted work as it came and assigned it, and few requests carried enough detail to scope with confidence.

An audit of intake traced the change cycles to that gap. Scope that nobody defined at the start kept arriving while designers were already in the work. I wrote a delivery operating procedure that put one intake in front of the team: every request for design, from any partner, passed through review before anyone started work.

Every request got a first answer within two business days

A request had one job: decide whether design work was needed, define the deliverables and the timeline, and set its priority against the team's capacity. Product managers and every other delivery partner used the same request type, and the research team ran its own intake through it.

Review ran in three stages. Within two business days, the team lead made a first pass and decided whether to review the request now, park it with a review date, ask for missing information, or close it. A full assessment then defined the scope and the timeline: what would be created, what would be left out, how success would be judged, and the time, people and skills it needed. Last, the requester agreed to the scope, and the request became a project with one tracked item per deliverable.

Every closed request said why. Work design would not take on was closed with the reason written for the requester. Small help, such as approving a partner's solution or a quick mockup during office hours, was closed as done, with its time logged so it still counted against capacity.

Parked requests kept a review date, and stale ones were closed

Some requests were worth doing but not yet. A team without capacity, or a delivery date far enough out, sent a request to the backlog with a written reason and a date for the next review. The procedure was explicit about who owned that wait: if design held a request too long and the date slipped or quality suffered, that was design's to own.

Waiting time was put to use. A team lead could ask the partner to complete validation before review, such as the OKRs and KPIs behind a solution the partner had already chosen, with help from the research team where needed. A backlog item that had not changed priority in three to six months, with no new information and no one willing to sponsor it, was closed or explicitly recommitted.

Each missed date was traced to where it started

Predictability compared completed work with the delivery date set when the work was scoped. I reviewed the reason behind every slip and every change in scope. Splitting misses by where they started meant design stopped absorbing gaps that began upstream or downstream, and each partner could see where delays in its own work reached delivery.

A project stayed open until its feature reached customers

Jira's documentation defines an epic as a large body of work broken into smaller stories. That did not match how the company shipped, so I redefined it: one design epic for each product deliverable, holding every design deliverable it needed, and open until the feature was released to customers. Each design deliverable was its own story, with a due date and a review by its requester.

Keeping the project open past hand-off kept design's support through development and release planned and tracked, and late requests for open work came through the same project. A project closed only after the product manager and every reviewer confirmed each deliverable was complete, followed by a retro.

Partners came onto one intake standard when it improved their own delivery

The hardest part sat outside the design team. Each product group and delivery partner ran its operations differently and expected different things from design. Bringing them onto one intake standard took sustained time with product leaders and operations teams, and a case made from their own results: complete requests gave them more accurate scoping, fewer surprises at hand-off, and higher quality in what they delivered to customers.

Two pieces of the procedure were built for partners. A dashboard let each partner follow design's support on its own projects. When a partner's date meant design had to skip a deliverable, the agreed scope recorded what was skipped, why, and the risk, so the trade-off was visible before launch and the context was there when the next release was planned.

Assigning across the team spread knowledge through the whole system

With intake in place, work could be assigned across every designer, matched on four things: the skills the project needed, whether it would help someone grow, current workload, and who could deliver at the required standard. Designers had been siloed in the features and products of their own team's portfolio. Wider assignments gave them experience across the system, so knowledge of a product no longer sat with a few people, and a portfolio that suddenly needed more support could get it. Newer designers were paired with experienced ones on live work, which gave them room to grow their skills.

The procedure was maintained like a product

I owned the procedure, every workflow in it, and its documentation. It served three readers at once: designers who needed daily guidance, partners who needed visibility into their projects, and managers looking for performance data. Changes were versioned and announced, and anyone could flag something out of date.

The procedure prescribed information, not methodology: what has to be known before work starts, what has to be true before work moves forward, and what has to be documented before work is handed off. Those requirements hold whether a team runs sprints or waterfall. Only the cadence and ceremony around them change.