Software Project Risks: What to Check Before Development Starts

01

Schedule and budget problems usually have an earlier cause

Imagine an established service business commissioning a customer portal. Customers will submit requests, upload evidence and track progress. Staff will review each case and send completed documents. The idea sounds clear enough to estimate, and everybody wants a delivery date.

The first risk register may list familiar concerns such as budget overrun, late delivery and technical failure. Those are real risks, but they are often consequences rather than causes. The delivery date becomes unreliable because an important workflow was never agreed. The budget moves because old data is harder to migrate than expected. The technology struggles because an integration was assumed to exist without anybody testing it.

Useful risk management starts before the plan turns red. It asks what is still uncertain, what would happen if an assumption is wrong and which small piece of evidence would reduce that uncertainty. The aim is not to predict every possible problem. It is to stop avoidable surprises controlling the project.

02

Risk 1: the business outcome is too vague

A project can have a detailed feature list and still lack a clear outcome. Build a portal, add document upload and create a dashboard are descriptions of software. They do not explain which operational problem the company expects the software to improve or how the people funding it will judge whether it worked.

For the customer portal, the outcome might be to reduce incomplete submissions and give customers a clear status without calling the office. That statement creates useful design questions. What makes a submission complete? Which statuses can a customer understand? When should a member of staff intervene? It also gives the team a way to reject features that do not help the first useful release.

Write the outcome in plain language before approving scope. Name the users, the change in their work and the evidence the business will look for. If the outcome cannot guide a difficult priority decision, it is too broad to control project risk.

03

Risk 2: the real requirements are hiding in daily work

A requirement such as staff can approve a case looks simple until somebody asks how approval actually works. One product may need two documents while another needs six. A missing photograph may create a query rather than a rejection. A senior reviewer may override one rule but not another. Those details often live in spreadsheets, email templates and the judgement of experienced staff rather than in the project brief.

If the team discovers these rules during development, each answer can change screens, permissions, notifications, data and tests. Calling every new detail scope creep is not helpful when the project never gave the business a proper chance to explain the work in the first place.

Walk through representative cases before building. Include an ordinary case, an awkward one, missing information and a hand-off between roles. Record the rule, who owns it and what should happen when the rule cannot be satisfied. A prototype can help when words alone keep hiding different interpretations.

04

Risk 3: data and integrations are treated as plumbing

The portal will not operate alone. It may need customer records from a CRM, documents from shared storage, invoice details from finance software and status updates from an older internal application. A box labelled integration on a diagram can hide access restrictions, incomplete documentation, rate limits, inconsistent identifiers and a supplier who has not agreed to the work.

Data migration carries similar risk. Ten years of spreadsheet records may contain duplicate customers, several date formats, missing values and columns whose meaning changed over time. Moving that information is not simply copying it into a new database. The business must decide what to keep, how to clean it and which old exceptions still matter.

Test the riskiest dependency early. Obtain access, inspect sample data and prove one representative exchange before building the whole journey around it. Decide what the system should do when the dependency is slow, unavailable or returns incomplete information. An integration that works only during a perfect demonstration is not yet a dependable part of the plan.

05

Risk 4: nobody owns the awkward decisions

Developers can make technical decisions, but they should not silently invent business policy. Somebody must decide who can view a case, when a customer may change submitted information, how long documents are retained and whether an unusual case can bypass the normal process.

Projects slow down when those decisions wait for a monthly meeting or move through several people who can comment but cannot approve. The team remains busy by building around the gap, then revisits the work after the decision arrives. Schedule risk grows even though everybody appears to be working.

Give the project one business owner with enough authority and time to make frequent decisions. Record which choices the delivery team may make, which need specialist input and which must be escalated. A named owner does not remove disagreement. It stops disagreement remaining unresolved inside the software.

06

Risk 5: visible features push quality work out of view

A progress demonstration naturally focuses on screens and completed journeys. The less visible work includes automated tests, error handling, logging, deployment, backups, maintainable code and the ability to restore the service after a failure. These are easy to postpone because they do not create an exciting new card on the board.

The problem appears near launch, when the application works in the happy path but the team cannot release it confidently or support it safely. Quality then looks like an unexpected cost even though live operation always depended on it.

Define the technical standard alongside the feature scope. Agree how changes are reviewed and tested, how environments are separated, how releases are made and what evidence is needed before a feature is complete. Small, regular releases make faults easier to isolate and give users a chance to correct the project before months of assumptions accumulate.

07

Risk 6: security and privacy arrive as a final review

Security is not a test that can be sprinkled over the portal before launch. The system may hold identity details, financial information, contracts or evidence that only specific people should see. Those facts affect the design from the beginning: what is collected, where it is stored, who can access it, how access is removed and what is recorded for audit.

Leaving those decisions late can force changes to the data model, permissions, hosting and user journey. It can also create an awkward choice between delaying launch and accepting a risk that the business never intended to carry.

Identify sensitive information and likely threats during discovery. Use the principle of least privilege, which means giving each person or system only the access it needs. Include security checks throughout development, protect repositories and deployment credentials, keep third-party components supported and plan how vulnerabilities will be handled after launch. Relevant legal and regulatory advice should come from the right specialist rather than being improvised inside a development meeting.

08

Risk 7: the business depends on one supplier or developer

A capable developer can move a project quickly, but speed becomes fragile when the business has no access to the repository, hosting, domain, deployment process or documentation. The risk is not only that somebody leaves. Illness, competing work, a commercial dispute or a supplier changing direction can all interrupt the application.

The customer portal should remain understandable and operable beyond one person. The business needs clear ownership of its accounts and data, more than one route to essential access, a recorded release process and enough documentation for another competent developer to assess the system.

This does not require a large team or a folder of documents nobody reads. It requires proportionate continuity. Check ownership and access at the start, keep them current during delivery and include a practical handover in the definition of done.

09

Risk 8: launch is treated as the end of the project

A portal creates value only when customers and staff can use it as part of real work. Launch risk includes training, support, importing live data, changing old routines, handling the first failures and deciding which process becomes the source of truth. If staff continue updating the spreadsheet as a safety net, the business may now have two incomplete versions of the same operation.

Plan the move into live use as carefully as the build. Decide who can answer user questions, monitor errors, correct data and approve urgent fixes. Test the release and recovery process. Use a controlled group or phased rollout when the operational consequence of a mistake is high.

The system will continue to change after launch. Ownership, maintenance, security updates, hosting costs and the next improvement therefore belong in the original decision. A project that funds creation but not operation has moved risk into the future rather than removed it.

10

Turn the risk register into decisions and evidence

A long risk register can become another document people update before a meeting. Keep it useful by writing risks as uncertain events with consequences. For example: if the finance system cannot return invoice status reliably, staff may need to check two systems and customers may see outdated information.

For each important risk, record an owner, the evidence currently available, the next action and the date by which a decision is needed. Choose a response: remove the cause, reduce the likelihood or impact, transfer part of the responsibility, accept the risk consciously or stop the affected part of the project. Review the highest risks whenever scope or a dependency changes.

Not every uncertainty deserves a workshop. A familiar feature inside an understood system may need only a short decision and sensible testing. Spend the most attention where a wrong assumption would be expensive to reverse, affect sensitive data or interrupt the business.

For the customer portal, the result should be a smaller set of visible risks and a delivery plan that tests them in a sensible order. If you are planning a new system or trying to rescue an uncertain software project, I can help clarify the operation, challenge the assumptions and turn the next phase into a decision the business can understand.