Somewhere at some edge around our sphere of control, there is the bad world, where people are not accustomed to deliver Quality On Time. If I ask software developers whether they ever get the needed hardware on time to test their software, most of them tell that the hardware is always late. If I ask hardware developers whether they get their testing software at the time agreed, they usually claim that the software is always late. If I ask the factory whether they always can start producing on time, they usually claim that they expect the developers to be late. Before Evo, it has always been that way. With Evo, we are going to deliver Quality On Time. But how do we make sure that our unreliable suppliers prohibit us being on time?

After all, if our delivery time has come, and we did not succeed to deliver, we failed. We agreed to deliver and we didn’t. Any excuse it too late.

All people have been trained since childhood to make excuses. Even if we know we were wrong, our genes produce excuses. It’s not easy to learn to suppress this habit. It is important however to agree that if we agreed to deliver and we did not succeed, that we failed. And we don’t want to fail. If you don’t really care, or keep using excuses, you are one of the cases where Evo won’t work.

If the customer has a rightful complaint, we are too late. If our delivery date has passed and we did not deliver the Results agreed, there is no legitimate excuse. We failed.

Of course there always remains a risk that we still will be late. A meteorite may pierce our product just before delivery. In most real cases, however, we knew, well before the final delivery moment. Telling our customer that we cannot deliver due to Acts of God, well in advance, is also a way of delivering Quality On Time. The earlier our customer knows, the more he can adjust to the consequences if our inability. Every day we see a problem earlier, we (together with the customer) have a day more to do something about it.

In many cases, people try to put the blame of their late delivery on others: "A supplier did not deliver on time", or, "Management took some people from my project". At the Fatal Day, however, this is not a good excuse any more. After the delivery of our supplier we had still some work to do, incorporating the suppliers result in our product. This means that we could have anticipated our inability to deliver at least the amount of time for our subsequent work before our own delivery time. That was the last possible moment to warn our customer that we would not able to deliver on time. However, did we really do our utmost best to avoid being late caused by our supplier being late, or by management taking "wrong decisions"? Did we really Actively Synchronize?

If we expect a result from a supplier, there are three possibilities:

1. We are absolutely sure that the supplier will deliver On Time (= at the time agreed).
   Past experience tells us that we can absolutely trust this supplier. In this case, if we make the agreement, we just wait until the suppliers Results are delivered On Time.
2. We are sure that the supplier will not deliver On Time, because they hardly ever did.
   We should ask ourselves why we keep relying on this supplier. However, there may be reasons why we are stuck with this supplier, not in the least because many suppliers are similar, or because the supplier has a very special capability, so that we are stuck with them. In this case, we have to Actively Synchronize.
3. We are not sure whether the supplier will deliver On Time.
   In this case we should better assume case 2, until we are sure by experience that they are a type 1 supplier. Until then, assume that they are type 2, because this is statistically safer.

From Evo projects we should be able to assume case 1. If we are an Evo project, we should behave like case 1.

What do we do to Actively Synchronize?

Assume that we agreed on a delivery by the supplier in six weeks. Are we simply going to wait until after the six weeks, only to find out that they did not succeed? No. We’re not that stupid (I hope). We should contact the supplier e.g. once every week. If possible, by visiting them in person. If that is not viable, find another way to contact them.

This has three benefits:

• Because of our continued inquiry, we will get a higher priority.
• In many cases, a delay at the supplier is caused by issues that are unclear to them. They want to ask us, but because they are so busy, they keep postponing, until it’s too late. They use this as an excuse even to convince themselves that the delay was unavoidable, because they first had to ask us a clarification. Inside, they know better. If you show up regularly, they can ask you for the clarification and are able to be on time.
• In those cases that they really won’t succeed to deliver On Time, you’ll know much earlier, giving you more time to take the necessary measures, possible escalating the issue to make them reprioritize and informing your customer.

Do we only Actively Synchronize with the bad world outside? No, we use the same techniques in large Evo projects, which are organized as many Evo cells, who have to Synchronize among each other. And the same applies to multi-site projects. We always have to Synchronize our activities, so that we will get the right results at the right time. How actively we have to synchronize depends on the risks of the parties outside our control to deliver what we need, when we really need it.