Development
06.11.2024
Why it is sometimes impossible to accurately calculate product development costs and timelines
Analyses based on the VUCA concept and early project planning phase
Developing digital products from scratch is often a complex and multifaceted process, in which forecasting deadlines and costs is almost always a challenge for the team, both on the client's side and on the contractor's side (we're not talking about one person here, but a whole team of designers, developers and projeccts). Planning and timeline calculation is accompanied by a high degree of uncertainty just in the early stages.
Early stages refer to the many options, ideas, and directions a project can take while the product is still undefined. This early stage is often referred to as the ‘fuzzy front’ because of its uncertainty.
Most of the difficulties faced by developers in the early stage of product design can be explained using the concept of VUCA, which combines four key aspects: variability (Volatility), Uncertainty (Uncertainty), Complexity (Complexity) and Ambiguity (Ambiguity). In this paper, we want to convey the idea of how each of these dimensions affects the ability of implementers to accurately predict product development costs and timelines. We have chosen to rank these aspects in descending order based on the predominance of one aspect over the others.
1. Complexity of the product architecture
Let's start with perhaps the most key reason why forecasting development costs and timelines can be a difficult task - the high complexity of the project. Product development often involves different modules, platforms, and technologies that must work together. Each modular system requires careful design and integration, and increasing the number of interconnected components leads to increased complexity in the development process. This increases the risks of unaccounted for problems that may arise at later stages: Module incompatibility, the need to make adjustments, product customisation or even complete redesign of parts of the product.
When the product architecture includes many components and degrees of freedom for different configurations, accurate planning can become particularly difficult. The development of modular systems involves the need to make trade-offs between standardisation and individual customer requirements. Increasing the number of product variations increases the likelihood that unexpected problems will arise during the design and assembly phase, resulting in increased development costs and time. Changes initially planned even as minor often result in the need for significant rework of other modules due to their interdependencies.
If the product architecture does not allow for easy changes to individual modules without affecting the entire system, accurate early planning is not possible.
During product development due to limited budget, it is also worth mentioning the problem of balancing internal and external goals.
Example: the implementer tries to fulfil all customer wishes (external goal) at the best price, but tries not to create too many individual solutions or variants that could affect the entire architecture (internal goal) and thus increase the internal complexity and costs for both the company and the customer.
2. Ambiguity and Communication Difficulties
Ambiguity often arises when different members of the development team or clients have different interpretations of the project requirements and goals. For example, a client may provide a ToR that is perceived differently by different team members - developers, designers, managers. Differences in interpretations are quite normal, which can occur within the team, and these differences then have to be harmonised, which of course takes time..Although there may be differences in the definition of requirements, they do not arise mainly due to lack of information on the part of the client, misunderstanding on the part of the developer or misunderstanding between them. Rather, the reason lies in the deliberate withholding or withholding of information about the prioritisation of objectives in order to leave room for negotiation.
3. Uncertainty in the early phase
Often at the initial stages of development it is not clear which functions or modules will be demanded by end users. In such circumstances, implementers are forced to make decisions based on incomplete information, which leads to the risk of planning errors.
The process of gathering requirements from customers at an early stage can also be difficult due to uncertainty in customer expectations. Customers are not always able to clearly articulate their needs or may change their requests during the development process. This leads to the need for frequent changes already in the design process, which increases the development time and introduces additional costs.
Often some requirements are not identified in the early phase, but invented in the process by the designers themselves
4. Volatility of the market and requirements (Volatility)
This aspect prevails much less frequently, but still it should not be forgotten. This applies most often to long-term projects. Markets and trends can change quickly, and what was relevant at the beginning of the project may be obsolete by the time the product reaches the market. This variability affects customer requirements, which in turn requires changes in product development. For example, a company may start a project with one set of features but discover during the development process that other features or improved features are needed for market success.
Changes in customer preferences, legislative innovations, or the emergence of new competitors can dramatically change development priorities. For implementers, this means having to make changes to a project that has already been thought out and started, resulting in a recalculation of time and cost. As we mentioned earlier, the degree of modularity and the ability to make changes to the product architecture directly affect the ability to adapt to changing conditions. If the product architecture is too rigid and does not allow for changes, it can lead to significant delays.
To summarise the above, no longer relying on the aspects above, let's not forget about such a thing as the human factor. Even despite the competence and level of the performer, there is always a chance of errors: an employee missed a small detail in the TOR, motivation of the team, resolution of both external and internal conflicts. All this can overlap on top of the frequently occurring aspects described above.
How do you buy mistakes on a project if you're already out of budget and on time?
1. To begin with, it is worth deciding what is a higher priority for the client: deadlines or budget. If deadlines are burning, then at any time to attract additional staff, but this of course leads to additional costs, as no one wants to work for ‘thanks’.
Here it should be added that if the customer wishes or other circumstances, another team can be additionally involved as an executor.
2. We at Labpics like to use the concept of Time & Materials to calculate additional budget beyond the originally planned budget.
The Time and Materials (T&M) concept is a pricing and project management model in which the client pays for the actual time spent by performers (designers, developers) at a fixed rate per hour instead of a fixed price for the entire project.
This concept helps to give the client a more transparent calculation of the budget and additional work performed beyond the main budget. The T&M concept is especially useful for complex or uncertain projects where it is difficult to accurately predict all the details in advance.
This model is also suitable for projects where unique and innovative solutions need to be developed. Especially for clients who do not fully know what they want at the beginning.
3. Providing daily reports. When the project has already gone a bit off track, the work can be optimised by more frequent reporting on the part of the contractor. It will be easier for the client to change requirements as the project progresses, adjust the scope of work and adapt to new circumstances.
4. Of course, you should not forget to use such a simple and free tool as an open dialogue between the two parties. If a dispute arises, it is always easier to openly discuss the problems with the team and the customer to agree changes in the plan and, if necessary, to revise the budget or deadlines.
Conclusion
To summarise the above: predicting the exact cost and timing of product development is often an impossible task due to many factors that are difficult to take into account in the early phase of a project. The VUCA framework helps to better understand why planning in a development environment is sometimes difficult.
Companies facing high levels of complexity, uncertainty in customer requirements and changes in the marketplace must be prepared for the fact that development may take longer and require more resources than originally expected. It is important to recognise that managing projects from scratch requires flexibility as well as the ability to adapt quickly to changing conditions for both the implementer and the client. The sooner both parties recognise these issues and integrate mechanisms to mitigate them into the planning process, the better they will be able to meet the challenges of the development process.
With this article we want to convey the message to our current, future or not at all our clients that there are many factors that depend not only on us, but on different circumstances. Even by setting earlier deadlines and budgets at an early stage - we can't always guarantee to hit them 100%, as many unforeseen things can arise while working on projects. We always try to do more than we promised and we always prioritise giving a quality and maximally satisfying product to our clients.
If you want to learn more about the concept of VUCA and real studies based on it, you can read this article.