ArriveCan, the mobile and web app created to manage vaccination and test records required to enter Canada, has been in the headlines recently due to cost overrun. With an original budget of $80,000, the estimated costs now stand at $84M according to a Globe and Mail article. Although the scale of overrun at ArriveCan is staggering, the concept of cost overrun is not foreign to anyone experienced in custom software development. A study by Harvard Business Review found an average of 27% cost overrun for software projects. Even more shocking, one in every six projects had a cost overrun of 70% and a schedule delay of 200%!

Business leaders and procurement specialists know that maximizing every dollar is critical, especially as we enter a time of economic constraint. But how might we avoid making costly mistakes when developing custom software products?

This article explores three common risks, and how to avoid making them by leveraging product thinking and Agile funding best practices.

Risk #1 – Developing detailed product requirements upfront in order to get a quote

Custom software products start on the right path by aligning stakeholders on a business problem and building consensus that software is the solution. What happens next is often the problem: detailed business requirements are created, then sent to potential suppliers and internal IT teams to get estimated costs.

Successful products have a clear vision, and measure of success that relates to the broader business goals. Still, too often, this step of aligning product goals with business goals is rushed or missed altogether. The result is a fragmented understanding of how the product should take shape across stakeholders. The resulting product might have features that were required, but fail to solve the business problem that justified funding in the first place.

So how can we avoid this problem? By spending time aligning stakeholders on the desired business outcomes before developing feature requirements.

At Devbridge, a Cognizant Softvision company, we start every engagement with a product strategy workshop, including both business and technical stakeholders. The outcome of this workshop serves as the charter for the product development team, developing a roadmap of features directly driven by the original business goals and related product strategy.

These sessions also help surface assumptions or features that might otherwise not be included in detailed business requirements. For example, the ArriveCan app was not built to the accessibility and security standards needed for the Canadian public, and an extra $4M investment was required to upgrade the app.

Risk #2 – Allocating the entire budget at kick-off

Funding cycles are often annual processes, setting the budget for the next fiscal year. But that doesn’t mean projects should have the entire budget unlocked at kick-off. Startups are able to iterate and deliver value quickly because they “fail fast,” learning and adapting with limited funds. But the ambiguity of “fail fast” funding is inconsistent with most business budgeting processes.

So how can business leaders realize startup-like gains within a large corporate funding process? By breaking large project budgets into smaller, measurable phases, and gatekeeping the funding for each phase.

The same product thinking applied when kicking off the project can occur on a smaller scale. Align on product goals and related feature sets that relate to the broader business goal for each new round of funding. These goals should be specific and measurable to continue justifying the funding.

Ideally, the product is released, or at least beta tested, after each funding cycle. This allows real user feedback to shape the product and strengthens the business case for more funding. More importantly, if released regularly, the ROI can be realized sooner.

Risk #3 – Fixed bid thinking (or, “can’t we just minimize risk by fixing cost, scope, and timeline upfront?”)

The “triple constraints” of scope, time, and cost are foundational to project management. It might seem like a simple solution to fix them upfront to minimize risk. However, the concept of “fixed cost” can actually introduce greater financial risk by encouraging potential software providers (even internal IT teams) to over-estimate their efforts in order to accommodate unknowns.

Inevitably, as the project progresses, new features are requested based on new information learned during the development process. Each request is treated as a “change request,” requiring new funding, because it was not included in the original costing assumptions. The end result is a higher price tag than the original "fixed cost."

So how can we avoid this, while still managing within budget? Just like we would measure progress toward project goals by measuring scope completed vs. remaining, we should also measure the actual budget used in real time as the work is delivered. If 20% of the scope is completed, but 40% of the budget is used, we can course correct before the entire budget is spent.

But doesn’t this introduce risk to the budget holder? Not if the client has real-time access to project health metrics including timeline, cost, and scope. Agile software development is a partnership, where the stakeholders should be actively involved in providing feedback and direction using shared metrics, aligning approval of work to results delivered as the project progresses each sprint.

Isn’t this just Agile?

Everyone claims to be Agile – “we have 2-week sprints!” – but Agile ceremonies alone do not guarantee a return on investment.

Business leaders, and especially budget approvers, have the ultimate control by setting the tone of how funding will influence the roadmap at the start of any project. We can optimize the investment by merging product thinking and Agile funding. Make sure the vision and success metrics are well-defined. Consider how the funding structure can de-risk the effort by breaking large scope into smaller, measurable phases and gatekeeping the funding for each phase. And demand real-time access to budget and scope reporting.

Want to learn more about how we’ve combined product thinking with Agile funding to deliver award-winning products? Read our case studies.

[i] Bill Curry (2022 October 17). “ArriveCan app started as $80,000 expense before growing to $54-million, breakdown reveals”. The Globe and Mail. https://www.theglobeandmail.com/politics/article-arrivecan-app-costs-contractors/

[ii] Bent Flyvbjerg and Alexander Budzier (2011 September). “Why Your IT Project May Be Riskier Than You Think”. Harvard Business Review. https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think