Disclaimer: much of what is written below I have learned with one of my previous outsourcing jobs at Sioux Embedded Systems B.V., so much credit goes to them for creating environment where I could gain experience and build up necessary skills.

Introduction

Whenever a company starts with outsourcing a proper (team) organization shall be put in place in order for outsourcing to work. Everybody seem to admit that ‘throwing spec over the wall’ does not work, but what is then necessary? In this post I will summarize my experience of what had worked on several projects. Note that this is not the only organizational aspect to be considered, there are also other aspects which are not covered in this post (meetings, reporting structure, etc).

Obviously there are two parties involved: the client, who has a project to be outsourced, and a supplier that performs work. Both sides need to have roles dedicated to the outsourcing activities. Perhaps it is more obvious for the supplier, but the client also needs to realize that his interests have to be represented (and guarded) properly on a regular basis to ensure that the project is delivering what was agreed (and it is still relevant!).

Note that the organization as described below is based on experience working with technical clients that were interested in details of the technical solution and had proper technical expertise to judge those solutions. In case of a less technical client the corresponding (architect) role can be decreased.

From client perspective there are two roles that are needed:

• a technical (lets call it Client Architect, within a non-technical organization perhaps will be called different);
• an organizational (lets call it Client Project Manager).

Note that I use Architect for a technical role. It depends on definition of an Architect in your organization, but this is a common ‘label’ we have used so far which pretty well matches daily work.

From supplier perspective the following roles need to be filled in:

• a local technical representative (Front Office Architect);
• a local organizational representative (Front Office Project Leader);
• remote team (Back Office team).

Lets look at each role and define the associated responsibilities. Note that the roles do not imply that people are allocated 100% to them.

Client

The client roles are mainly needed to provide proper input and further steering to the supplier to make sure the project is heading in the right direction. These people are the main point of contact for (daily) issues for the supplier.

Client Architect

The primary technical contact person for the team to provide domain knowledge, provide requirements and verify their correct implementation. The latter can be done by either performing acceptance tests or (in case needed) by performing code reviews, etc to ensure the correct implementation and design decisions are made. Provides input for aligning architecture between the client and remote team, shares the long term vision of the client.

Note that certain activities may be delegated to proper knowledge holders, but the client architect remains single communication point and holds responsibility for this.

Client Project Manager (Product Owner)

Main task for the project manager from the client side is to provide supplier with proper priorities, communicate to proper stakeholders and ensure alignment with other projects.

Supplier

Supplier provides everything that is necessary for the proper (remote) project outsourcing. The split into Front and Back office is mainly based on the amount of communication necessary on-site with the client. The roles of Front Office are often split between different projects, but that entirely depends on the required amount of communication and size of projects.

Front Office Architect

Front Office (FO) architect is the main technical contact for the client for discussing requirements, high level design and architecture, and roadmaps. FO architect acts as a single technical point of communication between technical stakeholders (architects, designers, etc) at the client and the team. FO Architect holds responsibility for the proper implementation of the requirements and has technical ownership of the (outsourced) product.

During inception phase FO architect typically elicits requirements, defines architecture/design of the product together with the client and then ensures proper (domain) knowledge transfer to the remote team. During implementation he conducts code reviews for the deliveries from the team and helps team with design decisions (or consults client when aligning is needed).

After implementation phase FO architect performs initial acceptance of the delivery from the team, ensuring the requirements are designed and implemented properly.

In general FO Architect acts at the top part of the V-model. The more mature the remote team is the higher level of involvement of FO architect is needed.

FO Architect may also serve as first-line support and troubleshooter of issues with deliverables.

Front Office Project Manager

Front Office Project manager tracks the daily progress of (remote) projects, reports to the client and provides process improvement proposals. He is responsible for high-level planning of projects and ensuring the remote team has enough work that is ready to be picked up. Together with FO Architect FO Project manager determines priorities of daily team work, supports team with resolving operational issues, handles escalations (changing priorities) and tracks budgets.

Back Office Team

Back Office (BO) team is the power behind actual implementation. The team is responsible for maintaining technical expertise and product competence. It is responsibility of the team to proactively gain, share and maintain knowledge, communicate impediments and come up with improvement proposals for their way of working.

The team has to come up with designs, implementation, tests and documentation for the product. Within the V-model team typically acts at the mid- or lower levels as higher levels typically require more communication with client and more easily can be performed by the Front office.

Common pitfalls

One of the basic mistakes often made by clients is treating remote Back Office employees of supplier as their own (local) employees thereby assuming their knowledge, motivation and availability. Clients try to steer remote team directly which often results in lack of focus, misunderstandings and as result frustration of not getting “any results from them”. In fact remote team needs a good focus and explicit communication which should be taken care by the Front Office in order to provide expected results. Remotely people tend to miss a lot of details that are communicated on daily basis locally at the client site and cannot timely react on the changes that happen at the client. This does not mean that a change cannot be handled, it only means that it has to be handled in a controlled manner.

So instead of trying to steer people directly focus on communicating proper requirements and background information to the Front Office that will take care of propagation of this information to Back Office and proper daily steering. It is one of the tasks of Front Office to protect remote team from daily hectic of the client and let the remote team work focused on committed deliveries.