To rescue a delayed website project, review working pages and open issues together. Separate broken forms, missing content and integration failures from design preferences that can follow later. Set a new date after understanding the order of dependent tasks; another deadline alone will not solve the delay.
Show what is actually complete
“Ninety per cent complete” can hide a substantial amount of remaining work. List page types, content, forms and integrations. Distinguish work that can be demonstrated, has been approved, has been implemented and has been checked. A designed screen is not necessarily ready to launch with real content.
Confirm access to the current files, accounts and working environment. Everyone should assess the same version. Consolidate scattered feedback into an open-issues list and distinguish missing work from comments reopening an agreed decision. This gives the existing or incoming team a basis for planning beyond guesswork.
Write down why each task is waiting
State why a task is waiting: missing product data, unavailable payment-provider access, conflicting design approvals or an unresolved development issue. APM's planning framework considers activity dependencies and resources when managing schedules. Apply that principle by giving each blocked task a next action and an owner.
Imagine a hypothetical project in which unapproved service copy is holding up the launch. The team can identify which pages are essential for the first release and which verified content is ready. This does not justify publishing inaccurate information. It makes the scope decision explicit and places it with the person authorised to make it.
Separate launch blockers from improvements
Review essential first-release work alongside preferences that can follow. A broken enquiry form and a second animation variation do not carry the same weight. Make the distinction against the business objective rather than allowing teams to select only convenient tasks.
| Open issue | Decision criterion | Treatment |
|---|---|---|
| Core journey fails | Can the visitor complete the task? | Resolve and verify before launch. |
| Information is missing or wrong | Is the decision information accurate? | Assign a content owner and approval. |
| Design preference is unresolved | Is an agreed direction available? | Resolve through one decision owner. |
| A new feature is requested | Is it essential to the first release? | Assess scope and schedule effects. |
| A later improvement remains | Does it prevent basic use? | Place it in an owned follow-up list. |
Build the new schedule around dependencies
Illustrative sequence: final service-page layout depends on approved copy; the CRM connection depends on agreed form fields; an end-to-end enquiry test depends on the connection working. Instead of assigning all three the same date, list the input each task needs. Do not hide missing inputs inside the schedule.
Describe the delivery as a working result rather than a file name. Replace “quote form complete” with “a mobile submission creates one record for the correct team”. If a task still needs access from an external provider, show that condition alongside the proposed date.
- Separate work that can proceed with inputs already available.
- Show dependencies between content, design, development and testing.
- Define every critical delivery with a runnable scenario.
- Keep pre-launch fixes separate from post-launch improvements.
- Assess the effect of new requests on the end date.