When a custom software project fails, the reflex is to blame the vendor. Sometimes that is fair. More often, after 10 years of building software at codelabs.rocks, we have found the dominant cause sits on the client side: the organisation was not ready to run a project of this kind. The code might be fine, the deadlines may be hit, but the business never absorbs the software the way it was supposed to, and the investment produces less value than it should.
This article is written for the person who has just signed (or is about to sign) a contract for a 6-month custom development project. It walks through what your side of the work looks like and how to prepare for it properly, so that the vendor's effort actually translates into business outcomes rather than a well-executed solution to the wrong problem.
Before the Project Starts: Four Things That Need to Be True
1. One person owns the outcome, not the process
Every successful project has a single person on the client side who owns the business outcome. Not the budget, not the timeline, not the vendor relationship: the outcome. This person is the one who can decide, in a sprint review, whether a feature is good enough or needs to be reworked. They are the one who breaks ties when two departments disagree about how something should work.
If this role is split across two or three people, or if decisions default upward to an executive who is not in the room, the project will lose days to every significant question. We have watched projects where a single decision about notification behaviour took three weeks to resolve because no one had been given the authority to make it. Across a 6-month engagement, that pattern adds up to major delays and a frustrated delivery team.
Before the project starts, name this person. Tell them. Make sure everyone else in the organisation knows that this is the person who decides.
2. The real problem is defined, not just the requested solution
Most RFPs and initial proposals describe a solution: "a platform with features A, B, and C." The actual business problem, the one that motivated the project in the first place, is often assumed but rarely written down. This gap causes trouble because good vendors will challenge the solution if they think a different approach would better serve the underlying need. If the underlying need has not been clearly articulated, those conversations go nowhere.
Before the project starts, write one page that answers three questions: what business outcome are we trying to achieve, what happens if we do nothing, and how will we know the project succeeded? This document will be referenced dozens of times over the next six months. Its absence is felt every time.
3. Stakeholders are identified and committed, not just informed
A 6-month custom software project typically touches multiple departments: the team who will use the software, the IT team who will host and secure it, the legal or compliance function that needs to sign off on data handling, the finance team who own the budget, and the executive sponsor who approved the project. Each of these groups needs to be actively involved at specific points, not just informed via email after decisions have been made.
The risk of treating stakeholders as observers is that they raise concerns late. In week 18, compliance discovers that the chosen architecture does not meet their data residency requirements. In week 20, IT refuses to host the system because nobody consulted them about deployment. These are not hypothetical examples; they are the kind of surprise we have been called in to help fix when another vendor had not set up the right conversations early.
Before the project starts, map every stakeholder group, identify who represents them, and get explicit commitment to participation. "We will attend sprint reviews as needed" is not commitment. "Maria will attend the review every second Wednesday at 10am" is commitment.
4. Capacity for the project is real, not theoretical
A sustainable custom software project requires, at minimum, a few hours per week from the product owner on your side and a few hours per sprint from subject matter experts who will provide domain input. This capacity needs to actually exist, not just be assumed. If your product owner is already running three other projects at 100 percent capacity, adding a major software engagement on top is setting the project up to underperform.
Before the project starts, look honestly at the calendar of the people who will need to participate. If they do not have time, either free up time or push the project start date. Starting a project understaffed on the client side is worse than starting it three months later fully staffed.
During the Project: The Rhythm That Keeps Things Aligned
Sprint reviews are not optional
We run SCRUM with 2-week sprints, and we require client participation in every sprint review. This is not a process preference; it is the single most reliable mechanism for keeping a software project on track. Sprint reviews are where the product owner sees working software, compares it to expectations, and signals whether the team should continue in the same direction or adjust.
When a client skips sprint reviews, small misalignments compound. A feature built in sprint three based on a slightly wrong assumption does not get flagged, so sprint five builds on it, so sprint seven builds on sprint five, and by sprint nine the gap between what was built and what was needed requires substantial rework to close. Show up to every review. If the product owner cannot make it, nominate a specific deputy, not "someone from the team."
Decisions cannot wait weeks
During a 2-week sprint, the team will hit questions that need client input. Some of these are small ("should this button say 'save' or 'apply'?") and some are material ("the original requirements assumed X, but we are seeing that Y is what users actually need"). Either way, a delayed decision becomes a blocked sprint, and a blocked sprint becomes a delayed project.
The fix is simple: commit to a decision turnaround time, written down. Most of our clients commit to responding within one working day for normal questions and same-day for blockers. This does not mean every decision is perfect. It means decisions happen, the team keeps moving, and if a decision turns out to be wrong, it can be revised in the next sprint rather than frozen for weeks.
Scope changes are normal; scope drift is dangerous
In six months, your understanding of what the software should do will evolve. This is expected, and a properly structured T&M engagement accommodates it. What causes problems is unacknowledged scope change: features quietly added during conversations, priorities reshuffled without a conversation about trade-offs, "while you are at it" requests that multiply across sprints.
Healthy practice: treat every meaningful scope change as a visible decision. The product owner approves the addition, something else drops or gets pushed to a later phase, the budget implication is acknowledged. This sounds bureaucratic, but in practice it takes fifteen minutes per change and prevents the far larger problem of discovering in month five that the project is two months behind because the scope quietly expanded.
The Difficult Part: Organisational Change
This is the piece most projects underinvest in, and it is often the reason good software fails to produce good outcomes. New software changes how people work. The developers your team hired to build a new fleet management platform are not responsible for helping dispatchers adopt it. That is your job, and it is a real job.
Plan the rollout, not just the launch. Who gets access first? How are they trained? What happens to the old system during the transition? Who supports users when they hit problems? If these questions are not answered in parallel with the development work, you will reach launch day with software that nobody is ready to use.
Expect resistance. Even a better system creates friction during the switch. People have built muscle memory around the old way of doing things. Some will be enthusiastic, some neutral, and some actively resistant. Planning for this, rather than hoping it will not happen, is the difference between a successful rollout and a system that sits unused while people quietly continue with the old workflow.
Measure adoption, not just delivery. "The software was delivered on time" is a meaningless metric if half your users are still on the spreadsheets they were supposed to replace. Define what adoption looks like before launch, measure it in the weeks that follow, and treat adoption gaps as urgently as technical bugs.
A Quick Pre-Project Checklist
If you can answer yes to all of these before the first sprint, your project has a much higher chance of succeeding:
- A single named person owns the business outcome and has decision authority
- The business problem is documented in one page, separate from the proposed solution
- All stakeholder groups have named representatives with committed participation
- The product owner has genuine capacity, not just a willingness, to participate weekly
- Sprint review attendance is calendared and protected for the next six months
- A decision turnaround commitment is agreed with the vendor
- A rollout plan exists, at least in draft, before development starts
- Success metrics are defined and will be measured after launch
If several of these are missing, that is not a reason to cancel the project. It is a reason to spend two weeks fixing them before the first sprint starts. That two weeks will save months later.
The Honest Bottom Line
A vendor can deliver excellent software to an unprepared client, and the project will still underperform. A prepared client working with a competent vendor consistently produces results that exceed what the proposal promised. The ratio of your preparation to your vendor's capability determines the outcome more than either factor alone.
If you are about to start a 6-month IT project, the most valuable work you can do in the next two weeks is probably not negotiating the contract another round. It is getting your own organisation ready for what you have committed to. That preparation will pay back at a rate that makes it the best investment in the entire project.
