How fast can you start, and how long will it take?

Almost every serious conversation reaches this question: when can you start, and when will it be done? The honest answer is that the start date is mostly in both parties’ hands, and the end date depends on things that are often unknown on day one.

That is not a dodge. Here is exactly what decides both, and what you can do to shorten them.

What decides the start date

We confirm a start date when five things are ready:

1. The scope. Both sides agree what the work is and what it is not.
2. Access. The repository, environments and accounts the work needs are available through a safe route.
3. The agreement. The engagement terms are signed.
4. Payment. The agreed payment for the start of the work is in place.
5. A decision owner. A named person on your side can answer questions and make decisions.

In practice, access and the decision owner are what hold starts back most often. A team can be ready on Monday and still spend the first week waiting for a server login or for someone who can say which of two options the business wants.

Why we don’t promise a date for unclear work

A delivery date is only as good as the understanding behind it. When the scope is unclear, a confident date means one of two things: it has a large hidden buffer, or it will move later.

So while the scope is still moving, as it usually is in ongoing work, we agree review points instead: when work will be shown, checked against real cases and accepted. Timing depends on approvals, access and the order of priorities, and we would rather say that plainly at the start. Once the scope is clear enough to price, as in a Custom Project, we do commit to dates.

The fastest ways to get moving

If you need to see progress quickly, start with something that has a clear boundary. Bounded work can start sooner because there is less to agree first.

• A Decision Review looks at one decision, so it needs only the options and information you already have.
• A Fix Sprint moves one clear problem towards an agreed result, checked against an agreed test.
• A System Review investigates one problem and tells you what to fix first, which often makes the larger timeline much clearer.

Starting small is not a sales tactic. It gives both sides real evidence about the system, the access and how decisions get made, which is exactly what a reliable larger plan needs.

When testing and go-live happen

Testing is not a phase at the very end. Before work starts, we agree how a change will be accepted. The work is then built and reviewed in parts. Where the setup allows it, changes go to a test copy of the system first (often called staging), so your team can check them with real cases, test accounts or protected sample data.

Go-live follows acceptance, not the other way round. At release, we record who approved it, any risks that remain, and how it will be watched and, if needed, undone.

How to shorten the timeline from your side

The biggest time savings are usually on the client side, and they cost nothing:

• Name one decision owner who can answer questions within a day or two.
• Arrange access before the start date, not after.
• Collect a few real cases the work can be tested against.
• Keep one priority active at a time, rather than several half-started.

With those in place, most of the waiting in a software project disappears.