How long does the preparation before kickoff usually take?

It depends on how complex your existing systems are and how quickly your organization makes decisions. For a straightforward company website where the content and material are already in hand, one to two weeks is usually enough. If you are moving off an existing system, connecting third-party services, or touching processes that span several departments, two to four weeks is the more realistic estimate. The recommended approach is not to wait until everything is finished before starting. Clear the two items that block projects most often — the decision contact and account access — then set delivery dates for the rest and run them alongside development. What you genuinely want to avoid is walking in with nothing prepared, which turns the first few weeks of scheduled effort into idle time.

I do not have a technical background. How do I know which systems to inventory?

The most practical starting point is to ask what websites or software your staff open every day. Have each department list the tools they use, the login addresses, and who holds the account, then note what data sits inside each one. You do not need to understand the technical detail. If you can answer three questions — where is this thing, who can get into it, and can the data be exported — that is enough, and the vendor can take the judgment from there; they will read that list and see which systems need connecting and which can be retired. The real risk is not an imprecise inventory. It is missing the one tool that a single colleague uses but an entire process depends on.

What does a vendor usually ask at the kickoff meeting, and how prepared do I need to be?

The questions tend to cluster into three groups: who the users are, how the process runs today, and what success looks like. You do not need technical answers. Everyday language is fine, as in "customer service calls to confirm an order before anything ships." What you genuinely should settle in advance is priority: if there is only enough time and resource for half of it, which features have to be in the first release. That judgment is not something the vendor can make for you. Bringing a clear answer to the meeting is worth far more than bringing a polished slide deck.

Software Project Kickoff: The Client Checklist

“When can you start?” is usually the first thing a client asks after signing. But the real starting line of a project is not the day development begins; it is the day the client has the data, the accounts, and the decision-making authority in place. The vendor schedules people in, week one stalls because nobody has the permissions to export data out of the old system, week two stalls because the homepage copy is still waiting for someone senior to read it. That is how a schedule gets eaten, a little at a time, and the delay rarely gets recorded against anybody.

The good news is that none of this preparation requires a technical background. What follows is ordered by where projects actually get stuck: what to finish before the kickoff meeting, and what to carry into the meeting itself.

Why preparation before kickoff sets the pace of the whole project

Why projects run late in general is covered in a separate article. This section deals only with the portion of that delay you can remove before development starts.

Development work is strongly sequential. Until the login method is settled, none of the member-facing screens can be finalized. Until the product fields have been inventoried, the data structure cannot converge. When an upstream decision slips, the scheduled work either idles or moves on to something secondary, and when the decision finally lands, part of what has already been built usually has to be revisited. The more awkward part is that this kind of delay happens in the gray zone where both sides feel it is not their problem: the vendor is waiting on material from the client, the client assumes the vendor is busy with something else, and two weeks disappear. Preparing before kickoff compresses that waiting into the period before the project formally starts, so the development phase only has to handle development.

How to tell whether you are ready enough. Picture the vendor sending you ten detailed questions tomorrow morning. Could you answer all of them within a few working days? Whatever you cannot answer is the homework still in front of you.

First: appoint one contact who can actually decide

This is the most important item on the list and the one most often treated casually. The contact does not need to understand the technology, but three things are non-negotiable: they know how the internal processes really run, they can decide within some defined range without escalating, and they genuinely have time to reply.

The most common misstep is handing the role to whoever has the most free time rather than whoever has the most authority. Picture a contact who has to send every question up through several layers of approval: each round trip takes days, and across a month the development team loses a meaningful share of its effective working time. That cost never appears on a quotation, but it is real.

If the size of your organization makes a single contact impractical, at least divide the work explicitly: who owns screens and copy, who owns process and business rules, who owns security and accounts, and who makes the final call. Agree on response times up front as well — ordinary questions answered within a couple of working days, anything needing a meeting scheduled within the week. How much time the contact has to invest also depends on the commercial model, which is covered in Fixed Price or Agile.

Inventory your existing systems: you are running more than you think

Most companies underestimate how many systems they actually have. Beyond the obvious ones — the public website, the inventory and ordering system — there are the tools each department found for itself: the messaging app customer service lives in, the spreadsheet a salesperson maintains privately, the email platform marketing uses, the invoicing system on the accounting side.

The method is simple. Ask every department four questions: which websites or software do you open, what do you use each one for, where does the data sit, and who holds the account. Collect the answers in a single table. No technical description is needed.

That table does three jobs. It lets the vendor judge which systems need connecting and which can be retired once the new system is live. It surfaces the invisible critical tool — the one only a single colleague uses, but which an entire process quietly depends on. And it lets both sides estimate the real effort involved in moving data.

The most common misstep is inventorying only the systems the company formally purchased and missing the tools departments adopted on their own. The things that never appeared in a procurement record are usually the ones that generate a “where did my data go?” the week after launch.

Third-party accounts and access: the step that most often blocks go-live

For development to proceed, the team usually needs to touch several categories of account: the domain registrar, the hosting or cloud platform, payment and logistics services, social and advertising platforms, analytics tools, and email delivery services. What they have in common is that the company frequently does not know who holds them.

The recurring situations are familiar. The domain was registered years ago by a colleague who has since left, using a personal email address. The payment back office sends its verification codes to one phone that belongs to the owner. The hosting is managed by a previous vendor and the company has never held the login details. Individually none of these is hard to resolve, but each can consume several working days, and they tend to surface at the point in the schedule where waiting is least affordable.

Three things are worth doing before kickoff: confirm who holds each account and how to log in, move the registered address from a personal mailbox to a shared company one, and check whether sub-accounts can be issued to the vendor instead of handing over the master password. If the relationship between a domain and a host is unclear, read Domains and DNS in Plain English before you start the inventory.

Content and data: preparing material is usually slower than development

The screens are built, the features work, and then, days before launch, somebody discovers there are only a handful of product photos and the service descriptions are years out of date. This is a textbook end-of-project trap. Content is usually slower to produce than software, because what it consumes is time on the client side rather than capacity on the vendor side.

A few things to confirm before kickoff: who is writing the text, whether photography already exists or has to be shot, whether usable brand assets exist (original logo files, brand colors, font licensing), and what format the data you plan to import is currently in.

A way to check yourself. List every page or screen the system will have, and against each one write who provides the content and when it is due. The entries where you cannot fill in a date are the decisions you need to make now: commission the writing, push the launch back, or leave that piece out of the first release.

Write down how things work today: confirming internal processes

A system digitizes an existing process, so if the process itself cannot be described clearly, the system cannot be built. The task here is to write daily operations out as a sequence of steps, noting for each step who performs it, what information it needs, and who receives the result.

Two things deserve particular attention while writing: exception handling and human judgment. Rules like “orders above a certain value need manager approval” or “long-standing customers can be shipped before payment clears” normally run on shared understanding, and software cannot run on shared understanding. Writing them down frequently reveals that different departments handle the same situation differently — a discovery that is valuable in itself, and enormously cheaper to make before development than after launch.

This step is also the first draft of your requirements document. If you are unsure how much detail to capture, follow the structure in How to Write Software Requirements. It does not have to read like a specification; it only has to make sense to an outsider.

What the first kickoff meeting should cover

The purpose of a kickoff meeting is not to present company history. It is to settle how the next several months will run. These items are worth the time:

Project goals and the definition of success. What problem this system solves, and what conditions mean it worked.
Priority. If only half of it can be built, which half has to be in the first release.
Contacts and response times on both sides. Who talks to whom, and within what window.
Communication channels and cadence. When the standing meeting happens, which channel day-to-day questions use, and what has to leave a written record.
Acceptance method and timing. Who tests, what they test, and how quickly feedback is due.
Known constraints. Legacy systems that cannot be touched, internal audit procedures that must be followed, dates that cannot be missed.

The most common misstep is letting the kickoff turn into a requirements debate, spending the whole session arguing about where one button goes without ever establishing who can make a decision or how acceptance is judged. The details can be worked out gradually; the rules have to be set first. For the questions worth asking while you are still choosing a partner, see How to Choose a Software Development Company.

A final self-check before the start date

Before the agreed start date, run through these questions once more:

Who is the decision contact, and how far can they decide without escalating?
Have all the related systems and accounts been inventoried, and can you obtain the login details?
Is there internal agreement on what belongs in the first release?
Who provides the content and data, and are there firm dates?
Have the current processes been written down, including the exceptions?
Who owns acceptance, and do they know how much time it will take?

If you can answer all six clearly, the first two weeks of the project will not be spent waiting. If two or more have no answer, consider moving the start date back and finishing the preparation first. Starting later with the preparation done usually costs less than starting on time with blanks in the plan.

If several boxes on that checklist stay empty when you run through it, those are the ones worth talking through first. Bring your current situation to NETVANA and we can walk the checklist with you, then work out what genuinely has to be closed before development starts and what can be filled in along the way. Software services are quoted individually rather than sold as fixed packages; for what each service includes and delivers, see the software services overview.

Further reading: to understand how schedules typically get eaten, see Why Software Projects Run Late. For who owns acceptance and how it ties to payment milestones, see How Software Acceptance Works. For what belongs in version one and what does not, see A Guide to MVP Development. And if what you are building is for internal use, start with A Guide to Building Internal Admin Systems.