Outsourcing of Development or Consulting: a Checklist

Time to Read 5 min

You want to develop a product or part of it by a partner? You would like to get consulting?

What should you consider? How to outsource? How do you pick the right partner?

We have put together an outsourcing checklist for you. It can be used to ask the right questions for development projects and consulting mandates. Please note that it does not cover body leasing like this!

What is the Reason for the Outsourcing?

First, it is advantageous to be clear about the underlying reason for outsourcing.

• Time: Outsourcing serves to be faster on the market.
• Resources: Outsourcing serves to save internal resources or to have more of them available.
• Expertise: Outsourcing serves to purchase knowledge.
• Innovation: Outsourcing serves to buy new ideas.
• Price: Outsourcing is used to develop with a smaller budget.

What are the Characteristics of the Project?

Not only commercial and technical requirements are important for a project award, it also makes sense to ask oneself a few questions about the project.

Goals

• Have we defined the overall intent behind the project, a project vision?
• Have we defined clear project goals and results to be achieved?
• What is the strategic goal of the project?
  • Generate ideas
    • How far should the project go?
    • What are the boundary conditions? Are these boundary conditions not too restrictive?
  • Testing an idea
    • Is the rapid prototype really minimalistic? Have we defined a project for a rapid prototype or already a product development?
    • Does it allow us to obtain the information we expect: technical feasibility, market...?
  • Development to production readiness
    • How does the integration with our systems and products take place?
    • Do we know how we picture the validation (field tests, endurance tests...)?
    • Who is responsible for the series introduction (incl. test equipment, support for the pilot series...)?
    • How much support do we need after the series launch?

Project Steering

• How far can we get involved or do we want to get involved during the project?
• What technical and project management decisions do we want to take ourselves?
• Who will take over the project management?
  • We ourselves:
    • Do we have the processes, procedures and employees to manage an external project?
    • Are we aware of the communication effort? For example, that important decisions can only be made through personal interaction?
  • The partner:
    • Also in this case, do we have enough employees planned in as an interface to the project partner, especially in the specification, integration and validation phases?

Knowledge/ Core Competencies

• Is knowledge generated that contributes to our core knowledge/ our core competence, which we absolutely must have at our disposal?
  • yes:
    • Do we have a plan for back transfer (time, people on our side, formats...) to get the complete intellectual property back into our organization?
  • no, it is only about execution
    • Do we have all rights to all resulting intellectual property (source codes, schemas, manufacturing documents, test documents, libraries...), so that we are not bound to the partner in the event of changes ("lock-in")?

How do I choose the Optimal Partner for this Project?

If we are clear about the project, we can choose the partner.

Cooperation

• Does the partner bring along his own project management (especially for projects that run over a longer period of time and with several developers)?
  • Does the partner also carry out risk management for the project?
  • Does the partner have clear and useful communication processes?
  • Is a transparent reporting planned, with which we can follow the project progress even between milestones?
• Does the partner harmonize with our corporate culture?
  • Do we have the same ideas of quality, reliability, deadlines?
• What is the distance to the partner?
  • How does this affect our cooperation?
    • Geographical distance: travel expenses, travel time, time difference, type of communication: how does the mix of real or virtual affect communication?
    • Cultural distance: understanding of quality and time, understanding of contracts
    • Linguistic distance: our language, English, our industry and project language

Knowledge & Skills

• Can I test the partner with a smaller (pre-)project?
• Does the provider have the engineers with the necessary experience for my project?
• Does the partner have clear processes adapted to the size of the project and also the employees who live them?
  • Does the partner have the competencies for the project (complex software, signal processing, functional safety, cybersecurity...)?
• Does the partner have the necessary tools for the project?
• Are the developers really qualified for the planned work?
  • For the required architecture and design tasks?
  • For the tools used?
  • For the programming languages used?
• Is there a good mix between young and experienced developers?
  • How can I ensure this?
• My domain knowledge: has the partner shown that he can quickly familiarize himself with the specific knowledge for new products?
  • Are there any reference projects in diverse industries and technologies?

Price

• Is the total cost of ownership until market launch really accounted for? Taking into account:
  • Distance: travel costs, misunderstandings due to culture
  • Quality: not all quality can be covered by standards (ISO 9001...) and metrics
• Additional costs: What is included in the offered costs (software tools, travel expenses, fees, measuring laboratory/measurements...)?

Rights

• Intellectual property: is it clearly stated in the offer/contract or terms and conditions that we get the rights to all generated intellectual property?
  • This also applies to the results of preliminary phases, e.g. the specifications and system architecture: if we have the rights these results, we can also ask other partners for further development.

Business Model

• What are the internal priorities of the partner? Is the project business his core business or are we just a stopgap for the developers who are not needed in his own development or production?
• Is the partner willing to assist us also after the project? With support, with measures for discontinued components, with modifications, with solutions for problems in the field?
  • This also includes the fluctuation rate of developers at the partner: in a year, will there be anybody left who knows us and the project?

I hope this subcontracting checklist helps you to make your choice.

Andreas Stucki

Do you have any additional points to consider? Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!

Would you like to benefit from our knowledge? Visit our contact page!