A few years ago, I learned some important lessons. I worked in the automotive industry, where suppliers are selected using a thorough process of requests for quotations, execution is based on detailed contracts and requirements, and payment is largely linked to a successful launch of the car. The negotiation power of car manufacturers is high, as they don’t commit to the supplier’s product from the get-go.
Furthermore, automotive manufacturers typically reserve one additional year between the supplier delivery date as committed in the contract and the introduction of the vehicle. They use that period for intensive integration testing. Any supplier who believes his project is over when his stuff is shipped with the right quality, couldn’t be more wrong! They keep you on your toes until the very last moment, just before vehicle introduction, exploiting every inch in the specification and of their purchasing power.
The lesson I learned back then: there are other forces that determine the lead time of a project than just the specification.
We all know the iron triangle of cost, time and spec. Because of intrinsic uncertainties in product development, we can’t fix all three aspects. Typically, in traditional project management, we fix the specification and put buffers on cost and time. But, as we know from Goldratt, buffers always fill up because of late starts (student syndrome), Parkinson’s law (available time is always used) and accumulating delays (the items next in the chain can wait but not start early).
In an excellent article, Kim van Oorschot describes how, in our efforts to make the deadline, we first consume the buffer of the current phase. After that, we consume future buffers and in the end, we just hope our future productivity will increase. The result is often delay and low predictability.
People are less aware that specifications are also full of buffers, as customers don’t know in advance what they’ll need. Therefore, even a concept like a minimal viable product is an illusion. But in my experience, it’s very effective to exploit that (invisible) buffer in specifications. The specification is never fixed and during project execution, we can continuously negotiate it. And you’ll notice that when the customer approaches his deadline, he’ll become more and more compliant to make the best product given the time frame.
This is why the role of a product owner is so critical. The product owner continuously aligns with key stakeholders on the specification and priority of deliverables. And this alignment is based on collaboration rather than on contract execution. When time and costs are fixed, the objective is to exploit the uncertainty in the specification to deliver in time and to satisfy the customer.
We recently applied this approach in a machine building project. It’s quite different from more traditional project management approaches and organizations definitely have to get used to it. People just love plans, it gives them the illusion of control. They have to accustom themselves to the fact that even if we’re not able to exactly predict the costs and time of each feature, we still can sort of guarantee an on-time, on-budget delivery, just by organizing ourselves to deal with the uncertainty in the specification.
The approach resulted in on-time delivery and a happy customer. So, 100 percent predictability. You may ask: “Predictable? You didn’t deliver the upfront defined specification!” My answer to that is: “Yes, predictable, as time and cost budgets are met and the customer is satisfied.”
This approach with a key role for the product owner is far more effective than traditional project management methods with a focus on planning, registration and known unknowns. Most projects are delayed because of unknown unknowns and don’t follow the plan. Management typically likes predictability, but I believe this traditional approach is one of the root causes of low predictability.