How to optimise teams when outsourcing

Outsourcing is when a business uses a third-party company to perform tasks and services. The granularity of these services and the types of services vary from very small (single person, hired as a freelancer) all the way up to very large (an entire department or skill set fully outsourced e.g., all software development, or all operation and management of the IT systems).

In between there are several intermediate levels covering small (one or two people hired from a business as a B2B relationship), medium (a team hired for a project with a finite duration or for an ongoing task e.g., build product X or support product Y for 12 months) and large (several teams for a big project or multiple projects running simultaneously).

These services can be satisfied with freelancing, sub-contracting or outsourcing. Freelancing describes a single person operating on their own, whereas sub-contracting is when a business is employed for a finite duration project or task. Outsourcing traditionally described an entire department or function moved out of a business for cost reasons but has evolved as an overarching term to now describe sub-contracting of all sizes, locations and models.

There are also a variety of terms used to describe different outsourcing models:

• Onshore - The supplier is based in the same region / country / time-zone as the client. Example: a UK client dealing with a UK supplier.
• Hybrid - The majority of the supplier team is based offshore, but a small number of supplier staff are in the client region, possibly the same office for ease of communication and access. Example: a UK client with a couple of UK-based supplier staff and the main team based in India.
• Nearshore - The supplier team is based in a near geographic region to the client, time zone differences and travel times are small. Example: a UK client dealing with a European supplier.
• Offshore - The supplier is in a different time zone that is a significant distance from the client. The benefits are typically lower costs and a pool of available staff to assemble teams rapidly. Example: a UK client dealing with an Indian supplier.

Team models

When teams consist of staff from a mix of businesses, it is key to clarify accountability and responsibility. When there is one group, either inhouse or offshore, which does all the work, accountability is very clear. As the mix changes the opportunity for problems arise. When issues occur, it is harder to get rectification work completed if boundaries lack clarity, with resultant lack of ownership.

Coupling and cohesion in teams

The principles of software modules can be applied in a similar fashion to teams. Low coupling between teams and strong cohesion within a team are good characteristics. Low coupling is best achieved through clearly defined areas of ownership for a team, consistent roles and responsibilities. Having an easily accessible organisation chart showing contact points for a team ensures any communication is directed to the most relevant individual.

Strong cohesion can be easily achieved through colocation of all members of the team, or from a history of working together or knowledge of a subject area. Cohesion is hard if the team is mixed between businesses or spans locations and is even more challenging if has been newly formed.

The weakest form of cohesion can be when staff augmentation is used to add one or two people from a supplier, temporarily, to a team. This requires proactive management and involvement with relationship building, sharing a common understanding of the project and adopting consistent methods of working to reduce potential friction.

Conway’s law

This is a principle dating from 1967 stating that the products and systems of an organisation mirror their own communication system. This leads to the approach that the proposed structure of an organisation should reflect the proposed structure of a new product or system.

The ability for people to communicate between teams and across company boundaries is crucial. Hence, architect the proposed product first and assign major modules or sub-systems to one company or location for optimal results. Any team members at that location are then optimally placed to deliver it and high levels of coupling are possible within that team. The company separation also then naturally means that weak cohesion between teams follows between modules.

Approaches for creating teams

There are several techniques for creating and onboarding multiple teams depending on circumstances:

• Build each team from scratch and keep it together, so team members can bond, go through a shared experience, and strengthen as a group. The downside is a longer duration for the team to get up to speed and there will be less common experience across teams.
• Create a seed team and once it is established, place people from that team into other new teams as they are being formed so there is always at least one person with some knowledge. This makes it easier to cascade knowledge quickly and to share a common theme and working practices. However, it means the original seed team do not stay together and hence those individuals must go through team creation twice.
• Setup an initial team and keep adding engineers to it until it becomes large enough to split and divide. This model can be repeated and ensures new members to the team can be inducted quickly and learn consistent working processes. The drawback is that the seed team is continually expending effort training new starters and varying in size. This process is also quite slow and only suitable when teams are growing at a slow rate.

Inhouse team as pioneers or followers

Often, a single inhouse team is on a project to provide long-term support and maintenance once the project has completed and outsourced teams dispersed. To ensure this team has visibility and understanding of the wider system, the team could be a pioneer or follower. If there are two inhouse teams, then both techniques could be used.

• Follower - Having a team that acts as an integration focus, such as the Nexus Agile methodology, or performing all-system testing of delivered modules from sub-teams can work well for an onshore team. This team needs a high-level overview of the entire functionality and by verifying deliverables from other teams, it is better positioned to understand and support the product at a later stage.
• Pioneer - Alternatively (or additionally) an inhouse team could act as a lead pioneer team that is temporally a sprint ahead of others. This team could have responsibility for refinement of designs, data definition, UX definition, UX widget design, creation of API definitions and even API stubs.

Consistency of team output

To ensure a level of consistency of work produced, it is critical that in situations with rapid onboarding of large numbers of external teams, that quality expectations are clearly documented and communicated. If this is not set out in the beginning, then at the end of the project, as the number of teams decrease, the remaining support engineers have a large amount of code with varying levels of style and documentation making the job extremely hard.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Documented coding and UX standards are a good starting point. These could be a single wiki page, or a large document set. To accelerate adoption, it is helpful to make it easy for engineers to access and use common building blocks. Base foundations could be UI widgets already pre-styled, or low-level software libraries or microservices.

Providing tools to style code, apply coding standards or to scan and enforce quality gates, is an effective way to spread and share quality expectations. Simplifying things through automated tools saves time and effort in code reviews. Otherwise, reviews just identify trivial coding and style differences rather than functional errors and omissions.

Accelerating onboarding

To get newly formed teams adding value quickly, a planned and structured training system is the main success factor. The traditional model of having a new starter to ‘watch, learn, copy, do’ needs to be scaled in a similar fashion. The goal is to devise a training programme that is fast and easy to repeat at an ad-hoc time when new people join.

An effective way is to video record or screen capture an experienced engineer explaining the aims of the project, how to setup tooling, quality standards and ways of working. Splitting this into modules allows the viewer to work at their own pace and replay details if complex and detailed tasks are described.

Summary

Team structure and onboarding is something that should not be left to chance. There are various approaches that can be adopted but they need to be considerate of project goals, size and quality.