Case study: A story that ended before the beginning

This case study will be different from other case studies out there. It is not going to be as shiny and glorious, yet we think it's important and interesting to share.

Let's dive into it.

1. Request

The request came from a friend in Norway who had already been our client before.

The task was to make an integration between two apps. One of them was a massive web-based management system for administation and quality management - let's call it App A. The other was a mobile app which was made in a way that the user could collect data from a construction site really quick and effortless - we'll call it App B.

The integration was to push collected data by B into A for further processing.

2. Foundations

As Rocksoft, we formed a team responsible for development and then we had kickoff meetings with the client's representative.

We started testing both applications in the scope necessary for our integration. We took a closer look at the use cases that we were going to cover.

On the surface, the solution seemed to be simple. We needed to build a simple service that would be responsible for communication between the two systems.

After a deeper understanding of the systems and their capabilities, we discovered the main questions and points to pay attention to, such as: data synchronization, model differences, identifier mapping, resistance to failures of both systems.

After this diagnosis, we arranged meetings with representatives of both applications, with which the service had to integrate. The purpose of the meetings was to agree on the form of communication between the systems and to find answers to doubts and potential problems that resulted from the analysis.

3. What happened before the scheduled start?

After we had thoroughly discussed the most probable use cases with the engineers from both app providers, we communicated our POV on the complexity of the project.

It was Friday evening as we got a reply from the client. It said basically: "Hey, big thanks for the cooperation so far. The estimate is five times bigger than our budget. We have to stop the project until we find a paying client for this integration".

4. How can you avoid such misunderstandings (and disappointments)?

If you come to a software house with a problem and have a budget on this, communicate it right away. It applies both to agile and waterfall projects. Maybe the feature you want isn't as easy to implement as you think?

You don't have to be scared of revealing the budget to an agile team. If it's truly agile, you can stop the work at any moment.

If you need a fixed price, you'll probably end up paying more than needed because of the margin that a developer needs to add to every fixed-price-project.

But there's another article describing the two methodics: "Agile vs Waterfall".