Good web project management starts with clear priorities, an accountable client lead and a shared understanding of the deliverables. Tools help, but budgets and deadlines depend on timely decisions, visible dependencies and controlled changes. We recommend a straightforward approach that reviews both progress and the cost of remaining work every week.
Define the deliverables before setting the deadline
A brief that simply says “new website” leaves too many questions unanswered. Before approving a budget and schedule, the client and agency should agree on:
- The goal: the business problem the website should solve, such as making quotation requests easier.
- The scope: the page types, languages, features and integrations included.
- The exclusions: what will explicitly wait until a later phase.
- Acceptance criteria: what you will check before considering the work complete.
Make requirements testable. “A working contact form” is less useful than specifying that the form must work on mobile, send enquiries to the correct recipient and display a confirmation.
Appoint a client lead with authority to prioritise and approve work. Several stakeholders can contribute, but the agency needs consolidated feedback and clear decisions.
Combine an overall plan with short delivery cycles
For many small and medium-sized web projects, we recommend an overall plan with clear approval points, supported by short delivery cycles. Review completed sections regularly rather than waiting for one large presentation near the end.
A simple Kanban board may be enough. This is a shared task board where work moves through stages such as planned, in progress, under review and complete. Limit the number of tasks underway so that work gets finished, not just started.
Match the contract to the uncertainty
Fixed pricing works best when deliverables are clearly defined. Time-based billing allows more flexibility but needs closer cost monitoring. If important requirements remain uncertain, a separate discovery phase can provide a better basis for commissioning the full project.
Agree what can change if time or money becomes tight. A fixed launch date often means allowing lower-priority features to move to a later release.
Schedule client work and external dependencies
A web development schedule must cover more than the agency’s work. Copy, images, product information, access permissions and internal approvals also need owners and delivery dates.
Identify tasks that block others. Missing product information can delay an online store’s import and review, even when the design is finished. If a software supplier needs to provide access, that must happen before the integration can be verified.
We recommend that you:
- book client review sessions at the start of the project,
- investigate uncertain integrations and data quality early,
- place contingency time around identified risks,
- revise the schedule when an important assumption changes.
A time buffer only helps if it comes before the milestone it needs to protect. Extra time after a fixed campaign date cannot prevent a late launch.
Use a small set of tools with clear purposes
The best project management tool is one that both client and agency actually use. Start with existing tools and avoid maintaining the same information in several places.
| Need | Example tools | Shared working rule |
|---|---|---|
| Tasks and progress | Trello, Asana or Microsoft Planner | Each task has an owner, a status and a date where needed. |
| Documents and decisions | SharePoint, Google Docs or Notion | Approved versions and the latest decisions must be easy to find. |
| Budget and forecasts | Excel or Google Sheets | Review actual spending alongside the estimated remaining work. |
| Time tracking | Toggl Track or Harvest | Assign time to work areas so that overruns can be explained. |
These are examples, not a shopping list. Check access permissions and contractual terms before sharing personal data. Keep passwords and other sensitive credentials out of ordinary project cards.
Decisions made in meetings or email should be recorded in the shared project documentation.
Track the forecast, not just the money spent
Spending half the budget does not mean the project is halfway finished. The most difficult work may still be ahead.
Recalculate the expected final cost
For time-based work, reporting should show the cost incurred plus a current estimate of the remaining work. Reassess that remaining work rather than simply subtracting invoices from the original budget.
Ask the agency to explain variances by work area. If a product import takes longer than expected, you need to understand why and what options exist: simplify the import, improve the source data or reprioritise other work.
Fixed-price projects still need oversight of costs outside the agreed scope. Separate the project delivery, approved additions, licences and ongoing running costs. Check that project management, content work, testing and training are included in the overall budget.
Agree that a forecast above the approved budget triggers a decision, rather than merely appearing in a report. A spending limit also needs a clear rule for pausing work while further approval is pending.
Approve changes before work begins
New requests are normal in web projects. Problems arise when they are implemented without anyone considering the consequences.
Document each substantial change with its purpose, estimated cost, schedule impact and approver. Distinguish new requests from defects against agreed requirements. Defects should be handled under the contract, not automatically treated as additional scope.
A typical example is adding another language after the design has been approved. This affects more than translation: it also adds content work, navigation requirements and testing. The decision is then whether to increase the budget, move the launch date or postpone something else.
Keep status meetings focused on decisions
A weekly status meeting should help people act, not repeat the entire task board. Review:
- what has been delivered and accepted,
- the forecast final cost and launch date,
- blockers, risks and decisions needed,
- who will do what before the next review.
Record decisions and give every action an owner and a due date. If a delayed deliverable threatens the launch, raise it immediately rather than waiting for the next scheduled meeting.
Plan testing and handover from the start
Testing is part of delivery, not an optional activity after development is complete. Allow time for client review, corrections and another round of checks.
Test real business journeys. For a company website, that might mean submitting an enquiry. For an online store, it could include purchasing, payment confirmation, shipping selection and refunds. When replacing an existing website, check old links and redirects too.
Before launch, agree who authorises the release, which defects must be resolved and how a failed launch would be handled. Handover should also cover training, access permissions and responsibility for ongoing operations and support.
Our recommendation: start with one shared project brief
Before production begins, bring the goals, scope, responsibilities, budget, milestones and acceptance criteria together on one shared page. Add a task board and a weekly cost forecast. This gives everyone a practical basis for decisions without unnecessary administration.
If you need help defining and planning your next website or online store, discuss the project approach with us.