Intake, capacity, and one source of truth

Context

Work reached the creative team from every direction: email, meetings, hallway asks, and a project tool only part of the team used. Nobody could say what was underway, what it would cost in people and days, or where a deliverable stood without asking three people, and the answer was often stale by the time it came back.

People agreed scope in conversation and remembered it differently later. Final files lived in personal drives. Schedule risk surfaced late, so stakeholders escalated by instinct rather than by information.

Intake and scoping

I built one intake. Every request came through a single form with the scope questions that change an estimate: audience, deliverables, channel, dependencies, and date. Nothing entered the pipeline without a brief, an owner, and a date, which moved most of the negotiation to the front, where it costs least.

I rewrote the brief templates, SLAs, and SOPs the new process depended on, and kept them current.

Capacity and prioritization

I ran a rolling view of committed hours across the campaign calendar, so I could make priority calls against real availability instead of optimism. When two campaigns wanted the same week, I brought marketing leadership the options and the cost of each, and we decided in the meeting rather than over three days of email.

I supervised a project manager and a coordinator, forecast capacity each week, and reallocated resourcing to protect launch dates through peak periods.

The system change

With marketing leadership I moved the brand team onto Asana for work management. I treated it as a change program, not a tool rollout: named the people affected, sequenced the cutover around campaigns already underway, retrained more than 25 users, and ran office hours until adoption held.

I owned the DAM: taxonomy, naming, rights and version rules, and an archiving step built into delivery, so the library stayed usable.

Where I put AI

I built agent-powered status and alert dashboards that assembled the weekly delivery picture and flagged work at risk. I reviewed the output before it went out. Stakeholders could see where programs stood, what was at risk, and what needed a decision, without waiting on a status report. That took most of the reporting work off the team.

Same principle as everywhere else: the system produces a draft and stops, and a person decides.

Retrospectives

I ran retrospectives on the campaigns that hurt and used delivery data to find where the time went, not where people assumed it went. That produced the turnaround number below.

Result

• Turnaround time dropped 20 percent, roughly 160 project-days returned across a year.
• One system carried the calendar, the work, and the assets, with documentation that stayed current as programs changed.