The best way to kick off a new software project is to settle a short list of things before anyone writes code: the problem you are solving, who decides, what is in scope, how you will know each part is finished and what the first small deliverable will be. The kickoff meeting then confirms those points with everyone in the room, and the first month is judged by whether working software has appeared. Most projects that go wrong can be traced to something left vague at this stage.
Before the kickoff: check that you should build at all
Start with the problem, not the software. Write down in two sentences what goes wrong today and what it costs the business. If you cannot, the project is not ready to start.
Then check whether a packaged product already does the job. Building is justified when the process is particular to your business, or when bending a product to fit would cost more than building. We set out how to test that in bespoke software vs off-the-shelf software.
If you are going to build, speak to more than one supplier and give each the same written description, so that the quotes can be compared. Our software project planning worksheet is designed for this. Pay attention to the questions each supplier asks you. One who asks about your data, your users and your existing systems is working out what the job involves. One who sends a price without asking anything is guessing.
What to settle before the first meeting
These are the points that cause trouble later if they are left open.
- Scope. What the system must do on day one, what can wait and what is deliberately excluded. The excluded list is as useful as the included one.
- Acceptance checks. For each part, how both sides will agree that it is finished. A fixed price depends on this: it can only be set once the scope and the checks are agreed. Our fixed-price page explains how that works.
- Data. Where the system’s data will come from, who will supply it and what condition it is in. Moving data out of old spreadsheets and databases is regularly underestimated.
- Users. Who will use the system, how many of them, on what devices and how comfortable they are with software.
- Running costs. Hosting, licences, support and maintenance after launch. These continue for as long as the system does and belong in the budget from the start.
- Personal data. If the system will hold information about customers or staff, UK data protection law applies to how it is stored and who can see it. Raise this before the design is settled, and take advice if the data is sensitive.
- Ownership. Who will own the source code and when, and whose name the hosting and other accounts will be in. This belongs in the contract, and it is worth taking legal advice on the wording. See who owns the source code of bespoke software.
The kickoff meeting: who attends and what to cover
The kickoff is a working meeting. Its purpose is to make sure that the people who will do the work and the people who will make the decisions have the same understanding, and to find out where they do not.
From your side, bring the person who can decide on scope and budget, the person who will answer day-to-day questions and at least one person who will use the system. From the supplier’s side, expect the lead developer and whoever manages the work, not only the person who sold it.
A workable agenda for ninety minutes:
- The problem and the outcome, described by the client in their own words. Developers who understand why a system is wanted make better small decisions.
- Scope. Walk through what is in, what is out and what is still undecided. Give every undecided item an owner and a date.
- Roles. Who decides, who answers questions, who tests and who approves payment.
- Ways of working. How often you will see a demonstration, where the list of work is kept, how questions are asked and how quickly each side will answer. If part of the team is in another time zone, agree the hours in which everyone can be reached.
- Access. Accounts, test systems, sample data and contacts at any third party whose system must be connected. Waiting for access is a common cause of a slow start.
- Risks and unknowns. What could change the amount of work, and how each will be investigated.
- The first deliverable, with a date.
Send a written note of what was agreed within a day, and ask everyone to correct it. That note is the first project document that matters.
Start small: the first deliverable
Choose a first deliverable that is small, real and runs from one end of the system to the other. For a job-management system that might be a single job entered on a screen, saved to the database and shown on a list. It will look unimpressive. Its value is that it proves the parts connect: the code is in a repository you can reach, the system can be built and released to a test environment, and somebody on your side has logged in and used it.
From there the system grows in increments, each one demonstrated. If the project is a new product whose market is uncertain, the same thinking leads to a minimum viable product; the advantages and disadvantages of that approach are covered separately.
What a good first month looks like
By the end of the first month you should be able to say yes to most of these:
- We have seen something working, however small, on a test system.
- The supplier has asked us questions, and we answered them within a day or two.
- There is a list of the work, and we can see it.
- Every open decision has a name and a date against it.
- We know what the next demonstration will show.
- We have access to the source code repository, or a date by which we will.
Warning signs are the reverse: no demonstration, no questions, access still being arranged and a specification that is still being rewritten. None of these is fatal in week four. All of them are harder to fix in week twelve, so raise them as soon as you notice.
What to do this week
If the project has not started, fill in the planning worksheet and send it to the suppliers you are considering, together with our list of questions to ask a software supplier. If it has started and there was no proper kickoff, hold one now. Going through the agenda above in week three is awkward for an hour and saves a good deal more than that.