Fund Teams, Not Projects

Software is not manufacturing. Fund teams, not projects.

When people trained in traditional project management (e.g. construction) step into the world of software delivery, they often face a difficult shift.

In those industries, scope is fixed, timelines are tightly managed, and costs are estimated with precision. Deviations are treated as problems to be avoided.

Software, however, is a different kind of work. It evolves as you build it. Discovery happens along the way. Trying to apply rigid planning models to a dynamic environment creates tension, particularly when it comes to discussing estimates and budgets.

“How do I budget for your work? Is this an open-ended cheque?”

That is a fair and important question. It comes up often when traditional project thinking meets modern delivery practices.

Instead of pretending we can define everything up front, we take a different approach. We timebox the investment. For example, a client might fund a team of five developers for a fixed period such as three months. During that time, we collaborate to identify the most pressing problems, focus on delivering value continuously, and adjust priorities as we learn. This creates a delivery rhythm that is both transparent and flexible.

We hold regular touchpoints, usually every one or two weeks. In those meetings, we review progress, evaluate outcomes, and decide what comes next. The client stays in control of the budget, the direction, and the priorities. They also have the freedom to pause, stop, or continue based on the results and evolving needs.

This is not about open-ended spending. In fact, it offers more control than the traditional model, where large budgets are committed up front based on speculative estimates and outcomes that may not appear for months. By the time results arrive, the original problem may have already changed.

Modern delivery is not about giving up control. It is about investing responsibly in outcomes, staying responsive to change, and managing risk by delivering value early and often (agile software development anyone?)

People coming from more fixed-scope industries often respond with, “Well, if you were building a house…” or “You wouldn’t build a bridge this way…” But that is exactly the point. Software is not a house. It is not a bridge or a car. It is not repeatable manufacturing. It is a process of learning, solving, and adapting. The rules are different, and so are the risks.

Originally posted on LinkedIn.