In my previous article on project budgeting, I discussed how difficult it is to estimate a software development project budget beforehand. Here is where a serious disagreement between techies and finance guys arises. Far too often, a project manager and a CFO have completely different views on budgeting: while the former understands risks and the necessity to assess them, the latter just wants a fixed budget. However, all budgets are based on forecasts that typically involve some degree of uncertainty. No approach guarantees 100% predictability when it comes to innovative solution development. In today’s volatile tech industry, changes are very likely to happen: markets evolve, new trends emerge, and consumer preferences shift. Thus, project goals may be reformulated, requirements may (and will) change, delays may occur—and these are all risks we must consider and manage.
Requirement Changes
The simple truth we have to accept is that requirements change. Evolving requirements are natural for software development projects. Nevertheless, real life has shown that 95% of clients do not understand it, and when they face the need to scale the budget due to new project requirements, they are clueless. Meanwhile, it can increase system-level project costs by 20% and enterprise-level project costs by a minimum of 100%. And in mobile or UI/UX development, three times budget escalation is often treated as “at least” three. Yes, you saw it right: +300%. Why so much, you ask? Well, perhaps because of UI mockups…
To continue on the topic of change, I have to mention Agile. In trendy Agile, change is happening continuously. It is expected and welcomed as a way to fix mistakes early and deliver faster. Everyone wants Agile to increase the speed of software delivery, but some organizations suddenly find themselves unprepared for Agile approaches. On the one hand, Agile requires high customer involvement (e.g., a Product Owner who is accessible for the development team 24/7), and some customers can hardly provide that. On the other hand, Agile means you embrace change, and change means risks to manage. Moreover, Agile implies many demos to clients, usually biweekly, and it is not just to say that Auriga has done several new things and they are functional but also to get extensive feedback during the demo (or several hours later): What was good? What has to be changed? And what are the next short-term goals? Otherwise, we may observe a good example of the SNAFU situation: it works and meets the requirements, but the customer is not happy with the results.
As an experienced provider, we always explain this to our clients. In the project budgeting stage, we make sure that the customer sees change as a risk and allocates enough budget for risk management. By doing this, we take a big risk ourselves: the client may go to another provider for a cheaper alternative (this has indeed happened, but not once have such clients come back in half a year complaining about unjustified expectations). At the same time, if we do not consider the requirement change risk from the very beginning, a conflict will definitely arise later and grow like a snowball rolling down a hill.
Broken External Dependencies
Obviously, an engineering team does not work in a vacuum; it collaborates with (and depends on) the customer team and various departments, vendors, suppliers, partners, etc. In this complex chain of interdependencies, it is highly important that all the parties perform cohesively. When we integrate one system with another, for example, we need this system to be prepared on the client’s side. The client’s IT department should give us the logins, deploy the systems, update the servers, etc. But we work with people, and people may forget, lack time, or simply be unavailable.
Broken deadlines and delays are inevitable, regardless of what anyone says. As a rule, this schedule risk increases project costs by 20% to 30%. That’s why we always ask customers to prepare the ground for the project 1–2 months beforehand. If the risk still occurs, we try to mitigate it and avoid downtime by working on some other project tasks, though it usually resembles building a house without first constructing its foundation—not the wisest idea at all.
Lack of Strategic Vision
Many state that Project Managers are useless in Agile. The SCRUM methodology, they say, involves a SCRUM Master and a Product Owner, and there is no place for a Project Manager. But let’s dig deeper. If you develop something, it implies something “finite” and countable in terms of time, budget, quality, etc. Thus, we can observe various deadlines and limitations. Who will be responsible for meeting them? Technically speaking, it will be the Product Owner.
Here, we see a huge risk: Product Owners understand their products pretty well; however, they have little experience with software product development. Most Product Owners sincerely believe that, if all MVP features are developed, we can upload a software build to the Google Market. But what about regression tests and security testing? How much time will they take? A couple of weeks? And how many rounds? And what about bug fixing? Too many questions arise.
In a good case, you miss the deadline by a couple of months, though the typical story is even scarier: a software product does not have the synergy between the set of flawlessly implanted user stories and, thus, it is almost useless. Why? Because nobody cares about that! There is no such person or place in Agile. But every project on Earth involves tactics and strategy. You can win the battle but ruin the campaign. Someone (and we believe that “someone” here is an experienced Project Manager) must be responsible for the strategy or the whole project may be lost.
To sum up, software development projects are rife with risks, whether we like it or not. In this short article, I mention only a couple of risks that are often underestimated by customers but affect project budgets significantly. Of course, there are many other risks: strategic, operational, technical, and so on. Don’t hope you will be so lucky to avoid them, and don’t ignore them at your peril. Look them straight in the eye and take care of them beforehand! Allocate the appropriate budget, time, and resources to risk management and cooperate with trusted and reliable providers to mitigate and minimize risks.
