Recently, we realized not everyone, or company, knows how to budget for a new software project. Coupled with the fact that people are almost always over-optimistic and software isn’t cheap, this is a topic that needs addressing.
Waterfall vs Agile
There are two bookends on the software development bookshelf. Waterfall and “Agile.” Neither are perfect and both have pros and cons. Why does this matter? You want to control costs. You want to get software that does what see in your mind’s eye. These two priorities conflict, at least in the real world.
On one end, you have Waterfall. This is the traditional method of doing projects. Set a scope, set a due date, set a price. Go! This way is great, right? You decide what to build. You get an estimate, or even competitive estimates. You set a due date so you know when you will have it. You set an exact price for all those details. Done! You hire a company to build it in 6 months. This is going to be great! But then 4 months in (after a good chunk has been built), you talk with another of your clients and they see it differently. Two weeks later you come to a new consensus. But your scope is locked with the price, so you have to do a change order or wait until delivery. If you wait until delivery, you won’t be getting what you now know is best. If you do change order on top of change order, life gets complicated and the price is now well over what you originally thought you were in for. To add insult to injury, the development team wants to buffer what they think it will take because they don’t know what will be encountered during the change. In other words, you pay more.
On the other end, you have “Agile.” Agile started out as a concept, but has transformed into a strict methodology. We are going to talk about it from the concept perspective. Agile emphasizes working software and human interactions. The point of Agile is that you, the customer, control exactly what is built and no more. This optimizes for a valid feature set at the end of the project. It hopes to cause minimal waste and deliver in the same basic timeline as originally desired. What this means is you don’t have to have the perfect answer on Day One for the whole project, you just need to know what is most important or foundational. Then you narrow in on the end result as you go. You might know the basic pieces or concepts of what you want to build but you don’t need to know exactly how you are going to do them. With an agile project, you will see progress along the way and be able to correct incorrect assumptions early - saving cost and time. Sounds great, but what is the catch? The risk is that it’s easy to want to pile everything into the initial phase as you start to see progress. In other words, without care cost can balloon and timelines may be extended.
Well how do you navigate this? It seems like you have 2 choices: 1) a most likely outdated or incorrect project/application or 2) a close to perfect solution with a risk of cost growth and a never-ending project.
Sounds like a dilemma! What do you do?
We find the risks of a waterfall methodology are too high for a whole project and are just not acceptable. As a service provider, we don’t want to take the blame for suggesting this. We prefer agile and to control costs and timeline by controlling what is built. Using “pure” agile is great for practice teams, and we are happy to accommodate this. However, for teams that aren’t composed of experienced individuals creating software products, we don’t like the “pure” approach.
Here is where we find a happy medium! Taking from the Agile methodology, we like to split work into “sprints,” meaning we divide work into small time-boxed efforts. For example, a 2-week sprint would mean every 2 weeks we, you and our team, will decide on a scope (set of features), define each feature, then plan and execute the specific tasks required for each feature. In pure agile, if the developers don’t get to something you just push it to the next sprint - no problem. Here is where we depart from pure agile and select exact features with a total fixed cost. This works because the enormity of the project is broken into a small, bite-sized, 2-week mini-projects. The end result of each sprint is carefully defined. You know what you are going to get and for what cost. And if you need to change something, you can change it in the following sprint, which equates to minimal risk on the features or quality side of the equation.
This is a compromise to be sure and doesn’t fit all projects, but it is a good option. Sometimes pure agile is the best for practiced teams to get both the best product and lowest cost. In the end, we want the best structure for your team.
You need to be willing to set budgets for each area of your project and know what you are willing to compromise on. The setting budgets for each area will allow you to decide what is important. If everything is important, nothing is important - so knowing your priorities are key.
You need to be willing to talk about details and designate a project owner with authority to make decisions. You can ask clients, partners, and other team members to act as stakeholders. In the end though, the project owner needs to be able to make calls and decide directions after negotiating and communicating with the rest of your team.
The project owner on your team will interface with project managers and project leads on our team in order to decide how to make the efforts match the budget. In our opinion, and experience, the strength of the project owner almost directly correlates to the success of the project. It doesn’t matter how well we (or any other team) does our job, you may not get what you want, in a timeframe you want, for the cost you want.
We only want to deliver what you want, and no more. We have opinions and experience to rely upon, but our project leads and project managers haven’t figured out mind-reading yet, nor are we the right people to negotiate with internal teams in your organization. We need you for that. And we need you to help us navigate those waters so we can deliver what you want and no more. This is important because we won’t just be asking questions about what to do, but how to do it and what it needs to look like. Those edge on subjective questions which require an internal advocate on your team if you care about those things. All of those things affect budget.
You most likely have multiple priorities or processes on a single project that need to be balanced. This is again why we need a strong project owner to make calls or decisions. While there may be discussion around how to do one particular feature, the project may be getting close to hitting a budget for one area of the project. The project owner to decide if we should take the utilitarian approach and finish the feature immediately, or choose to spend more time and budget completing the task. We support either position, but we cannot make that call in a vacuum, on your behalf.
Have an idea of what you have to spend
We don’t see it as our opinion to set budgets on your behalf. We may need to set realistic expectations with you and we may need to do some prototyping to find accurate estimates. All of that varies on a project to project basis. However, we see it work best when the client sets the budget, and we help balance the allocated budget between different priorities in the project. We often can expect to get X, Y, and Z done in a project for X dollars or less, but the fit, form, and finish may need to change based on the available budget and how close the side blinders are respected!
To have a successful project you need three things: 1) a project management process that fits your company and how you want to control costs vs quality 2) a project owner to communicate with project leads on a development team, and 3) a development team that listens and can execute.
- There are two extremes in project management: waterfall and agile.
- Waterfall has fixed costs, but the result is usually “outdated” immediately on delivery.
- Agile can be the most cost/time-efficient way to deliver a relevant result, but cost and focus need to be controlled closely.
- There are some ways to compromise between waterfall and agile.
- A project owner on your team is key and needs to be authorized to make hard decisions.
- Development teams cannot read minds, and need a project owners guidance.
We hope this article was helpful. If what you heard aligns with your values, let us know. We’re here to answer questions and help craft your ideas and dreams into realities!