"How Much Will This Project Cost?" — Part 1
by Dave Westbrook,
It's the one question common across all projects and, as you've probably guessed, there isn't a simple answer. In fact "how much is this project going to cost?"—or one of many variations—is often one of the hardest questions to answer definitively in software development, especially during the initial stage of project discovery.
Each project is unique in scope, the objectives it sets out to achieve, and for a whole variety of different considerations. Frequently, a seemingly straightforward project is more challenging or technically complex to deliver in reality and unexpected challenges will inevitably arise along the way.
Also, no two people are the same—clients, developers, users—each stakeholder will bring their own knowledge, expectations, and values to a project.
While we pride ourselves on our ability to deliver quality outcomes for our clients at speed, costing projects is often the biggest challenge we face.
What Makes Project Pricing So Challenging?
This can be broken down into a few different reasons...
It is often the first thing we're asked, but nobody knows all of the resourcing requirements before commencing a project. Our best estimate during the early stages is just that—an estimate.
It's highly likely that estimates will change over the course of the project as additional requirements come to light. This isn't necessarily bad—we can't ever know what's around the corner—so it's better to have a little extra padding for time and resourcing than hit a wall mid-project! However, expectations must remain realistic from the outset—it would be wonderful if every new idea was included without changing the original scope because it wasn't initially envisaged, however this is not practicable.
This is particularly prevalent in Agile development—where scope is the variable factor, rather than cost or time. Agile methodology is fantastic when executed properly and communicated effectively. It helps deliver outcomes which more accurately reflect the users' needs and, in our experience, will deliver greater long-term return on investment for our clients. But how does a variable scope sit within organisations more used to defined budgets and timeframes?
Let's consider a broad example—if your business needs change suddenly due to unforeseen circumstances, or focus groups suggest your user personas will want additional functionality than was initially covered within the agreed-upon budget, what will be included? What will be excluded? Whose problem is that now? How much more budget do you need allocate to pay for changes? These are all questions which can be hard to answer, especially mid-project—a time when you're already dealing with increased pressure from stakeholders.
If at this point it hasn't been made clear enough—costing a project is challenging!
It's not as simple as adding up the hours and multiplying by an hourly rate. Cost estimates are inaccurate due to their basis on assumption or through changing requirements, so there can be feelings of frustration which need to be carefully managed on both sides through an engagement.
In summary, project planning is pure Hofstadter's Law in action.
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Douglas Hofstadter, 1979
There's always a relevant XKCD. Source: https://xkcd.com/917/
What Can Be Done To Get More Accurate Cost Estimates?
That said, there are some steps we take to minimise our clients' exposure to certain pitfalls:
Resourcing By Skill Level
Every developer is different and we all have strengths and weaknesses which will affect how quickly we can complete a certain project. To minimise the impact of this it's far better to, where possible, estimate resourcing requirements broken down by skills and experience—considering, for example, tasks which can be accomplished by junior developers, or where investing in product management will reduce overall cost—so we can budget appropriately.
Estimating In Stages
When we quote for a project, we typically work with an estimated number of full-time equivalent (FTE) hours, days, weeks, etc. to complete certain features or functionality, broken down into stages, and further broken down in gates. This is great because it provides us with a way to easily calculate return on investment for our clients by looking at the expected time to completion throughout the course of a project. However, if the scope changes during the project timeline, so does our calculation of effort required to complete the project—and that's before factoring in any additional requirements!
Invoices are never fun to pay—nobody wants to part with their hard-earned cash without knowing what they're getting for it! The best way around this is by having a clearly defined business objectives for the project agreed upon at the outset. These objectives are different from the stages and gates mentioned previously—they are more akin to guiding principles which inform the decisions that need to be made about specific requirements and acceptance criteria if (and, more often than not, when) things change later on.
Stage and gate planning is made more resilient to change by accommodating ranged estimates of features and resourcing requirements which can shift according to how important they are for achieving business objectives.
Communication Is Key
It might seem obvious but we always communicate clearly whether there are any changes between iterations. Any deviation from the original request will affect your estimated cost or timeframe, whichever is more valuable to you right now. Up front communication requires effort but saves time in the long run—we want to get things right for you before we move forward, on to the next stage.
Ultimately, the aim of any engagement should be to establish trust, puts minds at ease, and provide confidence in what it will take to move a project forward.
In part 2 we'll take a deeper look at Datamango's approach to pricing, focusing on project planning applicable across all our solutions. Be sure to check it out and thanks for reading!
In the meantime, get in touch to start the process of bringing your software product to life.