What to consider if you plan to outsource part of the development, and how to get the most out of the cooperation

First, you must look at yourself and answer some questions: for example, do I still understand correctly from terms of reference that everything must be automatic but can be changed manually?

Is it possible that, in terms of reference, the order scheduling functionality in the ordering environment needs a more detailed description? Do I understand what I want, and is there a need for it?

The project will fail if the goal is to save costs because the development hour is cheaper elsewhere. The development hours saved are balanced by numerous hours of analysis or constant rework. The goal must be to do something and create value. Do we need extra hands, or do we need to know how to do it? These two perspectives are different and require different approaches.

When a helping hand is needed, it is good to clearly understand your own standards and culture against which to compare potential cooperation partners. If it is an unknown field, you can be more general - compare approaches rather than content.

How long do we need friends for? Hopefully, this question is rhetorical also for you. Even if a partner is only required for one particular random project here and now, what is the probability that the cooperation will not continue tomorrow?

At Trinidad Wiseman, we prefer to work with companies rather than freelancers, as it is easier to find points of contact between the two companies. Of course, freelancers still have capable specialists with whom you can cooperate fruitfully.

Choosing a partner takes time, considering everything possible that could affect the cooperation. For example, we value personal communication and the ability to bond because we believe that contracts will have little impact or meaning without these foundations.

First, we pay attention to fundamental values - we compare a potential partner's values, attitudes and working methods with our own. It is essential for us that they have the same goal. Regarding foreign partners, we also consider possible cultural differences, English language level, local public holidays and time zone differences.

We have a goal, and we know who can help achieve it. It is also necessary to introduce and clarify the goal, the plan to achieve it and our expectations towards the partner. You can save significant time if everyone is on the same page from the start.

The start of a new project requires the preparation of all parties. Meaning by the time we start work, all participants know what the form of cooperation is, what the phases are in the project, what the roles are and what expectations are set for them, what communication channels and work environments we use, where we keep the documentation and what the documentation standards are.

All of the above requires good communication. Communication could be osmotic, i.e. none of the parties would remain in the information bracket (see the checklist at the end of the blog for more details). This approach has another significant advantage - if all parties are involved in the consultations, a situation will not arise where some party does not know what it does not know.

For example, if a project manager and an analyst discuss a specific problem with each other, but the relevant developer is not involved, the decisions made may be difficult to implement. In the worst case, it becomes apparent only in the project's final phase.

Now that the sprint rally is underway, there is a need to check the quality, and it must be done continuously because later, it may be too late. The primary indicator of results is the presence of work results at the end of the sprint, and if it seems that the work is going well and the results satisfy us, then we move to the testing phase.

If too much work comes back from testing, we must find out why. We may have prepared the initial task poorly, or the person doing the work needs to gain skills and experience with such tasks.

Since, at the moment, we are primarily talking about the partner, we should treat him the same way as the members of our own team; that is, we evaluate everyone according to the same standards. Let's say a partner helps us build a machine-learning solution that integrates into the system we're building.

His expectations and requirements should be exactly the same as for the in-house service design team, which provides input to the in-house development teams that will implement the solution. Equal communication and attitude have a good effect on the relationship of trust with the partner and help to avoid tensions.

Sometimes it can happen that we have chosen and found an excellent long-term partner, we have thoroughly familiarized them, we have once again discussed our expectations of each other and our fears, and, if necessary, changed our approach and tried to improve the process to achieve the required synergy.

However, despite all this, the cooperation still does not go well. In general, experience shows that overcoming obstacles is possible if there is motivation on both sides to continue the collaboration.

If, however, it turns out that it is physically impossible to continue, for example, the project turns out to be more complex and requires competence that the partner does not yet have, we must be ready to independently search for solutions because we have taken our responsibilities to the client.

Having experienced various scenarios at Trinidad Wiseman we always try to apply our key in-house strategic roles (project manager, analyst, system architect, senior developer) to projects. In this way, in case of unexpected events, it is faster and more convenient to make the necessary reorganizations to continue work immediately.