Dedicated Project Management | Agile Delivery

Agile delivery management in the client's existing tools: Jira, Linear, Notion, or Asana depending on what the team already uses -- not a migration to a new tool as a precondition for getting started. Scrum for projects with defined feature sets: two-week sprints with sprint planning that produces a realistic commitment based on actual team velocity (measured from the previous 3 sprints, not estimated optimistically), a sprint goal that defines the purpose of the sprint in one sentence, and a sprint backlog with acceptance criteria specific enough that "done" is unambiguous. Kanban for support and maintenance work with WIP limits enforced so the team isn't context-switching across six in-progress items simultaneously. Backlog grooming sessions that turn business requirements into implementation-ready tickets: each ticket has a description of the user goal, acceptance criteria, edge cases to handle, and any technical notes from the engineering team. Velocity tracking produces a burndown chart that reflects reality rather than plan -- surfacing mid-sprint scope creep or underestimation before it becomes a missed sprint deadline. Daily standups kept to 15 minutes and focused on blockers rather than status reports that could be read from the tracking tool.

Jira-specific configuration: epic and story hierarchy aligned to the release roadmap (not a flat ticket list that makes progress invisible); custom issue types for bug, technical debt, and spike (time-boxed investigation task) so the backlog composition is visible to stakeholders; sprint velocity chart and cumulative flow diagram configured as the default dashboard rather than the default Jira view that shows every ticket in the system. Linear configuration: cycle time tracking per label; milestone tracking against a roadmap; GitHub integration for PR-to-ticket linkage so deployment status is visible on the ticket. Confluence or Notion for decision logs: every architectural or product decision documented with the decision, the options considered, the rationale, and the date -- so context is available to anyone who joins the project mid-flight without requiring a briefing from the PM.

Weekly written status update covering: what shipped in the current sprint (with links to the deployed features or the Jira/Linear sprint), what is planned for the next sprint, current blockers with owner and expected resolution date, decisions needed from stakeholders with context and deadline, and any changes to scope, timeline, or budget since the last update -- all on one page. The update is written in Notion, Confluence, or email depending on the client's preference, and sent by 09:00 Monday morning so stakeholders start the week informed rather than asking for a catch-up call. Reporting format chosen based on what the stakeholder needs: a technical team lead gets a different update than a non-technical founder or a client's executive sponsor, using the right level of abstraction for each audience rather than a one-size report that some recipients skim and others can't interpret. Escalation paths defined at project start: what kind of issue triggers an immediate notification (scope-breaking dependency, third-party integration blocked, delivery date at risk) vs. a weekly mention, who owns each type of decision, and what happens if a decision isn't made by the required date. Escalation cadence is critical -- a decision that has been waiting for two weeks is a delayed project. Risk register maintained throughout the project: identified risks, probability, impact, owner, and the mitigation or contingency plan for each -- reviewed in every sprint review so risk status reflects current project state rather than an initial assessment that was never updated. Honest status signals: a project that is on track gets a brief update; a project that has a problem gets a clear description of the problem, the impact on delivery, and the options for resolving it -- including the cost of each option in timeline or scope -- not a green dashboard with a buried footnote. Meeting minutes for any decision-making session with action items, owners, and deadlines sent before the close of business on the day of the meeting.

Scope documentation at project start: a written scope document defining what is in scope, what is explicitly out of scope (with enough specificity to resolve disputes), and the process for handling change requests. Change requests assessed for impact before being accepted: timeline impact, budget impact, and whether the change displaces something already committed. Written sign-off required before scope changes are incorporated -- not verbal agreements that get misremembered differently by the two parties. Change log maintained throughout the project so the final scope reflects the actual decisions made, not the initial estimate. Scope creep identification: requests framed as "small additions" assessed by the PM rather than absorbed by engineering, because individually small additions aggregate into significant overruns. Milestone gates with explicit go/no-go criteria before each phase: design complete, development complete, QA complete, launch ready. Each gate has defined acceptance criteria so "complete" means something specific rather than "mostly done." Budget tracking against the agreed scope shows cumulative hours or cost alongside the remaining budget, updated weekly rather than discovered at project close.

Risk identification starting in the discovery phase -- before development begins -- using a structured risk assessment that covers: technical risks (dependencies on third-party APIs with unreliable documentation, integration complexity with legacy systems, unfamiliar technology requiring team upskilling), resource risks (key person dependency, consultant availability windows, holiday blackout periods during critical phases), timeline risks (external dependencies outside the team's control: regulatory approvals, client content delivery, third-party integration timelines), and scope risks (requirements from stakeholders with a history of changing priorities mid-sprint). Each identified risk is assigned a probability (high/medium/low), impact (high/medium/low), owner responsible for monitoring it, and a mitigation plan (action to reduce probability) plus a contingency plan (action to execute if the risk materialises despite mitigation). Risk probability and impact reviewed each sprint so the register reflects current project reality rather than a pre-project assessment. Dependency mapping across the project: a directed dependency graph showing which features depend on other features being complete, which require external inputs (approved designs, third-party API credentials, content from the client, business decisions from stakeholders), and which items are on the critical path where a delay propagates to the project delivery date. Any external dependency without a confirmed delivery date becomes a tracked risk with an owner. Post-sprint retrospectives structured with three questions (what went well, what could improve, what is one specific action we will take next sprint) and action items assigned with owners and due dates -- reviewed at the start of the following retrospective to confirm they were completed, not discussed and forgotten.

Team health metrics tracked weekly: sprint commitment accuracy (story points committed vs completed -- consistently below 80% signals planning problem; consistently at 100% signals sandbagging); PR cycle time (time from PR opened to merged -- above 3 days signals review bottleneck or unclear ownership); bug escape rate (defects found in QA vs defects found in production -- rising production bugs signal QA coverage problems). These metrics are shared with the engineering lead weekly in a 10-minute sync, not saved for the quarterly retrospective after the problem has compounded. When a metric trend indicates a structural problem (velocity declining for 3 consecutive sprints), the PM produces a root cause analysis with specific remediation actions -- not a note in the retrospective that the team "needs to improve estimation."