Estimation of Business Central projects:
agile vs waterfall

July 19, 2021

The transition from waterfall to agile:
Global Mediator’s reality

Global Mediator’s determination to deliver state-of-the-art solutions and meet customer needs is unchanged, but over the years our approach towards project management has changed. Once many projects were waterfall-model based, but as we shifted away from NAV upgrading services and evolved into a Business Central software engineering houses our methodology changed.

A few years ago, providing a precise estimation for a fixed-price project was pretty easy: the project scopes were quite similar. Analogous estimating used to take a couple of hours to refresh memory with Excel sheets for any previous project to provide an estimation for a new one.

Since Global Mediator focused on Business Central software engineering, Power Apps development and .NET core development instead of upgrades, the analogous technique is now barely an option for the Business Central projects. With technologies getting more sophisticated, architectures getting more distributed, and the customer getting thirstier for expressing business processes in multiple applications, even with Business Central customisation, the approach to the detailed project estimation has become more complex as well.

We simply had to become much more agile as this leaves room for adjusting to the customer’s requirements along the development process, as the customer’s vision of the solution might be feebly known at the very start of the projects. It does not make the development team’s life any easier, turning the assessment process into an intricate task sometimes, but still driving to a high-quality result in the long run.

So, adopting agile as the core development model, Global Mediator centred on good ballpark estimations to get the general idea of the project scope and see the destination point. Among others, the development teams tend to choose the following estimation techniques for Business Central development and customisation project timelines:

  • three-point method – to ponder over the pessimistic, optimistic and the most likely scenario and discuss the buffer time;
  • planning poker – a gamified way to reach a consensus considering the effort evaluation with anonymous voting cards;
  • dot voting – as a quick remedy to prioritise the activities that require assessment: the more dots the activity receives, the more complex the task is.

The paradox is that ballpark estimation does not prevent Global Mediator from meeting customer expectations better, as practice shows.

“Dancing with the customer’s needs and visions is probably the greatest challenge of agile estimation. Nevertheless, Global Mediator’s experience and flat organizational structure without unnecessary middlemen turn that challenge into the leverage that drives the results and helps manage customer expectations, which increase day by day.”
Nicolai Krarup, COO at Global Mediator

Letting the team play

So, how come a ballpark estimation work for a Business Central development organisation? In our case, it is all about involving the customer in the development process and having a meticulous, granular conversation. Our software engineers care about the result they are responsible for and its value to the customer. The customer-oriented approach and no middleman structure push them to seek answers to the right questions and make the assessment phase insightful. The answers influence the solution and fully reveal the customer’s preferences, helping the engineers to make the right ballpark estimation and elaborate it in due course.

Thus, the helicopter view and ballpark estimation at the start of the project turn into detailed planning along the way. The process nuances may vary but the key steps usually look as follows:

  • The preliminary estimation phase implies discussion: the team is asking relevant questions to get the necessary insights on the possible project strategy.
  • During phase 1, the team prepares the collaboration requirements draft.
  • The aim of phase 2 is to provide the proof of concept for the customer.
  • Phase 3 focuses on selecting ideal cooperation – a dedicated team, project work or managed services, depending on the project complexity.

To keep the estimation deviation low and deliver the best possible result within the deadline, we negotiate the subtleties like machine time, the tools that the team uses during the SDLC, as well as the QA team efforts. The whole team is always engaged in the assessment process – they share the handson experience, negotiate responsibilities, make an impact, and strive for the best result.

“Good estimation is a team game. Let the team – the development and QA engineers, team leads and customer – talk. Here lies the truth – in discussing options.”
Evgeny Buriak, Delivery Director at Global Mediator

To a certain degree, agile complicates estimating development processes like data migration and software integration since they imply rebuilding the missing elements or creating new ones, which is always a tailored solution. Either way, a correct estimate and, eventually, a successful project boil down to getting answers to the right questions and discussing details with the customer and within the teams.

Moving from developers to troubleshooters

Due to the practice of ongoing discussion during the development project at Global Mediator, the move from waterfall to agile planning pushed back the task-by-task assessment. The estimation has evolved from a separate discipline into an integral part of the continuous development and improvement process.

Global Mediator empowers its software engineers to think outside the box and discuss timelines, track and integrate feedback, analyse and suggest better options where available. We have shifted developers to a new level of responsibility and decision-making – we have made them the technical consultants that develop, the real proactive troubleshooters. Individual developers are now the ones who estimate and stick to their evaluations, drive the results, and meet customer expectations. Teams indicate when a better solution is possible, they share their experience in evaluating tasks they had not previously performed. Our software engineers do what they love most: stay focused and provide objective opinions to deliver tailor-made solutions in a timely manner.

Want to be the first to receive our updates?

Insights directly to your inbox

Stay tuned!
Subscribe