17^th May 2021

Concern #3: Loss of Product and Technology Knowledge

Software product development is, undoubtedly, a very complex task. A large software product usually comprises a lot of business and technology knowledge. The final product code embodies all this knowledge but doesn’t explain it. If you own the software product, this doesn’t necessarily mean that you own the product knowledge and know-how and that you can improve or extend your product. In other words, without sufficient product knowledge you merely possess “black box” software not adequately suitable for further evolution, which is inherent for custom software.

Therefore, it’s very important for clients not just to own the product but also to own the product knowledge. Potentially, you can restore product knowledge based on the existing source code (sometimes, even the executable code) of your software product, but this is very costly task and makes sense only in exceptional cases.

If you outsource the entire product development to your partner, you may risk losing the product knowledge and having difficulties with further product evolution unless you request your outsourcing partner to create and deliver full product documentation describing the software architecture, business workflow, algorithms and data structures, environment configurations, deployment procedures, and other crucial information. Often, however, Agile does not leave time for writing full documentation, and the available documentation on a project is limited to user stories and code comments.

A more practical way, in the case of Agile development, is to split the project team between the client side and the outsourcing partner side. If the product owner and the system architect are located on the client side, a vital part of the product business and technology knowledge will be preserved with the client. To preserve implementation and coding knowledge, it’s sufficient to keep a few key developers on the client side and outsource most of the work to the outsourcing partner. In this configuration, the client can have peace of mind, knowing that no important product know-how will be lost.

Another solution to the problem stated above is to outsource less critical product components that are auxiliary, rather than the core of the client’s business. This work is often more labour-intensive than work done on the core functionality, so outsourcing it is a wise and rational option. The potential risks of losing product know-how are not critical in this case.

At Solead, we apply the following practices to mitigate the concern of losing product knowledge by our clients:

• We suggest that our clients keep the product owner and the system architect on the client side, or split these roles between the two sides
• We help our clients to define the optimal level of product documentation, and we create and maintain this documentation on an ongoing basis
• When possible, we perform software development in the client’s environments and keep the source code and other project artefacts in the client’s repository
• Upon project completion, we hand all the project resources, accounts, licenses, etc. over to the client
• In case of an unforeseen project suspension, we do our best to return the same team to the project when it’s resumed

In our next post #4 we’ll touch on another widespread concern – compromised work quality and failure to deliver by an outsourcing vendor.