When we think about milestones in a project, surely one of the first that comes to mind is signing off a contract with the client, the analysis and definition and the got-to production stage. However, there is a stage that is often overlooked and that is equally important: when the IT partner disconnects from the project. At Kaleidos we know that it is a relevant and delicate milestone and it has our attention from the beginning. Projects are designed with a vocation for transfer and with a shared time horizon from the beginning. This has plenty of implications for decisions made throughout the entire project.
Ensuring a clean and sustainable disconnection is vital for all involved parties as it enables spaces of trust and honesty from the beginning. For example, the continuity of a project is a widespread value while negotiation a budget, and false expectations can be generated; In our case, from minute zero our client knows that we are going to need a lot of involvement on their part, but that we do not seek the promise of continuity in the project beyond a certain date or goal.
This means that, by design, there is no conflict of interest with the team that will come after us. We are truly motivated to ensure that the incoming team can be autonomous very early on.
In short, making it explicit from the beginning that there will be a handover and a disconnection is another mechanism where transparency and honesty work for all parties and is very beneficial to the project.
Okay, but how, specifically, do we do this handover process?
It is there from the beginning
As already mentioned, all of our consulting and acceleration projects are designed with the handover in mind. During those first conversations we area already considering transfer scenarios: does the client have the equipment to maintain and evolve the product? Is the client going to assemble the team after the MVP (Minimum Viable Product)? Do they count on our help to recruit the team?
Along with the most operational, such as the team, we also mention strategic issues from the start. One of them is the creation of an extended roadmap, beyond the scope of our collaboration, so that from the beginning we have a shared vision. This roadmap is updated at the handover and appropriately presented so that the client can work on top of it.
And although technology might seem not as strategic as the roadmap, it becomes so at the moment in which from the beginning we use open-source technologies and formats. This ensures that the client will never be subject to vendor locking (the impossibility to change provider) and guarantees them to be able to explore any future scenarios.
Having these conversations so early on also forces us to answer “** Why? Why is it so important that Kaleidos ensures a proper handover?**” We have already mentioned that it enables trust spaces with the client, but that is not the only reason. This freedom we guarantee to the client at all times is exactly the freedom that we guarantee to ourselves. We wouldn’t want to have a client attached to Kaleidos for the wrong reasons, and we certainly wouldn’t want to feel tied to a client.
Moreover, having projects last, on average, a bit more than a year, we have more opportunities to evolve technically, update our skills and learn from new circumstances, which are key to our successful track-record.
Decision-making during the development
All of the points mentioned above establish a mindset that accompanies design and technical decisions. At Kaleidos we develop our own products too, so we understand the need for a project to be sustainable. And to ensure that, it is important to design taking into account which hypothesis needs to be validated first and how to get a platform to the market quickly, while at the same time being scalable and adaptable later on.
Hand in hand with design, the technologies we choose for a project also reflect this sustainability goal. The technological choice is made by answering questions such as:
- Which tech is the most suitable for the project?
- Does the client have their own team?
- Do they know this technology?
- Are there enough professionals working with this technology?
- Is it a language with projection or is it still the new fancy kid?
For example, UXBOX, an open-source solution for design and prototyping that we are developing, is made with Clojure and ClojureScript. It is a powerful and robust stack, and we consider it the appropriate technology for this tool; However, if we were to create such product for a third party, we would not propose Clojure as a base technology as we know that it does not have as much traction as other languages, so finding talent could be a problem.
After choosing the most suitable technologies according to different factors, we also ensure a smooth transfer during development. Good development practices are especially helpful so that the next one to come doesn’t have to navigate the stormy sea of ”hard to interpret personal decisions.” We try to use conventions, languages or frameworks in an idiomatic way, well maintained libraries instead of our own solutions, and we develop in a way that can be iterated on.
Sometimes it is difficult to balance between “go-to-market as soon as possible to validate hypotheses” and “make an IT architecture that can withstand different future scenarios”; It is precisely in the search for this balance that we feel comfortable; While we understand that sometimes we will have to sacrifice a more technologically robust vision, on other occasions we make sure (even vehemently) that certain guidelines are respected, so that future developers don’t face unfair dead ends.
Successful handovers
Finally, when the end of our collaboration comes near, we insist on having technical sessions with the new development team; there is no documentation that can improve the experience of having outbound and inbound teams solving user stories in parallel, working as one team only.
In this scenario we transfer the knowledge, the caveats, the reasons behind the decisions and also the methodology and the knowledge of the domain; all this represents a boost of involvement and productivity for the incoming team that is difficult to overestimate.
There isn’t always the ideal situation of having a trained and functional team to which to deliver a product already in production; In these cases, we put special emphasis on closing open functionalities and polishing everything very well, to ensure that the project holds up well during the first following months.
Regardless of the team transfer scenario, we also ensure the project vision transfer. Although it was not originally ours, at this stage of the collaboration we usually have a vision of the product and its potential, and we can connect it very well with our go-to-market experience. This contribution can have different formats: from user stories connected with the vision of the roadmap, to inspiring designs for the exciting future. Our clients also find our design materials very useful for the next funding rounds.
In short, in this last phase we deliver code repositories, challenges and vision, documentation, medium and long-term designs and more inspirational materials; the goal is for the client and their team to know that they are truly autonomous to continue making decisions from now on.
We believe it is very important that there is always a team ready to transfer the project to. Sometimes we get involved in this as well. From something light as recommending the perfect team configuration to go on with the project, to the team selection process. It is an intense and interesting task in which we can help to find the best team to take over.
Problems
Although this approach has many advantages for us, it is not without certain trade-offs:
Many times we have to leave at the sweetest moment of the project; when we have picked up a wonderful development speed and we are enjoying total focus; when there is already a release in production that a sales team can start doing their magic with and the development team can breathe again and look a bit beyond pressing needs. There is great pleasure in developing at a good pace knowing that you are in control.
A few times we had to delay the handover to ensure it is correctly addressed because imposing it (even if it was legit) seemed irresponsible to us; for example, if the customer has not been able to recruit their new internal team, or this process is still under way. On many occasions, a correct handover greatly depends on this delicate matter.
Final Thoughts
Hand-over is a key moment within a project, which deserves quality time and total transparency. At the end of a project, the client may feel dizzy before the massive change in context and responsibility, as Kaleidos typically goes “ALL IN”. Therefore, it is vital for the future and success of the project that we ensure ways for such continuity. None of this can be improvised, it must be planned with time and dedication. It has to be taken into account since the very beginning and monitored during all phases of design and development.