Addressing critical in deliveries from subcontractors

In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?

The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates.  How can these be addressed? Do iterations hold the answer? Are there better options?

Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.

1. Make sure the contractor works full time you your order

This might seem obvious, but it is not always true.. there are plenty if incentives for the third party supplier to work on multiple projects.

One of the biggest performance killers in knowledge work is multitasking, so make sure the people at the contractor works 100% on your order. You might need to address this already at contracting. Be ready to pay a little bit if needed to make it happen, it is a vise economic trade off. (try yourself, what would a 100% time overrun on your project be worth? From this number find 10%, 50%  etc.)

A couple of years ago I was working with in the game industry with a product owner who where dependent on a third party component. The PO had a local development team and a couple of developers “leased” at a third party company for making changes to their software. She had big trouble getting anything out of the third party developers who were seated among their peers in the third party product company. We moved the third party developers to our site (yes.. we had the luxury of making that happen). This move gave the third party developers the opportunity to focus (less multitasking),  removed unnecessary distractions (“hey what about..”) and made it possible for them to see and interact with our backlog (suggest simpler solutions). From this point, we got good in deliveries and smooth flow.

If it hadn’t been possible to move the third party developers we would have insisted on a separate room for these developers at the third party site and a separate backlog just for them which our PO controlled.

2. Defer the start of development of the third party until it is time (but no later!)

Knowing that it will take a long time to get the in delivery, it might be tempting to send the order for the third party component right away..

But there are hidden risks here. The customers needs, our understanding of the customers needs and our understanding of the right solution will change. If we don’t address this fact, we can indeed get the in delivery in time, but on the wrong thing.

A better approach is to try to find what the real lead time is from when we send the order until the in delivery is verified. This gives you an indication of when the last moment exists when you need to send the order. Potentially, add a small buffer for variance/uncertainty (if you have historical data points, this can be estimated).

The time period from the start of the project until we send the order holds opportunities. This is referred to as Late start advantage. It has upsides:

• We can learn what the real client need is until this point
• We can learn what solutions that works until this point
• We can incorporate late technology advancements and into our design

These options carry value. So we start by not throwing them away. We want to utilize late learning.

The force we fight against is referred to as erosion. The value of our design decisions erode over time because of changes in our environment. Therefore, a design done with late information  carries higher value than one done with early.

3. Strive for first time pass

Your next goal is to make sure your order to the third party goes through without loopbacks. Once the order has been sent, we want to make sure we have done all that is in our power to avoid loop backs, redesigns and interference over costly time and geographical boundaries. For example, if you are working with +6h timezone difference the round trip for one question can easily be three days. What if your project needs to solve 100 of them?

Above: Avoid frequent loopbacks over geographical/time zone differences.

Do: Strive for first time pass

First step

First step to get to this situation is to look at the work that happens at the subcontractor after the order is sent. Separate between inner and outer activities. Inner = Those who subcontractor must do, Outer=Those we as project must do. Examples can be specifying, verifying, installing, give feedback or similar.

Second step

In the second step, move the outer activities before, or (if synchronization isn’t needed) in parallel with the inner activities. Investing in training of subcontractor engineers and local integration test facilities allowing the subcontractor to verify quality himself is one example.

Third step and beyond

Eliminate 80% of the design uncertainty before the order is sent to the subcontractor.

• Define an API (interface) between you and the component. What we strive for is reducing the coordination cost of clarifying questions by focusing them to the understanding the interface rather then constantly needing to invoking the full skill set of the product. In the next step we use this to:
• Prove your product and the third party component prototype works in a production like environment before order is sent
• Create a scaled down prototype locally and verify it against a working solution before sending the order to the subcontractor

The best scenario is if you can ask your third party to send you the scaled down prototype.  Such will act as a “receipt” verifying you have understood each other.

But what if I need to iterate?

If you start from this point, it is a small failure. It’s preferrable not to iterate over (costly) time and geographical regions. But assuming that you need to, try these things:

• Send your designers over to them, and allow them to co-work together until the major design challenges have been eliminated
• Set up a daily meeting over video conference where your and your subcontractor’s designers can interact(don’t be stingy, use proper video conference equipment so you can see facial expressions and share design sketches)
• See to that problems and questions arriving from the subcontractor have top priority and are solved without delay

Summing it up

I hope you can make use of some of these techniques. Next time you encounter important subcontractor in delivery as part of your project I hope you resist the temptation to say “iterations” will solve the problem. Iterating the wrong things can be costly… We can do better.

/Mattias