Case Study: OneTrack
Short form
Phillip Greenham, a construction lawyer and former MinterEllison partner, spent more than two years designing OneTrack before he spoke to a single software company. OneTrack tackles the project administration of very large building and construction projects: the head contractor and every subcontractor administering and agreeing on outcomes as they occur, so the project schedule stays true. When he went to market, he asked five software companies for a fixed price. Redgum was the only one prepared to give it. Nearly 200 weekly working sessions later, OneTrack is live with trial customers, built through a relationship where neither side has needed to open the contract since the day it was signed.
The challenge
On a large construction project, administration is not paperwork that follows the work. It is the work. It rains, builds are delayed, and an extension of time must be requested and approved for each applicable contractor. When that administration happens as events occur, the schedule stays correct and everyone knows when they are supposed to be onsite. When it does not, nobody does, and the ripple effects run downstream through every trade on the project.
Phillip had watched that failure from inside the industry for a career. His answer was OneTrack: a platform where the head contractor and the subcontractors administer and agree on those outcomes together, at the moment they happen, instead of arguing about them months later. By the time he approached the market he believed the product was fully designed. What he needed was someone who could be trusted to build it.
Why fixed price was the test
Phillip asked five software companies for a fixed price proposal. Four of them waffled. They talked about time-based sprints, which he read as filling up your car with petrol: you get a certain distance, you fill up again, and you never know whether you have arrived. Redgum was the only firm comfortable committing.
The difference is not courage, it is method. Redgum runs CARTA, deliverable-based sprints rather than time-based ones. A deliverable-based sprint fixes what you are going to get, however long it takes, and that structure is what makes a fixed price possible to offer and safe to accept. On his own board’s advice, Phillip paid for certainty rather than squeezing the build, because a cheap build pays its technical debt at the end, and the debt grows exponentially.
What we built
Phillip assumed his job was finished when the design was handed over. He was surprised, on day one, by the volume of questions Redgum raised about what he regarded as a fully designed product. The detail a builder needs is far finer than the detail a designer thinks is complete, and both sides read that gap the same way: Phillip took it as his responsibility to fill in the missing information, Redgum took it as its responsibility to keep asking until the engineering was right.
That agreement played out as a weekly working session of an hour and a half, sometimes twice a week, nearly 200 of them and counting. Redgum’s developers absorbed the rhythm of the construction industry until they could frame questions and suggestions in terms that resonate with how the industry operates. The translation gap that sinks so many software projects became, on this one, the mechanism that closed it.
The outcome
OneTrack is live. Trial customers are using it on real projects, and the build continues workflow by workflow toward full production. The delineation of risk has held the way it was designed: Phillip owns the completeness of what OneTrack must do, Redgum owns the engineering of how it does it.
His strongest endorsement is one only a construction lawyer could give. He reviewed Redgum’s contract once, at the start, mostly to clarify intellectual property. He has not looked at it since, and could not lay his hands on it if asked. The project navigates forward on relationship and shared understanding. A fixed price tells you what you will pay; two hundred conversations are what make sure you get what you meant.