How much does it cost to build a typical airplane? We can calculate this more or less accurately, as it is a boxed solution. But how much does it cost to build an airplane with a new physical principles engine made of uncharted materials and able to perform some pretty unusual functions, such as oil well drilling? That’s what project budgeting looks like in the software development industry.
In the ever-changing high-tech environment, project budget estimation is a challenging task. You may think that CMMI and Waterfall models help estimate costs precisely – yes, but only if it is the one thousand and first project of its kind and free of risks and uncertainties. Well, having a good project plan tells us explicitly how far we are from the ideal path – and this is good, but it rarely answers the very important question of “Why?” In real life, even Waterfall methodologies do not guarantee predictability, not to mention a dynamic Agile approach.
Looking at Waterfall
For some reason, many think that Waterfall implies fixed cost. Here, they mix the development model and the product itself, which in turn should have a predefined/expected cost, quality and time-to-market. In many cases, it can be fixed.
In general, conservative methods like Waterfall together with complex processes like CMMI, 62304, or DO-178B help us reach the endpoint faster and provide good chances of predefined quality, sometimes with time and very seldom with budget. And this happens, if the project is typical.
For Waterfall-type projects, the typical effort distribution is as follows:
- requirement specification – 10%
- software design – 10%
- software development (including unit tests) – 40%
- software testing – 40%
- testing (system testing, load testing, etc.)
- validation (checking whether the specification captures the customer’s needs)
- verification (checking that the software meets the specification)
- acceptance
Importantly, software validation and verification are rather difficult processes that may increase project costs significantly (and even double them in some areas). Moreover, in addition to software development as such, a project may include software deployment, integration with existing systems, maintenance, and support – and these are all additional costs.
When we develop a completely new, innovative solution,
- we have a Change Management procedure, which generally increases the budget, though if we have a Fixed Budget, the CFO usually never allows us to increase it
- and a Risk Management procedure (which includes Change Management as a major risk), which clearly states that we have to increase the budget by two to four times.
This is a challenge for us as a vendor, as we have to choose whether
- to show multiplier X with a high chance of losing the project (a customer hardly ever has someone on board to justify this);
- or submit the project with a small risk buffer and follow the exact scope to meet the budget and deadline – in such cases, however, Auriga is treated as “not flexible.”
Now you understand why it is so hard working without IT professionals on the other side. Quite understandably, CFOs want fixed budgets, though even a robust Waterfall model does not eliminate change. But what if we are talking about hip and trendy Agile development? How possible is it to estimate an Agile project budget?
Reconsidering Agile
One thing should be cleared up straight away – don’t go to Agile just because it is “Agile”! Take a closer look at your project first – will Agile really work for you, or will it cost you? It is good to remember that, generally, agile methodologies are appropriate and effective in two situations:
- A project implies research and development (R&D), i.e. innovative activities undertaken by a company to develop a completely new, technologically advanced product. Here, it is difficult to predict the outcomes: nobody can guarantee that the project will follow the pre-established plan and that it will give the initially expected result. Consequently, we have to consider many risks (including the change of requirements), which influences the budget’s inflation.
- A project implies software development for a rapidly changing (e.g., mobile) industry in the very short term (just a couple of months). In this case, technologies evolve daily, and we do not know where the market will turn tomorrow. Requirements may become obsolete very quickly. We have a general plan for the next month, but we cannot fix our workload as we have to be flexible in a volatile environment – and flexibility always costs more.
The often-missed revelation is that Agile projects will have plan and someone to help the engineering team pass a set of important milestones. Why? Because customers want to work with something functional right now – but not in the distant future.
The second (but no less important) revelation is that Agile requires a product owner on the customer side who is accessible for the development team 24/7. If you think you have one, then you can start thinking about Agile!
To sum up, an Agile approach has undoubted advantages: it allows flexibility, early feedback, and a quick response to sudden and unpredictable market moves. It does not allow us to fix the project budget, however, and, thus, requires strategic and experienced project managers on the provider side.
Deciding on Options
It is often difficult to estimate what budget and how much time should be invested in a software development project beforehand. Therefore, in many cases, we can only decide on the movement vector: a roadmap for the future project that shows us the major milestones and, at the same time, gives space for change and experiments.
While developing such a roadmap together with the customer, we define what typical parameters and feature sets are needed. This step is a MUST. We work on commercial products, and our software has to meet end-user expectations – and no, it does not depend on Agile or conservative development approaches.
For software development projects with an unclear risk level, we usually negotiate an MVP (minimum viable product) with a multiplier of 2 or more. If there are few risks in the project, we will do more within the same budget. If many risks appear, a client will gain a viable product anyway.
For highly standardized industries, such as healthcare and avionics, where you have basic (safety, security, compliance, etc.) and some additional requirements, we offer a “mixed” approach to budgeting and iterative software development model allowing regular releases and requirement clarification at any stage of the project.
In conclusion, whatever development model you choose, wise project management is essential to the whole project’s success. Every software development project is unique, and Auriga takes an individual approach to each customer, helping consider and lower risks and avoid mistakes in project planning and budgeting. What risks and what mistakes, you wonder? These are the subjects of my next articles, so read on to find out more!
