Commissioning a web application, CRM system, customer portal or internal tool is a procurement and delivery exercise, not a creative brief. The business pays for an outcome, not for hours spent. Project management for business software is the discipline that connects what the organisation needs with what a development team builds, and it sits between requirements, contracts, testing and deployment. This guide covers the mechanics that business owners, operations managers and buyers actually control.
Requirements and Discovery
Most failed software projects fail before a single line of code is written. The root cause is almost always an incomplete or ambiguous understanding of what the system must do, for whom, and under what conditions. Discovery is the structured process of closing that gap before budget is committed to production.
How to Gather Business Software Requirements
Start with the processes the software must support, not with screens or features. Walk through each workflow from trigger to completion: who initiates it, what data they provide, what decisions the system makes, what outputs are produced and who receives them. Record every branch, exception and error condition. If a process has not been mapped before the project starts, the development team will invent one, and it will not match your operations.
How to Run a Discovery Workshop for a Web Application
A discovery workshop brings together business stakeholders, operational staff and the development team in a structured session. The format matters more than the duration. Prepare a process map in advance, even a rough one, so the workshop refines detail rather than starting from a blank sheet. Assign a facilitator whose job is to ask clarifying questions, not to defend a preferred solution. Document decisions in real time and circulate the output within 48 hours for confirmation.
How to Prioritise Software Features
Not everything identified during discovery should be built in the first release. Prioritisation forces the business to distinguish between what is essential for the system to be usable and what is desirable but can wait. A common framework asks whether each feature is required for launch, needed soon after, or a future improvement. The critical test is: if this feature were missing, could the system still go live and deliver value?
How to Write a Software Brief
A brief should describe the problem, the users, the processes, the integrations and the constraints. It does not need to specify technical architecture, but it does need to specify what the system must connect to, what data it will hold, who is allowed to see or change that data, and what the acceptance conditions are. Vague briefs produce vague estimates, and vague estimates produce disputes.
How to Handle Changing Requirements Mid-Project
Requirements will change. The question is whether those changes are managed or absorbed silently. A change-control process does not need to be bureaucratic, but it does need to exist. Every change request should be recorded with its impact on scope, timeline and cost before it is approved. If the contract is fixed-scope, changes require a formal variation. If the contract is time-and-materials or agile, changes are accommodated by reprioritising the backlog, which means something else moves down or drops out. There is no scenario where changes are free.
Estimates and Budgets
An estimate is a forecast based on incomplete information. Treating it as a guarantee is the single most common mistake in business software procurement. Understanding how estimates are produced, and what makes them inaccurate, is essential before you sign anything.
How Web Application Estimates Are Calculated
Most development estimates break the required work into tasks, assign an effort value to each and apply a rate. The accuracy of the estimate depends almost entirely on the detail of the requirements. A figure based on a one-page brief will have a wide margin of error. A figure based on a fully specified set of user stories, acceptance criteria and integration points will be narrower, but it will still be an estimate.
Why Software Estimates Are Often Wrong
Software is not construction. The components are not standard, the interactions between them are not fully predictable, and the requirements themselves evolve as stakeholders see early versions. Estimates also deteriorate as project size increases because the number of possible interactions grows non-linearly. A project twice as large is more than twice as hard to estimate.
How to Compare Quotes from Different Developers
Comparing quotes is only meaningful if the scope is identical. If three suppliers have been given different briefs or have interpreted the same brief differently, the price comparison is meaningless. Before comparing numbers, compare what each quote includes and excludes, what assumptions each supplier has made, and what level of detail each has worked to. A lower quote that assumes a simpler integration or omits testing is not cheaper; it is incomplete.
Fixed Scope vs Agile Budgeting
Fixed-scope contracts fix the deliverables and the price, with change handled through variations. Agile contracts fix the team or the time and allow the scope to evolve within those constraints. Neither model eliminates risk. Fixed-scope contracts create pressure to argue about whether something was in scope. Agile contracts create pressure to demonstrate that the right things were delivered within the budget. The choice depends on how certain you are about requirements and how much flexibility you need.
How to Phase a Large Project to Manage Budget
Phasing breaks a large system into releases that each deliver usable value. The first phase might cover core workflow and a single integration. Subsequent phases add reporting, additional integrations or advanced permissions. Phasing reduces upfront risk, provides earlier feedback and allows the business to redirect budget if priorities shift. The trade-off is that some architectural decisions made in phase one may need revision in later phases, which carries its own cost.
Contracts and Legal
The contract governs what happens when things go wrong, not just when they go right. For business-critical systems, the contract is as important as the code.
What to Include in a Web Development Contract
At minimum, a software development contract should define the deliverables, the acceptance process, the payment schedule, the ownership of intellectual property, the support obligations after delivery, the liability limits, the termination rights and the dispute resolution mechanism. Each of these terms has practical consequences. A contract that is silent on acceptance criteria, for example, leaves the sign-off process undefined, which is how projects stall at the final stage.
Intellectual Property Terms in Software Contracts
Intellectual property in a software project covers the source code, the design assets, the documentation and any pre-existing components or libraries the supplier uses. The key question is whether the business receives full ownership of the custom code or a licence to use it. Full ownership is standard for bespoke work but may not apply to frameworks or modules the supplier reuses across clients. Clarify this distinction before signing. If the supplier retains ownership of core components, the business may face difficulty engaging a different supplier to maintain or extend the system later.
Data Protection Clauses in Software Contracts
If the system processes personal data, the contract must address the respective roles of the business and the supplier under UK data protection law. The business is typically the data controller and the supplier the data processor, which imposes specific obligations on the supplier regarding data handling, security measures, sub-processor engagement and breach notification. These clauses should be reviewed by someone with current knowledge of UK data protection requirements, as the regulatory landscape changes.
Termination Clauses and Exit Rights
Termination clauses define how either party can end the contract and what happens next. For the business, the critical exit rights are: access to the source code, access to the data, handover of any third-party credentials or licences, and cooperation during a transition to a new supplier. If these rights are not in the contract, extracting them later can be difficult and expensive. Exit planning should begin when the contract is drafted, not when the relationship breaks down.
Testing and Quality Assurance
Testing is not a phase that happens at the end. It is a set of activities that run alongside development, and the business has specific responsibilities within it that cannot be delegated entirely to the supplier.
How to Test Business Software
Testing business software means verifying that the system supports the real processes it was built for, not just that it does not crash. This requires test scenarios derived from the actual workflows documented during discovery. Each scenario should specify the starting conditions, the actions taken, the expected outcome and the data that should be created or changed. Generic testing that clicks through screens without following a process will miss the defects that matter most to the business.
What Is User Acceptance Testing?
User acceptance testing (UAT) is the stage where the business, or its nominated end users, verify that the system meets their requirements before it is accepted. UAT is not a second round of development. It is a structured pass through pre-defined test cases using data that reflects real operating conditions. If UAT fails, the defects are documented, prioritised and resolved before retesting. UAT should have a clear completion criterion: a defined number of critical and major defects at zero, for example.
How to Write Acceptance Criteria
Acceptance criteria are the conditions that must be met for a piece of work to be considered complete. They should be specific, testable and written in terms of observable behaviour. A criterion such as "the system should be fast" is untestable. A criterion such as "the dashboard loads within three seconds when displaying up to 500 records" is testable. Every user story or requirement should have acceptance criteria attached before development begins, not after.
Testing Environments: Staging vs Production
A staging environment is a replica of the production environment where the business can test the system before it goes live. Staging should use the same server configuration, the same integrations and, as far as possible, the same data volumes as production. Testing in a staging environment that differs significantly from production will not reveal environment-specific defects. The business should confirm that a staging environment exists, that it is kept in sync with production, and that it is available for UAT before each release.
How to Manage Bug Reports and Fix Requests
Bug reports should be recorded in a shared tracking system, not sent by email. Each report should include the steps to reproduce the issue, the expected result, the actual result and the severity. Severity should be defined in advance: critical means the system is unusable, major means a core process cannot be completed, minor means a workaround exists. This classification determines the fix priority and prevents minor cosmetic issues from blocking a release while critical defects wait.
Acceptance and Project Sign-Off
Acceptance is the point at which the business confirms that the delivered system meets the agreed requirements. It triggers the final payment, the start of any warranty or defect liability period and the transfer to operational support. Getting sign-off wrong creates limbo: the supplier considers the project complete, the business considers it unfinished, and neither party has a clear mechanism to resolve the gap.
How to Manage Software Project Sign-Off
Sign-off should be a formal, documented process tied to the acceptance criteria agreed at the start of the project. If the criteria are met, sign-off follows. If they are not met, the specific shortfalls are listed, and the supplier resolves them before sign-off is granted. The common mistake is to begin using the system in production while withholding formal sign-off over minor issues. This creates ambiguity about whether the project is in warranty, in support or still in development.
Defect Liability Periods Explained
A defect liability period is a fixed window after acceptance during which the supplier is obliged to fix defects at no additional cost. The contract should define the length of this period, what counts as a defect as opposed to a change request, the response times for different severity levels and what happens if a defect cannot be resolved. Without these definitions, the defect liability period becomes a source of disagreement rather than a safety net.
Post-Launch Support Handover
The transition from project delivery to ongoing support should be planned before go-live. Handover covers: transfer of administrative access, documentation of the deployed environment, introduction to the support team or process, confirmation of the support SLA terms and agreement on how new requests will be handled. If the development team and the support team are different, the handover is particularly important because knowledge gaps between the two will directly affect response times.
Supplier Management
Managing a software supplier is not the same as managing an internal team. The relationship is governed by a contract, the work is often remote, and the business depends on the supplier's competence in areas it cannot directly observe. Active management narrows the information gap.
How to Manage a Web Development Project
Effective management starts with clear expectations set at the outset: how often the business will receive updates, in what format, who the point of contact is on each side and how decisions will be made. A single point of contact on the business side reduces conflicting instructions. Regular status updates, even brief ones, prevent surprises. The goal is not to micromanage the development process but to ensure that the project is tracking towards the right outcome and that problems are surfaced early.
Communication Expectations with Software Suppliers
Agree the communication cadence before the project starts. Weekly written status updates and fortnightly video calls are a common baseline for mid-sized projects. Larger projects may need daily stand-ups during critical phases. The format matters less than the consistency. If the supplier goes silent for two weeks, the project is likely off track regardless of what the last update said.
When to Change Development Suppliers Mid-Project
Changing suppliers during a project is disruptive and expensive, but it is sometimes less risky than continuing with a failing relationship. The triggers are persistent missed deadlines, unexplained budget consumption, refusal to provide access to code or environments, and a pattern of unresolved defects. Before making the change, ensure the contract gives you the right to terminate, that you can obtain the source code and data, and that you have a realistic plan for onboarding a new team. Exiting without these preparations can leave the business with an incomplete system and no way to continue.
Managing Multiple Software Suppliers
When a project involves more than one supplier, for example a development team and a separate integration specialist, the business must manage the interfaces between them. This means defining clearly which supplier owns which part of the system, how data will flow across the boundary, who is responsible when an integration fails and how joint testing will be coordinated. Without this clarity, each supplier will assume the other is handling the gaps.
Development Methodologies Explained
Development methodology is the framework the supplier uses to organise their work. It affects how requirements are captured, how progress is measured, how changes are handled and how the business participates. The methodology is not a technical detail; it directly affects the commercial relationship.
Waterfall vs Agile: What Business Owners Should Understand
Waterfall proceeds through sequential phases: requirements, design, development, testing and deployment. Each phase completes before the next begins. Agile delivers work in short iterations, with each iteration producing a potentially usable increment of the software. Waterfall provides predictability when requirements are stable and well understood. Agile provides adaptability when requirements are likely to evolve. The practical difference for the business is when decisions are locked in and when changes become expensive.
Scrum vs Kanban for Software Projects
Scrum organises work into fixed-length iterations called sprints, typically two to four weeks, with a planned set of work committed at the start of each sprint. Kanban manages work as a continuous flow, with limits on how many items can be in progress at once. Scrum provides regular delivery cadence and predictable review points. Kanban provides flexibility when the type and urgency of work varies. For most business software projects, the choice between them is less important than having a clear process for prioritising and reviewing work.
How Sprints and Iterations Work in Practice
At the start of a sprint, the business and the development team agree which items from the prioritised backlog will be delivered. During the sprint, the team works on those items without adding new ones. At the end, the team demonstrates what has been completed, and the business provides feedback. Items that are not finished are returned to the backlog for reprioritisation. This cycle gives the business regular visibility of progress and regular opportunities to adjust direction.
When Agile Is Not the Right Approach
Aggressive agile is not appropriate when the system must meet a fixed regulatory requirement with no room for interpretation, when the output must be certified against a specific standard, or when the business cannot commit to regular stakeholder availability for reviews and prioritisation. In these situations, a more structured approach with formal sign-off gates may be lower risk. The methodology should serve the project, not the other way around.
Environments and Deployment
Deployment is the process of moving software from a development state to a live, operational state. It is a technical activity with direct business consequences: a failed deployment can take a system offline, corrupt data or break integrations. The business does not need to perform deployments, but it does need to understand the environment structure and the deployment safeguards.
Development vs Staging vs Production Environments
Development environments are where individual developers write and test code. Staging environments mirror the production setup and are used for integrated testing and business acceptance. Production is the live system used by real users. Code should move through these environments in sequence: developed, tested in staging, accepted by the business, then deployed to production. Skipping staging or deploying directly from a developer's machine to production is a risk the business should not accept.
How to Plan a Go-Live for a Web Application
Go-live planning covers the deployment itself, data migration, user access provisioning, integration testing with live external systems, rollback procedures and the initial support period. The plan should specify who is available during the go-live window, how long the deployment is expected to take, what the failure indicators are and at what point the decision to roll back is triggered. A go-live that is not planned as a controlled event becomes an uncontrolled one.
What Is CI/CD and Why Does It Matter?
Continuous integration and continuous deployment (CI/CD) is the practice of automating the build, testing and deployment of code changes. When CI/CD is in place, code changes are tested automatically each time they are submitted, and deployment to staging or production follows a defined automated pipeline. For the business, CI/CD reduces the risk of human error during deployment, speeds up the release cycle and makes rollbacks more reliable. It is not essential for a small internal tool, but for any system that will be updated regularly, it is a meaningful quality and safety measure.
Rollback Planning for Web Application Releases
Record the decision and the owner
Every deployment should have a rollback plan: a defined procedure for reverting to the previous version if the release causes critical problems. The plan should cover reverting the code, reverting any database schema changes and restoring any data that was modified during the failed deployment. Rollback should be tested before it is needed. A rollback plan that has never been rehearsed is a plan that may not work when the system is down and the pressure is on.