In this article (11 sections)
When you hire a software project, you're buying something you can't watch being made. There's no building site to walk through, no product to try first. There are meetings, a quote and, months later, a system.
That opacity is the source of almost all the distrust in this industry. This article opens it up: what happens inside, who does what, and what you should be seeing every week to know whether it's going well.
The stages, in order
1. Discovery
Before anyone writes code, someone has to understand how you operate. Interviews with the people who do the work, not only with the ones who supervise it. The answers differ, and the first one is the useful one.
Produces: a scope document with screens, business rules, roles and acceptance criteria.
Takes: one to three weeks for a small-company project.
What you have to see: that document, and you have to be able to read and understand it without help. If you don't understand it, don't approve it.
A provider who quotes a closed price without having done this is guessing. They'll either put a high number to cover themselves, or a low one to win the job and then argue every change as an extra.
2. Design
How the screens will look and how you move between them. On business systems it's usually a clickable prototype: screens you can navigate, with nothing running behind them.
What you have to see: that prototype, and try it yourself. Moving a button here is vastly cheaper than moving it later.
3. Build
The development itself, in one or two week cycles. At the end of each cycle there should be something working that you can touch.
What you have to see, every two weeks: the system running in a test environment, with what was built in that cycle. Not a presentation, not a completion percentage: the software.
If six weeks in you have never touched the system, something is wrong. It doesn't matter what the progress report says.
4. Testing
Two layers: the team's —ideally including automated tests— and yours, with real data and real cases.
What you have to do: name the people who will test and give them assigned time. Client testing is the part of the plan that gets underestimated the most and the one that delays deliveries the most.
5. Go live
Data migration, training and the switch. It's the stage with the most operational risk and the one worth planning in the most detail.
6. Warranty and maintenance
The bugs that show up with real use. Most of them surface in the first two or three months and then drop off sharply, which is why warranties tend to run three to six months.
Who does what
On a small team one person can cover several roles. What matters is that the functions exist.
- Tech lead. Decides how it gets built. This is the person you need to be able to talk to when something doesn't add up.
- Developers. Write the code.
- Product or UX design. Defines the screens and the flow.
- QA. Tests systematically. On small teams it tends to be spread around, and you notice when it isn't there.
- Project management. Coordinates, flags slippage, keeps scope under control.
- A counterpart on your side. This one isn't optional. Someone from your company with authority to decide and time assigned to it.
That last one is the role that most determines the outcome and the only one the provider can't cover. Projects that slip because of decisions pending on the client's side are the majority, and they get fixed by putting the right person on it with hours set aside.
How scope is controlled
This is conflict source number one.
New requests will come up during the project. That's normal and healthy: it means you're thinking about the system. The problem isn't asking for them, it's not recording them.
What should happen with each request: it gets written down, estimated, and decided among three options —it goes in and the date moves, it goes in and something else comes out, or it waits for a later stage—. All three are valid. The one that isn't: it goes in with nobody saying anything and shows up later as a delay with no cause.
If your provider doesn't have somewhere you can see change requests with their status, ask for one. It's the tool that prevents the most arguments.
The signs it's going well
- You touch the system every two weeks.
- Scope changes are written down with their impact.
- They tell you about problems when they appear, not when there's no room left.
- There's a named tech lead you can talk to.
- The code is in a repository you own from day one.
The signs it's going wrong
- Progress is reported in percentages and never as working software.
- Everything is "almost done" for several weeks in a row.
- The changes you ask for don't show up written anywhere.
- Every time you ask something technical, the answer goes through a middleman who doesn't understand the question.
- There's never any bad news. Every project has problems; the one who doesn't tell you is saving them up for you.
That last one is the most important on the list. A provider who warns you early about a problem is giving you the only thing that actually helps solve it: time.