The first step is always the hardest. Same for all IT projects; from not knowing what your client work methods are or how much they differ from yours and balance that relationship, what really makes the difference is a challenging and critical factor: adaptation.
November 5th, 2018. A rainy day in London, what else? We had this new client that wanted to create an entire new banking business online, something so new to them as to us. As a startup, what they needed was a partner more than a solutions provider, someone they could trust and consult with on the best market approach.
Polarising responsibility in this project started only with its Integration component, an area we are experts on. But quickly we were also asked to implement a CRM tool with a technology chosen by the client and that needed to be tailored to its business.
At this point, we couldn’t even begin to imagine that this would become one of our most challenging projects, and the pressure for everything to go well got bigger, same as our motivation!
Topics in this article
Fast is not (always) effective.
Like in any other project we started by analyzing all the requirements assuming that like many other tools, anything can be customized and adjusted to the client’s needs. And all seemed to go well, since the first analysis sprint was quick and effective, and the client feedback was so positive that all the team could breathe in that amazing feeling of accomplishment.
We were excited! From here on anything could happen and managing expectations was critical: on one side, the client eagerness to have a new and unknown product successfully implemented, and on the other a development team motivated to do it effectively.
It was at this phase that the first obstacle arises: the necessary effort to customize this CRM tool was much bigger than what was initially estimated. Against all odds, we pushed it anyway. We wanted to keep the level of service our clients are used to.
But it wasn’t working that way. Something wasn’t right and we’ve missed some deliveries. Although the client was understanding, there was a legitime discontentment and apprehension.
We kept going and moving from sprints, although the development effort was enormous comparing to the underperform results. We decided to contact the software vendor, but they weren’t helpful as they claimed not to understand what our problem was exactly or empathize with our struggle.
Something had to be done and quick! Contrary to what some other IT companies might do, Polarising management guidelines were not to do more or faster, but instead to look for efficient alternatives.
One step back, two steps forward.
The team gathered; it was necessary to go back and analyze all our steps and decisions thoroughly. In retrospective we listed all the pros and cons of using the low code no code out of the box functionalities. The advantages of using the product existent features were many, specially its robustness and speed of delivery, since developers only had to do small adjustments to the original product.
There was no doubt that we had to inevitably change paradigm. So, we presented the client with a new approach, capable of supporting his requirements, a solution that was different from the previous one but that it would support the product basic features.
The future with low code, no code platforms.
The client agreed and the results came up; we were delivering more and better and, in less time, having productivity rates above expectations. Once they had the knowledge to customize the tool, the development team quickly became autonomous and highly motivated to take the next sprints, as well as to configure and benefit from its out of the box functionalities.
This project taught us a lot, turning into such a great experience and that gave the team and I value-added lessons that I’m sure we’ll remember in future projects we take on.
I like to think that contrary to the typical IT stereotypes that defend that the first interaction should always be to solve the problem, the differentiated approach is figuring out what’s wrong by questioning all variables.
Only this way we can avoid unnecessary programming efforts and, most of all, to maximize the already available solutions. So… does your business wants to change and evolve? Question the question and adjust!
Polarising Business Analysts