How a typical IT project flows, phase by phase

Q: We are about to commission our first serious software build — what are the phases of an IT project, and what actually happens in each one from our side?

Most IT projects move through four phases, and knowing them up front tells you what you owe at each stage and what you should get back. First comes consultation: together we sharpen the concept, weigh realistic alternatives (build vs buy, native vs cross-platform, fully custom vs off-the-shelf), and you leave with an indicative estimate — a ballpark of cost, time and effort, good enough to decide whether and how to proceed, but not a signed-in-blood quote. Then specifications: we turn the concept into interactive mockups you can click through, and write the business logic in stakeholder language — rules, roles, edge cases and what-happens-when — so the people who actually run the process, not just the developers, can confirm it matches reality before a line of production code is written. Implementation follows in short sprints, each ending in something you can see and react to, so your feedback steers the build while change is still cheap; as it nears completion you run user acceptance testing (UAT) against the agreed specs and formally accept the result, while any new wish beyond the agreed scope is handled as a change request (CR) with its own estimate and sign-off. Finally operation: once live, the software is kept running under agreed service levels (SLAs) — uptime, response and fix times — and is scaled as your usage grows, so it keeps performing as more users, data and load arrive. Knowing this shape up front means fewer surprises: you always know which phase you are in, what decision it asks of you, and what you get out of it.

Question

QuestionWe are about to commission our first serious software build — what are the phases of an IT project, and what actually happens in each one from our side?

Accepted Answer

Most IT projects move through four phases. Knowing them up front tells you what you owe at each stage — and what you should get back:

1Consultation — we sharpen the concept and weigh realistic alternatives (build vs buy, native vs cross-platform, custom vs off-the-shelf), and you leave with an indicative estimate: a ballpark of cost, time and effort, enough to decide whether and how to proceed — not a binding quote.
2Specifications — the concept becomes interactive, click-through mockups plus the business logic written in stakeholder language (rules, roles, edge cases, what-happens-when), so the people who run the process can confirm it matches reality before any production code is written.
3Implementation — the build runs in short sprints, each ending in something you can see and react to, so your feedback steers it while change is still cheap. Near the end you run user acceptance testing (UAT) against the specs and formally accept, and anything beyond the agreed scope becomes a change request (CR) with its own estimate and sign-off.
4Operation — once live, the system runs under agreed service levels (SLAs) for uptime, response and fix times, and is scaled as usage grows so it keeps performing as more users, data and load arrive.

Knowing this shape up front means fewer surprises: you always know which phase you are in, what decision it asks of you, and what you should get out of it. The phases can overlap or repeat — but skipping one usually just pushes its cost further down the line.