Collaboration with a software partner

Three models for constructive collaboration with a partner in software development

Developing software systems is a time-consuming and resource-intensive undertaking. Today’s systems are becoming increasingly complex and extensive. In many cases, it is no longer possible to develop such systems without the additional support of a software partner.

This article will show you:

• in which situations it makes sense to work with a software partner and why it is important to discuss the type of collaboration,
• what challenges arise when working with a software partner, and
• what success factors ensure efficient and effective collaboration.

In which situations does it make sense to work with a software partner?

It is very important to have a clear idea of the reasons and objectives of working with a software partner in order to find the right partner and to choose the right set-up from the outset. You may think that the software partner already knows how to optimise the collaboration, so why should you have to think about it so hard?

Although an experienced software partner usually has an idea of how to work together, they may have their own goals and a different perspective on what the ideal collaboration should look like. That is why it is essential to clearly define your own motivations and goals in advance.

Some possible reasons and objectives for a partnership may include:

• You need additional manpower for your development team at short notice and on a temporary basis.
• You would like to have a complete system or subsystems developed externally because you either do not have your own software development or your capacities are fully utilised.
• You need expert knowledge on a specific topic that you cannot or do not want to develop internally.
• You are planning a long-term expansion of your development resources and are looking for an external partner to respond more flexibly to fluctuations in capacity utilisation or to benefit from the cost advantages of nearshore or offshore development.

This list is by no means exhaustive – there are many other good reasons for a partnership. It is important that in such cases, a collaboration is carefully considered and professionally set up; otherwise, problems are almost inevitable.

Challenges and principles of cooperation

Working with a software partner often brings with it various challenges. It is not uncommon for stumbling blocks such as the following to arise:

• Friction losses due to a lack of coordination and alignment.
• Misunderstandings regarding requirements, interfaces and other specifications.
• A lack of conceptual integrity in the software – similar tasks are solved with different concepts.
• Inconsistent code that makes maintenance more difficult.
• Integration problems with other subsystems.
• Inefficiencies due to the need for support, reviews and control of external work.
• Lack of knowledge or insufficient documentation, which makes it difficult to adopt external artefacts.

To avoid these and similar challenges, it is crucial to clearly define the collaboration from the outset and set it up professionally. Two principles are useful here:

Principle 1: Avoid unnecessary complexity when working with external partners.

External collaboration must not unnecessarily complicate the development process. Unfortunately, this is often the case in practice, which means that the desired support effect is lost. You can recognise this by the fact that the usefulness of external help is questioned – for example, by statements such as ‘This partner is of no use to us’ or ‘We are actually slower with these external parties’.

These problems usually arise when the set-up is not right or the collaboration has not been clearly defined.

Principle 2: Ensure that the software partner’s results can continue to be used and developed even after their deployment.

Whether you want to bring development back in-house at a later date, change partners or simply avoid manoeuvring yourself into an unnecessary dependency, you should always have clarity on the following questions:

• Has the software partner adhered to your internal development guidelines, such as coding guidelines?
• Which tools were used to create the results, and can they be processed further with your own tools?
• How were the results versioned? Do you have access to the history?
• How were architecture and design decisions documented?
• Can the tests that have been created be integrated into your test environment?

A clear understanding of these aspects is essential to make the collaboration a long-term success.

Models for working with external software partners

Let’s now take a look at the three most common models for collaborating with external partners. What are the differences between the models, and what factors influence efficient and effective development with software partners?

Let’s start with the simplest model:

Scaling

Use this model when you need to ramp up your existing development. The following illustration shows how this model works in principle.

Figure 1: Collaboration model ‘Scaling’

What is important in this type of collaboration is that the external support does not add too much additional complexity to the development. This means that external employees should be treated like internal employees and follow the same processes and standards. In an agile set-up, this means that the additional developers, for example, become part of the existing Scrum team.

The success factors in such a set-up are:

• defined requirements (also possible in the form of User Stories),
• existing and documented coding and development guidelines,
• architecture definitions and documentation,
• guidelines and checklists for setting up the development infrastructure, as well as
• guidelines and checklists for authorisations and accounts of external employees.

To reflect on the collaboration and optimise it if necessary, it is advisable to set up a regular steering meeting with the software partner’s representative.

This brings us to the second model:

Expertise

You should use this model when you don’t have expertise in a certain area and therefore need to get it from an external source. In contrast to the ‘scaling’ model, it makes no sense here to integrate the ideal expert into the team. My recommendation here is, if it is not just one expert, to install a ‘single point of contact (SPOC)’ to coordinate the collaboration with the experts. This SPOC should set up and maintain a contract-based collaboration with the experts. The result, i.e. the solution or the required know-how, must be defined in advance to enable effective collaboration. The integration of the result then takes place in the development team.

The following figure illustrates this model:

Figure 2: Collaboration model ‘Expertise’

In this model, the following two factors are essential:

• A clear definition of the expert’s assignment, which should include all relevant aspects. For example, functional requirements, quality requirements or procedures.
• Definition of a ‘single point of contact’ that ensures efficient and effective cooperation with the expert(s).

And so to the third model:

Outsourcing of packages, partial or complete systems

This model is used when you want to have defined packages of tasks, partial systems or complete systems implemented externally. There are usually various reasons for this:

• You have an enormous scaling requirement in your development and therefore need a team or perhaps even several teams.
• You want to benefit from the reduced hourly or daily rates of nearshore or offshore development.
• You want to have subsystems or entire systems developed externally for which you do not have the necessary know-how internally.
• You do not have your own software development at all and therefore want to have your system developed externally.

In this model, it is essential that coordination is carried out via requirements or, in an agile set-up, via User Stories. The requirements for the external team must be selected and made available. How exactly the external team develops is not relevant. However, it is important that, in addition to the content-related (technical) requirements, quality and delivery requirements are also defined and coordinated. Ideally, this is done via a software partner’s SPOC, which ensures that the relevant requirements are also met.

The integration or, if an entire system is developed by the software partner, the verification and validation of the partner’s deliverables should be done internally to ensure that customer expectations are actually met.

Here is another illustration:

Figure 3: Collaboration model ‘Packages, partial or complete system’

The success factors in such a set-up are:

• Defined requirements (e.g. in the form of User Stories)
• Definition of quality, process and delivery requirements and specifications for the software partner. This point includes everything that is important for subsequent work.
• Single point of contact (SPOC) at the software partner’s end to ensure that the requirements and specifications are met.
• Clear and unambiguous interface definitions for subsystems and packages to ensure integration into the overall system.

Conclusion

Successful collaboration with a software partner requires more than just the selection of a competent service provider – it requires a conscious and strategic approach. This is the only way to fully exploit the advantages of external support while minimising typical challenges.

First of all, it is crucial to clearly define your goals and expectations. What do you want to achieve by working together? Do you need short-term support, specific expertise or do you want to outsource entire development projects? The answer to these questions is the basis for selecting the appropriate partner and the right collaboration model.

Furthermore, it is essential to structure the collaboration carefully. Clear requirements, defined processes, transparent communication channels and adherence to common standards are crucial success factors. Failures in these areas can quickly lead to frictional losses, misunderstandings and inefficient processes.

The sustainability of the results should also be a focus from the outset. It is important to ensure that the software partner’s results can be easily reused, further developed or integrated into your internal processes. This requires clear specifications regarding documentation, tools, guidelines and the availability of information.

Finally, you should regularly evaluate the collaboration. Are the defined goals still up to date? Are the agreed standards being adhered to? Are there ways to further optimise the collaboration? Continuous reflection and adaptation is essential to ensure long-term success when working with external partners.

To summarise: a successful partnership is based on clear objectives, careful planning, structured processes and a sustainable focus on results. With this approach, you can not only benefit from the expertise and resources of a software partner, but also achieve your own development goals efficiently and effectively.

Notes:

The complexity of projects, especially software projects, is constantly increasing due to growing diversity, dynamics and networking. Employees with different backgrounds have to work together effectively to achieve the project goals. It is becoming increasingly difficult to maintain an overview. Matthias Künzi is happy to help you bring structure, systematics and methodology to your undertakings. If you are interested, just talk to him. And if you are interested in smooth software development and well-designed software, then it is worth taking a look at the blog of visuellklar.

If you like the article or want to discuss it, please share it in your network.

Matthias Kuenzi has published another article in the t2informatik Blog: