Most of what decides whether a software project goes well is settled before anyone writes code. Not the technology. Not the vendor. The things the client did, or did not do, in the weeks before kickoff.
We have run more than a hundred builds since 2005, and the projects that finished on budget and got used shared a short list of habits on the client side. This is that list. None of it requires technical knowledge. All of it requires an executive who is willing to decide.
Decide what the project is for
One sentence. If you cannot say what the business will be able to do after the project that it cannot do today, the project is not ready to start. “Replace the old system” is not an outcome. “Close the books in three days instead of twelve” is. “Quote a job in one visit instead of two” is.
Write the sentence down and share it with everyone who will touch the project. Every scope debate for the next six months gets settled against it. When someone asks for a feature, the question is whether it moves that sentence. If it does not, it waits.
If you have three sentences, you have three projects. Pick the first one.
Decide who owns it
A software project needs one person on your side who can make decisions and be reached. Not a committee. Not “the leadership team.” One name.
This person does not need to be technical. They need to know the business well enough to answer “how does this work today?” without a meeting, and have the authority to say “we will do it this way” without checking upstairs. In a middle-market company that is usually a COO, a CFO, a GM, or the owner. It is rarely the IT person, because the IT person usually cannot make business-process decisions, and those are most of the decisions.
Expect this person to spend several hours a week on the project during design, and a few hours a week during the build. If they cannot give that, the project slows to the speed of their calendar. We would rather you tell us that now than discover it in week six.
Line up the people who do the work
The executive knows what the business needs. The people who do the job every day know how it actually works, including the parts nobody wrote down and the workarounds that quietly became the process.
Before the project starts, identify two or three of them per major workflow. Tell them what the project is for, and tell them they will be asked to sit in design sessions and try early versions. Make it clear their managers have cleared the time. Nothing kills a project faster than the person who knows the process being “too busy” every time we need an hour.
If you want a head start, ask them the questions in All Systems Fail. The answers will surprise you, and they will save us a week.
Gather the data and the access
Almost every project we take on touches data that already exists somewhere: a spreadsheet, an old database, an accounting system, a SaaS product with an export button. Before kickoff, find out:
- Where the data lives. Every system, every spreadsheet, every shared drive that holds something the new software will need.
- Who can get into it. Admin logins for the systems involved. If the only person with the password left two years ago, start the recovery now, not during the build.
- What shape it is in. Pull a sample. If customer records are duplicated four ways and half the dates are typed as text, that is useful to know before anyone plans a migration.
- What the vendors will allow. Some platforms have an API. Some do not. Some charge for it. A quick email to your account rep answers the question that otherwise stalls a design session.
You do not need to fix any of it. You need to know about it, and to have someone who can grant access on the day it is asked for.
Settle the money and the paperwork early
Know your budget before the first call. Not to the dollar, but the range you can defend to your board or your partner. We will ask, and a real answer lets us design toward something you will actually approve. If you have no idea what things cost, typical budgets by type of project are on our pricing page.
Find out who signs. If contracts over a certain size go through legal, or a PE sponsor has to see anything above a threshold, get that process moving in parallel with the proposal. We work from a standard MSA and a short SOW, and the paperwork is rarely the hard part. It is the thing that sits in someone’s inbox for three weeks that hurts.
What not to bother with
Some things feel like preparation and mostly waste time.
A detailed requirements document. You do not know what you want yet, and neither do we. That is what the design phase is for. A page of outcomes and a list of the workflows involved is worth more than a fifty-page spec that will be wrong by week three.
Picking the technology. Unless you have a hard constraint, like an existing platform the new system must run inside, leave the stack recommendation to the people who will build and support it. We will tell you what we recommend and why.
Interviewing six vendors on price. You will get six numbers built on six different sets of assumptions, none of which match. Compare how each firm proposes to find out what the project should be before they quote it. That tells you more than the number does.
Waiting until everything is perfect. Your processes are not documented. Your data is messy. Someone key is on leave next month. That is every company we have ever worked with. Start anyway.
Where this leads
For a new system, the first engagement is a VDP Sprint: Validation, Design & Planning. It opens with a two-day, face-to-face workshop with the people you lined up above, and closes three to four weeks later with click-through mockups of the key screens, written requirements, a stack recommendation, and a roadmap with the investment for the first release. Every item on this list makes that sprint faster and the output better.
If the project is about a system you already run, the first step is a System Evaluation instead, and the access and data items above matter even more.
Either way, it begins with a Discovery Call. Thirty to sixty minutes, no slides. If you have done the first two things on this list, deciding what the project is for and who owns it, you are further ahead than most.