How to Price a Project

Pricing out a software project is the great boogeyman of the industry. On the one hand you have the clients or stakeholders, who are largely non-technical, that are trying to get something built and budget for it. At the other end, you have the developers and the agile gurus shouting that estimates are trash and we can never know how long something will take. So then how the heck does anything actually get done?

Businesses need to have some expectations in order to plan for their software needs. Developers need to have some idea of time and complexity, as well as how to handle the inevitable unknown unknowns, or they'll run at a problem forever. Is there actually a way to reconcile these two camps?

At a software agency, reliable delivery of software on time and on budget is at the core of the business. But for many, figuring out how to handle pricing and scoping of projects has been harder than the act of learning to program itself. However, after many years of doing this I have a relatively simple framework that works depending upon what's important to the stakeholder.

Cost, Time, Scope -- Pick One

All software estimates come down to three elements:

1. Cost - how much money you have to build?
2. Time - how much time you have to do it?
3. Scope - how many features you need to build?

I've found problems arise when you try to fix or lock-down more than one of these elements. Let's take a look at how it typically works when you try to fix two of these components.

Fixed Scope and Cost

Fixed scope and fixed cost is a recipe for an agency going upside down on nearly every project. Most agencies run on margins that are too tight to make this workable. The agreements look something like, we will build large list of features and the price is X.

If you are a buyer and have an agreement like this with your agency, you'll be in relationship counseling with them before the end of the year. There is of course a honeymoon phase where the agency is amicable about building all of the features, no matter the timeline, up until the margin vanishes and the project turns into charity. The reality is time and cost have some relationship to one another as most employees are paid based upon time. Some agencies pull this off by virtue of dirt-cheap labor, but I've found that just prolongs the inevitable.

Signs that your agency's margins are vanishing are:

• Communications slow down or become irregular.
• Releases become less frequent.
• Development feels slow.
• Discussions of phase two are initiated.
• More bugs seem to be introduced with feature releases.

If you are in this situation it may be tempting to drag your agency through the mud and force them to make good on the contract. However, at some point you will need to accept the contract was doomed from the start and the agency is being forced to find a new project, hence the slowdown in yours, to pay for the losses they are incurring. This isn't a good relationship for either of you, nor the long-term health of your project, which is mounting lines of untested spaghetti code like elephant shit in a three-ring circus.

When customers come to me in this situation with their existing agency, my first remedy is not to switch agencies to my team, much as I would love to earn the new business. The best advice I can give is to get on the phone and get into a phase two with fresh budget so you can salvage the codebase. This is usually painful for the stakeholder, but the long-term consequences of allowing trash code to pile up under conditions of haste may put you in the position of needing to re-write everything. You should both take the lesson on the chin and make sure for phase two you try not to fix both budget and scope again.

Fixed Time and Cost

Fixed time and fixed cost appear to go hand in hand, because time is money, and labor is typically paid by the hour. However, there is a subtle variable that many often overlook that separates the two. The cost will determine not just the timeline, but the experience and quality of the team and the experience of the team on the project. The experience and quality of the team become huge factors when it comes to their ability to meet a deadline. Fixing both of these can often leave a project understaffed or lacking the experience necessary to get the thing done on time.

Signs that your agency is blowing the budget and risking the deadline are:

• A new developer is being introduced to the project.
• A bunch of new developers appear to be swarming your project.
• Requesting more budget for additional team members.

What tends to happen in these situations is when it appears that the deadline is in jeopardy, the agency will often swarm the problem, throwing more developers on the project in an effort to move things faster. Unfortunately, as has been classically observed in The Mythical Man-month, adding more developers to an already behind project leads to the project getting even more behind. This is because the existing team needs to ramp up the new team on this new project, which further slows them down, as well as there not being enough isolated work streams on the project for all the new developers to be effective without tripping over one another.

This leads to a rapid depletion of budget, creating the agency as charity situation observed when we fix scope and cost. The relationship declines, and what gets released is typically late or riddled with bugs from hasty execution.

If you have found yourself in this situation, my advice is typically to figure out if this deadline is truly a hard deadline. In my experience the only hard deadlines are holidays and events. Christmas, Black Friday, the New York City Marathon, and the Super Bowl are not going to be delayed because of your software project. So short of this, as a stakeholder, you'll need to cut your agency some slack here because the quality of the software shipped is often greater than any self-imposed deadline. For example, the marketing team wanting to run a campaign on a specific date is not a reason to ship shoddy work. These deadlines can be moved, albeit begrudgingly by the disconnected team, but we are all humans here trying to do our best work, have some empathy.

If we are looking at a true hard deadline here, then we have no choice but to speed up the project. By the time you are here it's likely not going to be able to be remedied by throwing more money or people at the problem. The best thing to do here is to aggressively slash features or trim back the expectations such that you can get the software shipped at the highest quality possible by the due date. This may mean you get 100% of what you need but only 80% of what you want, however, this is more desirable than 100% of what you want functioning 80% of the time.

Fixed Time and Scope

Fixed time and fixed scope typically goes awry when the feature set is too rigid or too large as envisioned. As we have observed above, throwing more money and people at a project that is already behind won't work. The best thing do do in this situation is to look to trim scope by cutting features, seeking third-party integrations and libraries, or pairing back design requirements. In order to hit a hard deadline like this, scope is the most important thing to make malleable so engineers can explore alternative avenues to deliver the value desired by the end user, on time.

The signs that your deadline is going to be missed are the same as fixed time and cost projects, where you're seeing new teams or staff being introduced to the project. This is likely because you have a large or flexible budget. However, you've been given the wrong instrument to rectify the problem. The only way to get to on time delivery is often by way of scope not budget. So all the money in the world won't save you unless that money is going to buy something that's already built and can be licensed to you.

This Is The Way

via GIPHY

You can see that when we become rigid on any two axes of this triangle we jeopardize the delivery of the project. But let's dig into why it works out when we fix just one value and are flexible on the other two.

Fixed Cost

Fixed cost if typical of larger, enterprise organizations. I've found that when things live and die by the finance department and the budget set out at the start of the year, this is really the only way to do it. In this case you need to have flexibility in timing and in scope so you can find a way to fit the value you're looking to deliver within budget.

Tools a developer might use to do this are off-the-shelf solutions that can be molded or modified to fit the use case. We can also find ways to trim back or creatively implement features. We also may do a more rigorous value proposition evaluation on the features desired. Use the 80/20 principle, it's usually 20% of the desired scope that delivers 80% of the value. So focus on those features first so you're delivering maximum value early on in the project, making the tough, scope-cutting calls less difficult by leaving the nice-to-have's for the end.

In these types of organizations there's usually a clear monetary target to hit in terms of value. Goals of the project usually sound like like:

• To improve operational efficiency by X%.
• To lower the time it takes to perform a task.
• To eliminate costly staff that are doing a manual task.

You need to focus on the features that can deliver on these cost or time savings promises first and be willing to trim the nice to have's for a later date or when more budget can be unlocked. It's often helpful to time-box your designs and to keep it simple for your version one. Many rough edges in terms of user experience can be rounded out later, and by getting the software to users sooner, you'll learn about use cases you hadn't considered prior.

Fixed Time

When it comes to being flexible on time, I always recommend having a deadline in mind, because this always helps center everyone on the project. Flexible doesn't mean infinite but there are projects that have true drop-dead due dates. As explained before these are usually holidays or events like Black Friday, Cyber Monday, or a Concert. In these cases you're going to need to be flexible on scope and on budget to achieve the goal.

With these projects we're looking to staff with top talent right from the start. Let me repeat that again, you're going to staff with top talent right from the start. These are teams of seasoned designers and engineers that know how to build a quality product fast. This type of talent won't be cheap, but they will be masters of their craft. If you try to do this after the project is already behind, it's already too late. There's a ramp up time for any team-member, even an experienced one. If a sufficient amount of poor code has been written, even the most experienced team will struggle to recover the project before a tight deadline. So don't skimp here, get the team right the first time and be ready to pay for it.

It also requires being flexible on scope. If you have a strong team and things still run behind you need to be able to trim back on features that are eating up time. A great team with a lot of experience is going to know where these skeletons are hiding before they start implementing them. If you have a lower cost, inexperienced team, you run the risk of finding out a key feature isn't possible in the timeframe too late in the process to react to it. Experienced teams have confidence in their abilities and their recommendations. They thrive on puzzles like these and are going to understand the stakes early and not be afraid to tell you when something needs to change to make sure you never blow a deadline.

Fixed Scope

Fixed scope tends to be the thing people most ask for, but is actually the rarest need in reality. We have some clients that come to us with baked out designs, entire technology architectures, and a suite of tools and services they want to use for every aspect of a project. If this solution is not already in use by the client in some other form, scope is usually far more flexible than it would appear during the initial discovery.

Most of the time, all this scoping is used to open up a fixed budget discussion. But if you're not careful, you may get coaxed into fixing BOTH budget and scope. Signs this is happening to you is they want to attach these documents to the contract. It's important to remember that having goals for the project is not the same as scope. Goals are important, but how we get to those goals is the scope. Most people conflate the two and undergo excessive scoping to obtain more accurate price quotes. We've already seen above how this ends up.

Where fixed scope might be the reality is when you are re-building or replacing an existing solution. In these cases the client knows all the features their team needs and is actively using, but there are other issues that are leading them to re-build. Typically the existing solution turned into a big ball of mud that is hard to modify and extend. Feature development slowed and seemingly simple things are taking too long to implement. Maybe the user experience is poor and teams are struggling to use the software as well. In this case, the feature set is known, but the goal of a re-write is a good user experience with clean, extensible, well-tested, and architected code.

This is why a flexible timeline and budget are important. If we start to add time or budget pressure to this project, you may end up with frantic developers cutting corners to deliver the project. This can put you with a brand new code base that will run into the same extensibility problems as the previous one. You delivered the scope, but missed the value. You had plenty of scope but didn't focus on the goals. By being flexible on timeline and budget the project is staffed with the experience it needs, and developers have the time they need to write our proper test suites, documentation, and craft elegant abstractions that will enable faster development well into the future.

Conclusion

As an agency, it's up to you to try to uncover which of these three components is most important to a project. Most people are not familiar with the pitfalls of software development. Because building software is such an abstract and intangible experience for most clients, they'll often try to apply the principles of building physical things to the development process at their own peril. It's easy for us as agencies to give in to these terms in the desire to secure the deal, but we end up with burnt bridges, lost profits, and broken products.

via GIPHY

"Your scientists were so preoccupied with whether or not they could, they never stopped to think if they should." -- Dr. Ian Malcom, Jurassic Park

If the client only has a set budget for a project set down by the CFO, then the decision to fix the budget makes sense. If the solution is built for a major event like the World Cup, Election Day, or the US Open then you fix the timeline. If we're doing a rebuild of an existing solution that needs replacement then fixed scope is the way.

When it comes to seeing clients that are currently experiencing the pain of naive engagement terms, my recommendation is to be flexible before firing your agency. Guide the conversation toward recovery and come with this knowledge to correct the mistakes of the previous engagement. You may require experienced leadership to help the existing team or set up a plan for transition, but letting the existing work fall into disrepair is the least desirable outcome. Protect the investment by being flexible and empathetic to the team.

We strive to have an offering for every project for each of these three situations depending upon the client's goals. Being flexible in how we engage is the best way we can offer the most value as an agency to the most types of clients. This is also good for the client as they have the right expectations set up front with the value desired delivered in the end.