, updated · 3 min read
Starting a project the right way
What the first two weeks of a project should produce, so you avoid the expensive mistake of carefully building the wrong thing.
Most Projects Go Wrong Before Any Code Is Written
The expensive problems in software rarely come from bad code. They come from building the wrong thing carefully: requirements that were misunderstood, priorities nobody agreed on, an assumption that went unexamined until it was structural.
The first two weeks decide more than the following six months, which is an uncomfortable amount of weight to put on a period when everyone is still being polite with each other.
Start With The Problem, Not The Request
When someone arrives with "we need a dashboard" or "we need an app", the useful first question is what problem that solves. Sometimes the answer confirms the request exactly. Often it reveals the request was one possible solution to something that has a cheaper one.
This is not a delaying tactic. It takes a conversation, and it regularly saves weeks of building something that was never going to help.
Agree What Done Looks Like
Before anything is built, agree what a successful first version contains. Not a wish list, but a focused set of capabilities that solve the core problem for a real person.
Write down what is deliberately excluded as well. An explicit list of what is not in the first release prevents the slow expansion that turns a three month project into a nine month one, and it makes the second phase a decision rather than an argument.
Find The Risky Part Early
Every project has one part that is genuinely uncertain. An integration with a system nobody has documentation for. A performance requirement that may not be achievable. A workflow that seems simple until you try to model it.
Build that part first, even roughly. The instinct is to start with the comfortable work and leave the hard problem for later, which means discovering the hard problem when the budget is spent and the deadline is close.
Decide How You Will Disagree
Every project reaches a point where the client wants something the team thinks is a mistake, or the team proposes something the client did not expect. That moment goes considerably better when both sides agreed in advance how it would be handled.
Who decides scope. How changes get priced. What happens when an estimate turns out to be wrong. These conversations are easy while everyone is optimistic and unpleasant once something has gone sideways.
Ship Something In Weeks, Not Months
A rough working version in week three is worth more than a detailed specification in week six. It gives everyone something concrete to react to, and people are far better at critiquing a real thing than at imagining one.
It also surfaces the misunderstanding while it is still cheap. Feedback on something that runs is specific in a way that feedback on a document never is.
What The First Fortnight Should Produce
- A clear statement of the problem, who has it, and what improvement looks like.
- A first release scope, with the exclusions written down alongside it.
- The riskiest assumption tested with something that actually runs.
- Agreement on how decisions get made when the plan meets reality.
None of it is glamorous, and it is the difference between a project that ships and one that quietly runs out of enthusiasm.
