In the early stages of any startup’s life, energy runs high, while resources are scarce. Many of those resources are money related, of course, but time is also a big one. One of the founder’s main missions at the onset of a company is to find a healthy pace for the organization’s growth, in order to avoid running out of resources or falling on the opposite end of the spectrum: having abundant resources at the cost of having very low energy levels.
The recipe for that usually involves outsourcing. Based on the teachings of “The Lean Startup”, by Eric Ries, most early stage startups focus on developing their Minimum Viable Product, and so they keep their people focused on high stakes activities and decision making, and leave the rest to be taken care of by external providers: accounting, recruiting, PR & advertising and, of course, software development.
This has become widespread enough to be considered a good practice.
And, for most purposes, it is.
However, after that initial phase of explosive growth, where speed is the number one priority, the startup’s leadership team needs to stabilize the operation. Intuitively, this sounds like it will be easier than the first stage. After all, where the first part was all about growing and acceleration, this second part is about slowing down. But there’s more to it than meets the eye.
The project then needs to go back into the hands of the startup’s team, and that can be tricky.
What goes into a handover
The first important distinction to make is that some of the outsourced efforts become ongoing engagements (accounting and PR are usually the case), while others are encapsulated projects with a clear beginning and end. The development of software platforms and products is usually the second case.
To make things easier and clearer, the external team to which the initial project is outsourced will henceforth be called the “project team”; and the internal team, which will take over after the project is finished will be called the “operational team”.
The handover is the delicate dance that takes place right after the project team has completed the delivery of everything that was in the agreed scope, when the time comes to transfer knowledge over to the operational team, who will continue the evolution of the product internally.
Many organizations carry this process out without much thought, and it is usually a source of frustration that can be avoided.
Let’s look into some of the key aspects that go into a project handover.
Priorization
A few years back, I had a colleague who regularly took the chance to remind our clients that:
“If everything is important, nothing is important”
I have lived by those words ever since, and my life has been all the better for it. The ability to establish priorities and a hierarchy of information is paramount in any project, and especially in a project handover. Most handovers suffer when project teams can’t prioritize what information is relevant for the operational team and what isn’t.
Prioritization is usually thought of as an issue during the project life cycle, which leads to delays, mis-estimations, endless meetings and arguments, and a bunch of rework. But it can also be the cause of major headaches when the project is over, and it’s time to transfer knowledge to the operational team.
Why? Because as any project advances, the team involved in it learns more about the problem and the implemented strategies to solve it, and develops an acumen that is difficult to transfer.
A lot of project teams end up dedicating too little time to this, and the operational team is left facing a long ramp-up to get up to speed with things. And the teams who do set time aside for this, often run into trouble deciding what information will be relevant for the operational team and what isn’t, with the double-sided risk of flooding them with too much irrelevant information or failing to transfer critical knowledge.
Accumulated knowledge
Related to the issue of prioritization, another difficulty comes from the amount of accumulated knowledge over time. Regardless of how it is prioritized, the sheer amount of information can be a problem in and of itself when the time comes to hand it over.
This problem of accumulated knowledge only grows: as time goes by, as teams get bigger, as projects advance, the amount of knowledge gets larger and larger. Every possible element that relates to the evolution of the thought and work that goes into the project, adds up to the pile of things that later need to be passed on.
The sooner teams install systems to manage shared knowledge, the easier it becomes to face the handover phase.
Complexity
But it is not just about the volume of data: there is also the dimension of the complexity of the relationships between the elements that make up our knowledge about a system.
As we learn, our brains make connections and establish references that work for us, but are not necessarily universal or easily relatable to others. As if that wasn’t enough complexity, when we learn with others, we share some of those connections in the form of common knowledge, and we start to communicate with shorthand references. This is an often overlooked problem when conducting a project handover.
Most transitions focus on the technical aspects of the project, like components and technologies used in the stack, repositories and passwords, or architecture. But a large part of the project’s health relies on things that are not in the documentation. A good way to avoid overlooking this body of knowledge is to have someone from the operational team directly involved with the development team from day one, to be familiar with the evolution of the understanding, decision making and the mental framework used to design and build the tool.
Things to be considered
One major thing to tackle around this process concerns ownership. The best possible scenario is that projects begin and end with high involvement of the operational team, who need to act as owner of the project from day one, and continue to own it after the handover. Continuity is a cornerstone of knowledge transfer. But it is not always the case, and it’s not the only thing to consider.
The Wúru case
Wúru drives healthcare operational excellence using AI, to unlock the wellbeing of patients and care professionals. Their platform feeds on millions of data points originated from patients’ itineraries to provide healthcare workers with critical information that drives smarter decisions.
When they reached out to Manas looking for a tech partner to develop their new platform, the company was in a very early stage, and had a small team that was laser-focused on testing out the validity of the product and its fit with their target market.
They were the textbook example of a company headed for a handover: they had a functional MVP and needed to get it ready to scale, as fast as possible, to aggressively go to market. The urgency to amplify their development capabilities and seize the market at peak maturity called for the aid of an external team, but the consolidation of their customer relationships would need an internal team to grow and evolve the product with direct input from users.
Design and build, side-by-side
During our initial conversations, we made it clear that we don’t intend to keep any of our clients hostage, and that required them to be involved with the development from the beginning, to start preparing the transition to their operational team from the get-go.
So, when we began to stabilize the project, we integrated Wúru’s CTO into the workflow. To understand how to prioritize the information to be passed on, we decided to take a functional approach: we assigned him a few tasks to see if the technical documentation was clear enough to enable him to solve them. We monitored his progress and adjusted accordingly.
When a larger portion of the operational team is available in an earlier stage of the development cycle, we usually cease the chance to hand over the project gradually. For that, we define a discrete process that the team will have to take over, and we iterate over it in cycles:
- The project team executes the task end to end, to make sure that the workflow is air tight
- The project team executes the task end to end, while being observed by the operational team, who make notes of the process
- The operational team executes the task end to end, while being observed by the project team
- The operational team executes the task end to end by itself, without supervision, but with the possibility to turn to the project team if any doubts arise
Bugs in production
When not handled properly (or ignored altogether), preparations for the handover of a project can make it one of the more challenging aspects of software development: in the best case scenario, it can result in developers not knowing how to contribute to a given codebase, but it can also lead to higher order problems, like missed timelines and expectations and, of course, sunken business opportunities.
Mishandling knowledge transfer can also generate significant problems when the project is directly tied to end customers: misunderstandings can lead to downtime, flawed features and eventually money loss.
Prioritization of information, efficient transfer of accumulated knowledge and a responsible grasp on complexity vary depending on the project and the background of the people who are going to take over the technical ownership. It all certainly gets easier the sooner the project owner gets involved, and the higher the technical acumen of the team is.
Outsourcing done right combines a project team doing the heavy lifting, with at least one member of the operational team who can champion the development efforts within the organization, and be the guardian of the knowledge that is acquired and generated during the entire process.
The sad news is that most organizations don’t take this with the degree of seriousness it demands. The good news is that, if your organization does, it’s several steps ahead of the competition.