How to Manage a Web Development Project

Managing a web development project as a business buyer is not the same as being a project manager inside a software company. Your job is not to run daily stand-ups or assign tasks to developers. Your job is to make decisions the supplier cannot make, keep the project aligned with business goals, and verify that what gets built actually solves the problem you started with.

This means understanding where your responsibilities end and the supplier's begin. The supplier is responsible for technical delivery: architecture, code quality, testing their own work, and meeting the milestones you have both agreed. You are responsible for providing clear requirements, answering questions promptly, making scope decisions, testing against your real processes, and signing off deliverables. When either side blurs these boundaries, projects drift.

Who owns which decisions

The buyer's role across project phases

During discovery, your role is to explain the business problem, share existing processes, identify who will use the system, and describe what success looks like. The supplier's role is to ask the right questions, challenge assumptions, and translate your needs into a technical specification. If the supplier starts writing code without this step, the project is already at risk.

During the build phase, your role shifts to answering clarification questions quickly, reviewing intermediate deliverables such as designs or workflow prototypes, and tracking whether the project is still aligned with the original scope. You are not approving individual lines of code, but you are checking that a feature works the way your team expects it to.

During acceptance, your role is to test the system against the agreed criteria using your own data and your own people. This is where you confirm the system handles real scenarios, not just the tidy test cases the supplier prepared.

Why businesses struggle with this role

Many organisations treat a web application build the same way they treat an office refurbishment: write a brief, pick a supplier, wait for delivery. Software does not work like that. Features interact with each other, data has to be structured in specific ways, and users behave unpredictably. The more complex the system, the more decision points arise that only someone inside the business can resolve.

The practical consequence is that you need a named person inside your organisation who has the authority to make decisions about scope, data, and process changes. If that person is a committee, the project will slow down. If that person is unavailable, the supplier will make assumptions that may not match your intent.

Setting up the project before work starts

Before any development begins, agree on a written scope that describes what will be built, what will not be built, and what is deferred to a later phase. This does not need to be a hundred-page document, but it does need to be specific enough that both sides can point to it when a question arises about whether something is included.

Agree on milestones tied to tangible deliverables, not calendar dates alone. A milestone such as "user roles and permissions configured and testable" is verifiable. A milestone such as "phase two complete" is not. Each milestone should have acceptance criteria that you have reviewed and agreed before the build phase reaches that point.

Establish a change-control process upfront. Scope changes are normal in business software projects, but untracked scope changes are what cause budgets to double. The process does not need to be bureaucratic: even a shared spreadsheet logging the request, the estimated impact on cost and timeline, and your decision is sufficient for most projects.

Internal preparation

Identify every internal system that the new application needs to connect to, and confirm who controls access to those systems. If your CRM needs to pull data from your accounting software, the person who manages the accounting platform needs to be involved early. Discovering an integration blocker three weeks before launch is a common and avoidable problem.

Prepare sample data that reflects real complexity. Test data that contains three identical customer records will not reveal the problems that arise when you have duplicate records, missing fields, and historical entries in inconsistent formats. The quality of your testing depends directly on the realism of your data.

Decide who your internal testers will be and block their time in advance. The people who understand the current process best are usually the busiest. If they are not available to test, you will end up accepting work based on a surface-level review rather than a genuine test of whether the system supports the job.

Handling different build scenarios

When building a customer portal, the key management challenge is usually defining what customers can see and do at each stage of a workflow. Map out the customer journey before the build starts, including what happens when a customer submits incomplete information, disputes a charge, or needs to contact your team. These edge cases are where most portal projects reveal gaps.

When replacing a spreadsheet or legacy system, the key challenge is data migration and process fidelity. Your current system almost certainly contains workarounds, informal processes, and data that does not fit neat categories. The supplier can only migrate what you tell them about. If you do not audit the existing data and processes before the project starts, the new system will inherit old problems in a more expensive format.

When building an internal admin panel or CRM, the key challenge is agreeing on user roles and permissions before the interface is designed. If you leave permission decisions until after the build, you will face expensive rework because the interface was not structured to support the access levels you actually need.

Buyer behaviours that weaken delivery

• Abdicating responsibility to the supplier. Telling a supplier to "just build what we need" without active involvement almost always produces a system that technically works but does not fit the business. The supplier does not know your team's habits, your customers' expectations, or the informal shortcuts people rely on.
• Changing scope without tracking it. Adding "just one more feature" or "a small tweak" during the build phase is the single most common cause of budget overruns. Each change has a cost, even if the supplier does not raise an invoice immediately. Track every change, ask for the impact in writing, and decide consciously.
• Testing only the happy path. Walking through a process that works perfectly with clean data does not constitute acceptance testing. You need to test what happens when data is missing, when a user takes an unexpected step, and when two people try to do the same thing at the same time.
• Signing off without using real data. Accepting a system because it looks correct with dummy data is a frequent error. Always test with a subset of your actual data before agreeing the system is complete.
• Leaving user training until after launch. If the system changes how people work, training and documentation need to be part of the project plan, not an afterthought. Factor this into your timeline.

Limitations of the buyer's control

You cannot control the supplier's technical decisions in detail, and attempting to do so will slow the project without improving the outcome. What you can control is the inputs you provide, the criteria for acceptance, and the decisions about scope and priority. Focus your energy there.

You also cannot eliminate all risk. Software projects involve unknowns, particularly around integrations with third-party systems and data quality in existing sources. The aim is not a risk-free project but a project where risks are identified early, discussed openly, and factored into planning.

Controls to review throughout delivery

• Is the supplier asking questions, or just building? A supplier who does not ask clarifying questions during early phases is either making assumptions or not thinking deeply enough about your requirements.
• Can you see working software at each milestone? If milestones are described in documents rather than demonstrable software, you will not discover problems until late in the project. Insist on seeing testable functionality at each checkpoint.
• Are scope changes being logged and costed? If your supplier is making changes without documenting them, you have no way to understand why the project is over budget or delayed.
• Are your internal stakeholders still aligned? Requirements often shift as people see early versions of the software. Re-confirm priorities with your internal team at each milestone to avoid contradictory instructions to the supplier.
• Is the data migration plan specific? A vague statement such as "we will migrate your existing data" is not sufficient. You need to know which fields map to which, how exceptions are handled, and how you will verify the result.

Managing a web development project well comes down to three things: providing clear and timely inputs, making deliberate decisions about scope, and verifying results against your actual business context rather than against the supplier's test environment. The technical work belongs to the supplier. The business judgement belongs to you.

A weekly buyer control check

• What usable outcome has been completed and evidenced?
• Which decisions or information are blocking progress?
• Has scope, cost, timeline or risk changed?
• Which acceptance activity is due next?
• Are ownership, documentation and operational readiness keeping pace with the build?