Product teams and founders are always looking for the answer to this question: How long will it take, and how much will it cost? It’s not an unreasonable question, and of course the budget and your runway must be managed properly. But how to do that the right way is complicated, and we’ll explore those intricacies and common mistakes in this blog post.
The Challenge of Project Estimates
Project estimates are one of the most difficult subjects to address. It’s never easy to answer the question of how much something will cost and how long it will take without proper discovery and detailed planning.
In the digital world, estimating software development is challenging because they always have unknowns, and requirements often change as new ideas emerge during prototyping and testing. Product leaders often discover significant functionality that needs to be added, and solving workflows and data requirements is fluid.
We recently engaged with a company who were looking to build a platform and had a very preliminary scope of what they wanted it to do. They had already spoken to several firms and had estimates from $250,000 to well over $1 million, which was surprising to them.
The truth was, there was no way that anyone could provide an accurate estimate on the project without proper planning. They were shooting from the hip, which is never a good idea.
As an Agile company, we don’t provide fixed bids, but we do have effective means for controlling costs and timelines. We do that through thorough discovery and planning, meticulous documentation, and solid project management, which I will outline next.
The Importance of Proper Discovery and Planning
One of the big challenges is finding the right balance between too little planning and too much. In the old “waterfall” project management days, discovery and planning was attempted for the entire project, with the goal of delivering a detailed scope doc and project plan that was to cover every aspect of the project in detail. That documentation invariably proved to be a fantasy, and the finished product was always very different than what was planned.
The flip side is doing too little planning, which results in poor outcomes, unmet requirements, and cost and timeline overruns. “Fire, Ready, Aim” is not a good strategy for developing great products. Because planning has a cost, outsource partners often shortchange planning to keep costs down, which introduces enormous risk.
So, what’s the solution, and what is the right sized planning process? There are numerous planning methodologies, but we are proponents of Program Increment (PI) Planning, which is a system that uses face-to-face communication with all stakeholders to develop a 90-Day plan with committed objectives that are designed to deliver business value. It’s collaborative and transparent and outlines the risks and unknowns. And it provides a cost range for the PI, as well as increased clarity on the costs for future phases of the project lifecycle.
While this kind of rigorous planning process has an upfront cost, the reward is that it reduces risk and provides enormous value with dramatic increases in productivity. So yes, there is an expenditure at the outset, but the total project costs are typically much lower.
So, what does a PI Planning Charter deliverable look like? While each project is different, they typically include:
Create a Consensus
Consensus on what the high-level goals and objectives are for the product. This includes not just what is being built, but what the objectives and business goals are.
Epics, Stories, & Spikes
Epics (the big pieces), Stories (which are smaller requests written from the user’s perspective), and Spikes (which are the things that require some research and decisions to be made). These define the elements of the features, and the unknowns, in granular detail.
Acceptance Criteria
Features with Acceptance Criteria, which are plain language descriptions of what defines when a feature is completed. It’s the consensus of what each feature is that all stakeholders can see. Nothing gets missed.
Confidence Scores
Confidence Scores, which is the development team’s level of confidence that they understand the work to be done, and how long they expect it to take. Low confidence scores are alerts that something might need additional attention and scoping.
Documentation
Mapping of workflows, which often include wireframing or even high-fidelity mockups that make it easier for all team members and stakeholders to obtain a consensus on functionality.
Scenario Planning
A breakdown of the estimated costs including high, low, and planned case (our target) estimates.
As you can see, there is a lot that goes into creating a PI Planning Charter that is, in all actuality, part of the development process. The beauty of investing in this first is that it does indeed provide a great deal of clarity on the budget and the timeline, as well as an extraordinarily clear consensus on what is being built!
Keep in mind that while the Charter for the PI is for the first 90 days, we can also begin to make some projections into the future as to how many PIs we anticipate it will take to get to a product launch. It’s not perfect, but this is how you get a handle on the overall production budget, and to make sure that product launches align with things like sales and marketing efforts.
And this is still Agile. It’s not uncommon for new ideas and changes to surface during development that are opportunities for new features or even reducing costs. When that happens, any impact on the budget timeline is discussed and approved before the change is made.
So, again, Program Increment Planning isn’t the only methodology, but we have adopted it because of the tremendous benefits it brings to a project.
The Problem with Fixed Bids
For startups and teams with limited budgets, they often look for fixed bids to control costs and to add certainty to the timeline. The irony is that often introduces tremendous risk, and more often than not, the actual development cost doesn’t align with the estimate.
Rarely does it work out just right for both parties where the estimated hours came out to what was actually required. Someone almost always loses, and sometimes big. Either the bid was too low, and the developer is going to eat the cost, or the bid was too high, and the customer pays too much.
Clients might think “If they bid too low, that’s their problem.” But when the developer underbids, they will panic as their costs soar, and start scrambling to minimize the hours by cutting corners, looking for upsells, and creating change orders constantly. The product suffers, or even fails completely. No one wins.
And that’s really speaks to the heart of the client / development partner relationship. It should be a mutually beneficial relationship where everyone wins.
In future blogs and webinars, we’ll be talking about other ways to control costs, maximize the value of your budget, as well as pitfalls that can derail a project or even kill a company.
Conclusion
Controlling costs is multi-faceted and goes beyond just competent development. It starts with solid customer discovery and great planning. Select partners with solid reputations that align with your goals, and you’ll greatly increase your chances of success.