Estimation in R&D and software development is hard. Agile methodologies provide some relief but are not intended for answering customers’ questions about final deadlines and costs of large projects.
So, how to go about this?
To increase the accuracy of predictions, teams usually believe they have to improve at making estimations.
While more experience, more time invested in preparation, and various planning methodologies may help, they might not be enough due to the complex nature of R&D projects.
Embracing the fact that estimations cannot be and do not have to be highly accurate is a liberating moment. It opens up various ideas on how to deal with uncertainty and surprises during the R&D process.
Now, let’s explore some of those ideas we’ve successfully implemented at Visage Technologies.
First of all, there is usually always some room to adjust the project structure:
→ Organize the work in multiple separate projects, if possible.
The first one will be an investigation phase, relatively shorter than the whole project and typically up to several weeks long. The aim is to invest more time in investigating state of the art, available data sources, feasibility, requirements, and resources before defining the parameters of the whole project.
In an ideal case, the customer will pay for the preparation project since the deliverables will be valuable, no matter whether they continue working with you or with another company.
→ Plan incremental proofs of concept and demos. It makes it easier to keep pace and show the progress to the customer.
→ Plan more minor phases.
→ Ask for regular feedback. Before the project starts, make it clear that the customer will be involved in the project so they can plan their activities and time. Be consistent in asking for feedback and actively keep the customer in the loop.
→ If possible, plan time for improvements after the delivery of each milestone and the whole project. There is a chance that the customer will have some comments or change requests.
→ Consecutive projects may be a good solution, closer to the agile approach. Start with one or more Proofs of Concept, continue with a Minimal Viable Product, and incrementally add or improve features.
Some customers may be less flexible regarding the project structure, but there are also a lot of possible adjustments to internal R&D practices.
→ Start by investigating state of the art, and searching for publicly available models, source code, scientific papers, and data.
→ Before going deep into R&D, make sure you understand the need and value that the project will bring. R&D engineers often aim at achieving performance comparable to (or better than) lab results from most recent scientific papers. That is sometimes necessary, but sometimes not.
→ Once the need and value are clear, translate the expectations to rough objective acceptance criteria.
→ Start with simpler models.
→ Start with less data.
→ If possible, ensure that each increment of work is demonstrable.
→ Stop when acceptance criteria is reached.
A good relationship with the customer is the main precondition for a successful project.
Some customers do not have experience with the agile way of thinking or with R&D projects in general. Therefore, ideas such as preparatory projects, incremental deliveries, regular feedback, or consecutive projects may sound abstract to them.
For that reason, it is important to actively work on the customer relationship from the first contact to the end of the project:
→ Act as experts and provide advice if the customer is struggling with the scope or requirements for the project. Make their decisions easier by focusing on value and influencing the decision-making process.
→ Start with clear use cases.
→ Do not be overprotective. The customer’s best interest is to get the project done instead of terminating it because of a minor problem. Therefore, showing the willingness to take some calculated risks usually benefits the quality of the relationship with the customer.
→ Be transparent, fair, and helpful. It makes everything else easier and provides a necessary foundation for a solid, long-term relationship.
While these ideas may improve project planning, customer expectations, and the overall project success, they may not be equally implementable in practice.
Customers may have their own preferences about the project structure, technical requirements may impose certain limitations (e.g., starting without data can be impossible), and business context may require certain legal obligations in contracts.
However, being aware of possible ways to deal with uncertainties in R&D allows you to choose appropriate and relevant practices.
Years of experience with various R&D projects have taught us that each project brings its challenges, but we should treat all of them with sincere dedication to the customer and the value that the project can bring to them.
Adapting project structure, improving internal R&D practices, and involving the customer, usually contributes to the differentiation between successful and failed projects.