As the former Chief Product Officer at STRV (now driving products under STRV Labs), I’ll be the first to admit that we’ve had projects go over budget. Every professional in this space has made mistakes. But with 17 years of experience, we’ve learned our lessons and have adapted our processes to minimize the risks.
For anyone that needs a bit of guidance, I’d like to outline the four most common mistakes, how our team works to avoid them and what you can do to recognize a genuinely transparent, reliable company.
Why Do Projects Go Over Budget?
Lack of Transparency
Disregarding transparency takes many forms. The most seemingly innocent, common but very dangerous are the little white lies that stem from thinking, “Okay, we'll figure this out, we'll deal with it later.” When that “later” actually comes, a debt will have to be paid—whether it's financial, technical, time-related or whatever else—and that obviously has an impact on the whole project.
Making Big Assumptions at the Beginning of a Project
Not giving a cost estimate the proper care can be catastrophic. (Our CEO wrote an article about the BS found in sales proposals.) In software development, you need to be able to very quickly adapt to change. With agile development, a team is required to skillfully pivot from sprint to sprint. For this to go smoothly, the project’s goals and budget must be clear from the beginning. When a collaboration starts with the client asking for an estimate and the tech partner relying on an array of rushed assumptions, it’s easy to end up with a big gap.
No One Revisits the Budget
As a project evolves, the scope obviously changes and there are constantly things that have to be revisited in terms of development on its own. Many times, companies do not do this at all. And if no one revisits the costs as the project takes shape, you’re easily going to go over budget because you can’t really pinpoint where you are in the process at any given time.
Undefined Roles & Responsibilities
With a traditional agile approach, you have a product owner, a product manager, set deadlines… Responsibilities are defined. People are held accountable. In this scenario, product managers communicate with the stakeholders and whoever put forth the budget. There’s an ongoing, open conversation about all of the latest changes. If this communication isn’t happening, you’re continuously going to go over budget on projects because the changes and their impact are not being communicated to the stakeholders.
How to Prevent These Mistakes
A key piece of advice is approaching the budget as something that is not fixed. It is something that you’re going to continuously have to monitor.
Here’s what we’ve learned from our own missteps and solutions, as well as from observing our competitors and listening to our clients’ experiences with other partners.
Find People That Naturally Take an Extreme Ownership Approach
One of STRV’s greatest tools is having our roles and responsibilities clearly defined. STRV product managers are basically a mix of project managers, tech leads and even account managers. They do a little bit of everything, from client communication and scope analysis to budget tracking. One of the main reasons we’re successful at managing a project against a scope is this idea of extreme ownership.
When our product managers are on a project, they know: “This is mine. All of the components that touch this product, including the budget, are mine. The sprint planning, how we’ll get to market, does the product make sense, everything is my responsibility.” And because of that sense of ownership, they are continuously keeping an eye on everything.
I think this is what makes us a little bit different. Bigger companies tend to have these roles divided; there’s a project manager, a business analyst, etc. And if these people don’t communicate properly, things can fall through the cracks. Unfortunately, the budget is one of them.
Understand That a Proper Cost Estimate Takes Time
Before sending out the SOW (Statement of Work) in the contract—which includes the scope, budget and timeline—we have multiple people give it a “sanity check.” Our sales team can never just send out a contract; it needs to be approved by someone from the product side, and that person needs to get a green light from someone on the engineering and design side.
The STRV estimate process takes about five days, which some people deem too much. To an extent, I’d agree; if you have proper specifications, this process should take less time. However, given our experience, the specifications are never as clean-cut as our clients think. There are always ideas that pop out, loopholes that haven’t been considered or even gaps in the logic. We do our due diligence, making sure that everything’s been covered. And if we’re making assumptions, we communicate them to the client—so that he/she has the opportunity to say, “Sounds about right,” or, “That’s not quite it.”
Have a Buffer, but Make Sure to Get It Right
Our SOW includes a 10% buffer. Even when clients are convinced they know exactly what they want, that buffer remains. It is there as preparation for unexpected changes; that buffer is why small tweaks to the plan don’t result in unnecessary delays and even a sense of broken trust. It’s also why we can confidently stand behind our estimate without feeling like we’re naively optimistic.
As our estimate goes through the many afore-mentioned checks, someone (often an engineer) may notice a discrepancy in a specific assumption and can suspect that we won’t be able to stay within the estimate, despite the buffer. In such cases, we start finding alternate approaches. If we can’t figure this out in time, we let the client know that a part of our estimate may be a little bit under or a bit over, we explain the assumption, and we bring in an engineer to do additional research—at no cost to the client, of course. Creating the estimate is our job, so this homework is on us.
Recognize & Reduce Assumptions Through Transparency
When client assumptions (in the form of product goals or expectations) are too big and unhinged in the beginning, we acknowledge this by informing clients that we’ve drifted into brainstorming an idea. That’s when we recommend that our clients try the Discovery Phase, where we can get all questions answered before we start building. This helps us see how big the roadmap is, how much it’s going to cost and/or what scope of the MVP we should aim for considering budget limitations—all of which lets us paint a much more accurate picture.
Assumptions are always finding their way into the conversation. When the client starts seeing a product take shape, many different ideas start coming to mind. The client may decide to shift in a new direction. By all means, let’s do so; our processes are built for that. But pivoting often affects aspects like the budget, timeline and team setup. Communicating this to the client before moving forward with changes is key. Otherwise, the client may not be aware that a certain change required adding five engineers, and that the month’s invoice has doubled.
Continuously Check & Revise the Budget
If any scope changes come into play and/or if assumptions shift, a number of crucial steps should follow: The changes need to be communicated to the client, and they have to be reflected in the budget and in the forecasting.
When we finalize our estimate process at the start, we know what we’d like to build, and we have our assumptions about what that will take (which have been scrutinized by our department representatives). Then, as the project moves closer to the finish line, we’re continuously checking those assumptions to establish whether they are still accurate, or whether a pivot is needed. For instance, at the beginning of each project phase, the product manager lays the plan out for all designers, engineers, QA testers and anyone else on the project. The full team analyzes the details before they are confirmed with the client.
Bonus Tip: The First Warning Sign
I’d like to share an example of an alarmingly common scenario in this industry.
A client comes to STRV, saying: “Hey, I want to build an app. I need it to have a chat function. I already have a quote from this other company.”
Our response is, “Great! What are the functionalities?”
“What do you mean? Just a chat.”
“Would you like group messages or private messages? Is it just text, or also sending pictures, videos and gifs? Do you need an admin for each group? Do you have a search and history function? Do you have a delete messages function? Do you have an admin for the whole thing? Are you able to report users or content?”
Most of the time, the client can’t answer these questions, yet they already have an estimate for a chat from another tech company.
It’s common for potential clients to tell us that they’ve already received bids from multiple companies and they’re just waiting on ours—while no one on our team has had a conversation with them about the product; all we have are specifications, which come in the form of about 10 bullet points. Immediately, there are red flags popping up. You don't know what you want to build, but you have people that are quoting you on it?
This signifies a large problem within our industry, and it comes down to a lack of transparency. Agencies making assumptions on behalf of clients, rather than with them, should not be acceptable.
Ask the Right Questions, No Matter What
Quoting clients on the absolute bare minimum never has positive consequences. It results in conversations like, “Oh, well, we didn't know you wanted this, that’ll cost you X percent more.” This is what results in a project exceeding its budget. It is precisely the mentality that we look to avoid.
If a client gets a sticker shock from us after we provide our estimate, I’m always ready to sit down with them and go through the numbers, line by line. If they’d like to reduce the scope, I am more than happy to discuss the options. But I am not going to reduce the budget, because it is fair and it is the truth.
Sometimes, STRV may not be the partner for you. We’re okay with that. If we go through the estimation process together, we’ve already built a form of partnership. My hope is to always feel good about the fact that we’ve done everything we could for the product—even if that’s just opening a person’s eyes a little bit by saying, “Hey, whatever other company you’re talking to, just make sure you’re asking these questions.” Because if you aren’t, you’re going to end up with a very heavy check down the line, unsure of how you got there.
