Your team needs to build something. Let’s say it’s a new website. Or an app. Or a cloud database that’s actually scalable. You get the gist.
It’s exciting, right? Everyone’s on board for the project, you’ve sat through the scoping meetings, and you know what you want. You can’t wait to reap the benefits.
Now it’s time to find someone who can help. You go to three different agencies and ask them to quote me what it’ll take to build this website. Hey, no problem, they say. We had our team look at it. We got a feel for it. What we propose is that we do a discovery session, usually two to four weeks. That’ll be $25,000. And then based on what we know today, we think the website is going to cost $125,000.
Great. You pick a vendor. You get approval to spend the $150,000. You kick off.
And here's where the journey takes a turn.
Over those 2-4 weeks of discovery, your vendor uncovers unwelcome surprises. You’ve watched Property Brothers before—you should have known that there’s always something expensive lurking behind the walls—but it’s still distressing. Oh, you don’t have a hosting service? Oh, we didn’t realize we had to build the backend. Oh, we didn’t know you’d need X. That’s gonna cost extra—we’re probably looking at more like $300,000.
Now you’ve already invested $25,000 into these folks, and you don’t want to just waste that money, get new quotes, and start the whole process over again. So fine—you’ll get approval for the extra and sign a change order.
Scope changes. Prices go up. Timeline gets longer. Change orders get written. And round and round you go. Instead of focusing on this thing you’re creating, this thing that’s going create real business value, you’ve got to deal with all this nonsense. It happens all the time, it happens to everyone, and it just seems like we should have optimized this process by now.
So let’s do that.
We’re seeing from our clients that project success isn’t necessarily dependent on scope. What matters is how fast and how high-performing your engineering organization is. Every project changes scope at some point in its development; that’s a given. So instead of fighting that reality, what if we incorporated it into the project plan? What if the success measure was “You have a great website that accommodates all your needs” and not “You stuck to the scope within timeline and budget”?
With high-performance software development teams, that can happen.
1. Reevaluate if the defined scope, schedule, and budget are truly the drivers of this project at all.
If you want to break the cycle, you’ve got to break the mold. Do you write up an agreement with Netflix to scope out exactly what you’re going to watch for the next three months and pay them for time and materials? No—you have a subscription, and they deliver whatever content you decide on, when you want it. Software development should use the same service model. No “discovery” = faster start, no money wasted on changes, and quick pivots if you decide to switch something up without an extra charge. Consider this model Software Development as a Service (SDaaS).
2. Partner with a company that augments your team, not one that takes the project out of your hands.
There’s nothing worse than being in the dark on your own project. When you hand off a project, you’re at the mercy of your vendor’s project plan. That’s why we’ve chosen this new way of deploying one or more TangoTeams—they work solely for you, as long as you need them. No split priorities means your pod gets intimately familiar with your team, and that allows for faster deployments, more visibility, and a relationship you can trust.
It’s your project. You should be in the driver’s seat. Seems so simple when you put it that way. Why isn’t this the industry standard already?
3. Adopt a faster, more agile development pace.
Phased SOWs and project plans leave a lot of room for error, and that’s on purpose—your software development team will be judged on whether they meet the timeline. But research shows that high-performance engineering teams deploy multiple times a day and keep lead time for changes and fixes under an hour. That tempo means you can make decisions and changes on a dime. Want to move a feature higher up the list? You got it. Need to change your global site colors? Great, here you go. This is the pace you need to use if you want to get s*** done.
4. Measure success via the four key metrics, not by how closely it matches the scope.
There’s performance, and there’s performance. A lot of engineering vendors give you ‘insight’ into how well their devs are doing through a song and dance of performative ‘success’ metrics, like lines of code or number of story points hit. Do they think you were born yesterday? It’s easy to show those numbers in a way that looks good but doesn’t really tell you anything.
We use the Accelerate DevOps model, with full transparency on metrics you can’t fake. They cover both speed and quality:
High-performance software development keeps deployment frequency high and the rest low. If your team can maintain that, the rest hardly matters—requirements and design are all you need to get moving.