TLDR: we’ve found that combining the best parts of Waterfall and Agile allows us most success in estimating our projects.
Over the past 3 years I’ve started a consulting company in Austin, TX and being a small, lean firm our survival is tied to happy customers. Let’s face it, avoiding budget surprises is key to customer (and stakeholder) satisfaction right behind deadlines, quality and professionalism. However, anyone who has worked in software for any amount of time has probably seen most of their projects fail when it comes to budget planning. It’s notoriously hard to get right without sandbagging. However, sandbagging in the consulting world, apart from being dishonest and unprofessional, will also cause you to loose bids as you will be over charging. Getting budgets numbers right was something that we knew was critical when we were starting our company and it’s been one of our core corporate values and areas of focus as a result. We have had success on enough projects now of different sizes that we feel that we have found a recipe for success and I wanted to share that recipe incase it’s helpful to others.
Starts with a dirty word?
Waterfall… There I said it. Now before you click away, know that we use both Waterfall and Agile on our projects because we need to take advantage of the strengths of each approach. Waterfall for all of it’s faults allowed for accurate budget and release planning. However, when it comes to building software efficiently and making sure you are building the right thing, it’s hard to beat an Agile style processes.
Why is Agile bad for budgeting?
Whether you keep it casual with Kanban, go all in with Scrum or like to keep it old school with XP the tenants of Agile offer a lot of benefits around being lean and… well, agile. However, as any experienced developer knows, nothing is free in software development and the tradeoff you pay to get the benefits of Agile is budget accuracy and this is why.
Agile is evolutionary but budgets should be static
Idiomatic Agile uses historical data to calculate velocity. You start with relative complexity estimates using points and then map points to hours over time measuring your velocity. This works great if you are 1) disciplined 2) have a stable team 3) can wait till after you’ve started development to know how long the project will take. However, if you are bidding on a project that is 5 weeks long or if you need estimated number for a proposal then you can’t start development before you provide a cost estimate.
You can’t measure what you can’t see
I’ve been on a lot of projects and the best Agile teams I’ve worked with had maybe two sprints of story’s ready in the backlog. If you don’t know what you are going to build beyond the next month then you definitely can’t estimate accurately beyond that point.
But how does Waterfall help?
We’ve found that the key to our successful estimation lies in starting with wireframes. Take the time to use your favorite wire framing tool, we like Balsamic, and sit down with your stakeholders and talk through how the software will work and flesh out the UX.
It doesn’t have to be pretty, in fact we prefer that ours are ugly as it will force stakeholders and everyone else involved to focus on UX and features instead of graphic design and UI. The wireframes just need to disambiguate what’s going to be built.
At this point you might be saying, well that’s not really Waterfall and maybe you’d be right, there’s a lot more to Waterfall than just having a plan in place but taking the time to create a plan is definitely more of Waterfall style approach than Agile style approach.
Isn’t the UX just the tip of the iceberg?
I’m sure some of you are noticing that this wouldn’t work on all projects. The UX could very well be the tip of a very large iceberg. If your UX is sitting on top of a distributed architecture like CQRS or represents a view that is doing complex BI manipulations that will require some backend muscle to preform right then you will need more than wireframes. However, for the majority of the Modern Web projects I’ve been on this isn’t the case. Most of our projects we work on can be accurately estimated from wireframes.
But the initial estimates will still be wrong
Yes, your initial estimates absolutely will be wrong. I don’t like to talk bad about my people but programmers are terrible at estimating. This phenomena is the problem that measuring velocity with Agile helps mitigate over time. However, like most problems, the key to solving a problem is admitting that you have one. What we do is to quickly estimate in ideal hours knowing that these numbers are wrong but also knowing estimating this way quick allowing us and our our clients to be lean. By going into this knowing that we are usually wrong by 20% we can account for this known unknown by creating a 20% budget bucket for ideal hour errors that we only use for these types of estimation errors.
But requirements will change
That’s right and it’s hard to hit a moving target. You know that as you develop the application you will realize that you forgot about user roles or that business rules will turn out to be more complex that you anticipated or that the stakeholders will simply change their mind a few times.
Put the couch over there…
Actually, move it over there…
You know, I think chairs would be better…
We know this is going to happen so plan for it. We put 30% budget bucket to allow for requirements related directly to the wireframes to evolve a bit over time and then bill those kinds of estimation wiggles appropriately.
But isn’t this just sandbagging?
No, because we aren’t excessively padding to set a false expectation with the clients, we are using historical averages to account for known unknowns. We have found that if we start with wireframes then the known unknowns becomes more predictable.
Where does Agile fit in?
Once we’ve sized everything out then we can use Agile (we prefer Kanban) to keep things lean and maximize the ROI for stakeholders. We create a backlog. We use GitHub with a fork pull request model to allow for easy code reviews. We rely heavily on frequent demos to show progress and lighter on excessive book keeping. This whole combination allows us to be reactive and Agile while still maintaining good code quality and most importantly while staying on budget. Every team is different and I’d encourage you to take advantage of Agile’s notorious flexibility to customize your process for success.
But what if the project is big?
If you are looking at several hundred hours to develop wireframes then what? We’ll for one you start to appreciate that this really is Waterfall and more importantly to realize that you have one viable option under this approach… breaking the project into phases. A discovery phase who’s deliverables are wireframes and a product phase who’s deliverables are the product.
But what if you need a deadline?
Deadlines are expensive especially for large projects. We usually recommend against them for most of our clients. However, sometimes they are unavoidable. My recommendation for larger projects with both budget and deadline sensitivity would be to create one more budget bucket for deadline risk. We haven’t done this yet, but my best guess would be that you’d want another 30% to play it safe here and this would probably line up real well if you were being held to a fixed fee bid.
Won’t the time just expand to fill the space?
Depends on if your team is lean and hungry or not. If you’re not working with a highly motivated team that gets satisfaction out of succeeding then this might not be a good approach for you. Our experience is that our clients budgets are what they are and the more value we put in their budget the more business they will send our way. We want to stay in business and being small word of mouth is king and that’s where we found our motivation but every team is different. Instead of hitting our budget we like to focus on trying to get the client as many extras as we can with in their budget if things go well. You won’t run out of ideas on how to make the product better and if your showing constant progress your clients will likely be happy to get some more features than what they initially planned within the budget.
But what if you get it wrong?
For smaller projects, it’s pretty easy to succeed with this formula with a motivated team. For lager projects it’s much harder. So how do you deal with getting it wrong because at the end of a day it’s still an estimate based on unknowns and averages.
The way we deal with this uncertainty is by doing frequent project demos and rolling into our demo’s a review of the budget numbers. What could be more important than keeping an eye on if your on track for the projects budget? If you do this as part of your demo ceremony then you will know earlier in the project if your at risk and can have conversations around scope and budget earlier in the project when the stakeholders still have an opportunity to decide if they want to cut scope or reconsider the budget.
We generally find you can do one of the following things if you see that your project is at risk:
- find some gold plating items in scope that can have their priority adjusted
- find more cost effective creative solutions and acceptable work arounds for some features
- find motivation in just knowing that your at risk to help increase or maintain velocity on long projects
You will always be in a better position if you come to your clients early with options and let them guide the outcome.
Wrapping it up
Our recipe for successful budgeting is
- Create wireframes
- optionally make this effort a seperate discovery phase - Estimate in ideal hours
- Budget for known, unknowns
- ideal hours
- requirements wiggle
- deadline risk - Run you project using some type of Agile process
- frequent demos
- show budget progress in demos - If you run into problems before your out of budget look at options
- adjust scope
- consider alternative solutions or work arounds
- reconsider budget
- empower stake holder to control the outcome
