Why software projects run late, and how to scope one that does not 

Software projects run late when nobody speaks for your business in the room, when definitions are left for later, when scope changes aren't priced and when the first version tries to do everything. A scope that names your users, your data, the first release and what's out stops most of it before it starts.

The five reasons a four-month build reaches month fourteen

A software project is late when it takes longer than the plan you both agreed to, and I'd say the cause is rarely the code. It's mostly people, decisions and clarity. That's good news because you control a lot of it.

1. Nobody represents the business

Developers build what they're told and your brief is what they hear. If the person briefing them is busy or doesn't know how your work happens then they fill the gaps with guesses. You find those guesses weeks later as this is not how we do it, and each one is rework you pay for. Technology decisions made without anyone speaking for your business drift the same way.

2. Definitions are left for later

What counts as a customer, when is an order complete and which discount wins when two apply? These feel like small points at the start so you say let's decide that later, and later then arrives in the middle of the build when changing your answer means changing finished work.

A question that costs you ten minutes in week one can cost you days in month six.

3. Scope changes are not priced

Every project meets new ideas. Adding a field or a report feels free when you're chatting about it, but ten such additions aren't. If nobody writes down the effect on time and cost then your plan quietly grows while the date stays put, until the gap turns into an argument nobody enjoys.

4. The first release tries to do everything

A long list of features feels safer than a short one but it isn't, because it delays the moment your real users touch the software and that's when you learn what actually matters. Big first releases also have more parts that can go wrong at once and the final stretch drags on.

5. Feedback comes too late

If the first time your business sees working software is at the end then every mismatch arrives together. Regular demos of small working pieces keep your errors small. To my mind two months of silence is a warning sign, whoever is at fault.

What a usable scope contains

A scope is a short written agreement on what will be built for whom and what will not. It doesn't need to be long and for a small project two to four pages will often do, so here's what yours should hold -

1. The problem in one paragraph, stated as a task your people do today with who does it and how long it takes.
2. Your users by role and the main tasks each role must complete.
3. Your data, meaning what the system holds and where it comes from, who may change it and which of your other tools it must talk to.
4. The first release, which is the smallest version that lets your real users do one real job and what finished means for it.
5. What's out, meaning the features, reports, integrations and devices you won't get in the first release.
6. The people, meaning who decides for your business, who builds and how often you all meet.
7. Ownership and support, so who owns your code, accounts and data and who supports the system after go-live.
8. The way you handle change, which I cover below.

Write your out list with as much care as the in list, and I'd go further and say it matters more. When someone later asks for a feature that was out, you already have the answer on paper.

Why does we will decide that later cost the most?

Software is built in layers and the early ones like how data is stored and how users are identified hold up everything above them. A late decision that touches those layers means reopening finished work, while a decision you make in the first week touches nothing yet.

You don't have to decide everything at the start because some choices truly need real use first, and the skill is in sorting them. Ask yourself of each open point what must be redone if you get it wrong and how long that will take. If the answer is a lot then decide now, but if it's a screen or a label then you can leave it for later.

• Decide now on your core records and users, what must connect to what, what must be secure and who owns what.
• You can wait on colours and wording, the order of fields, extra reports and anything else that doesn't change the structure.

How to handle change without an argument

Change is normal and often good. You learn what you need by seeing the software. The aim is to make change visible and agreed rather than to ban it, and in my book a simple rule works well.

1. Any new request after sign-off gets written down in one or two sentences.
2. The builder sizes it and tells you its effect on time and cost.
3. Your named decision maker approves, defers or declines it in writing.
4. If it's approved then it's added to the plan and the dates are updated, and if it's deferred then it goes on your list for the next release instead of sneaking in.

This keeps both sides honest, because you see what each wish costs and the builder can't quietly absorb extra work and then run out of time at the very end. A good partner raises this rule at the start and not after your first dispute. Keep the written list of approved changes next to your contract and review it at every demo.

If you are already in month fourteen

A late project can often be saved. Blame helps nobody but a reset does, so here's how I'd go about it -

1. Pause new requests, yours included, and let nothing new in until the next step is done.
2. Take stock of what works today by running it, clicking through it and listing what a user can already do.
3. Pick the smallest set of work that gets users one real job done and make that your new first release.
4. Move everything else to a later list, even if it hurts.
5. Settle the open definitions in one working session with the person on your side who knows the answers.
6. Agree a new plan with short cycles, a demo at the end of each and a date you both believe.
7. Check ownership and make sure you hold the code, the accounts and the data whatever happens next.

If trust has broken down then an outside review of what's been built and what's left can help you both. A neutral person who understands your business and the technology can often turn a stuck project into a short list of decisions.

What can the business do to keep a project on time?

Builders aren't the only ones who affect the date and your side matters just as much. Here are the habits I'd put at the top of my list.

• Name one decision maker and give that person real hours each week, because replies within a day or two keep work moving.
• Supply sample data early, since real examples of your orders, forms and reports reveal rules nobody remembers to mention.
• Attend the demos, because short feedback every one or two weeks costs you far less than a big correction at the end.
• Keep a single list of requests, as ideas sent across chats and calls get lost and turn up again as complaints.
• Plan your staff's time for testing and training before go-live and not after.
• Tell your builder early when your priorities change, because they can adapt to a new priority but not to a surprise.

Your build partner should ask for these things at the start and tell you plainly when a delay on your side is moving the date. If they don't then ask them why not. You deserve a straight answer.

Frequently asked

I hope the short answers below help you!