Author:
Han Schaminee is general manager Navigation and Automation at Wärtsilä Voyage.
Reading time: 4 minutes
I often meet managers seeing risk as a threat: a threat to predictability. They rightfully aim to be a trustworthy partner for their customers and believe predictability is an important ingredient for that. But they sometimes forget risk is one of the reasons why they’re in business. There’s intrinsic uncertainty in innovation, and many of our customers in a B2B environment seek partners who can better manage that uncertainty than they can do themselves – and they’re willing to pay that: the higher the perceived risk of your own investment, the more profit a customer will allow you to take.
So, managing risk is a key element of the value we add towards our customers, and it would be silly to try to avoid it. Many managers spend substantial effort identifying risks in advance and defining mitigation actions. They focus on the known unknowns and even apply sophisticated methods like Monte-Carlo simulation. But most innovation projects suffer from unknown unknowns. And this makes these techniques totally useless. You better organize yourself to deal with the unexpected rather than trying to predict the unpredictable.
One of the most effective ways to deal with uncertainty is ‘reuse.’ You can reuse competencies, which often used to be sufficient reason to be selected by customers. But to be able to reuse competencies, you, of course, shouldn’t ramp up a project team with new people and scale it down when the project is over. According to the “Project management book of knowledge,” a project is a “temporary endeavor undertaken to create a unique product, service or result.” Another definition talks about “a temporary organization to achieve a certain business result.” The word “temporary” already disqualifies these methods for application in innovation projects.
There are even better ways of reuse than just reusing competencies. A very effective way is reuse of (sub-)products or building blocks. Research shows that in world-class, stable companies, a one-euro R&D investment leads to a two-euro return. When you sell engineering hours, you would have to sell every R&D euro for three euros to achieve that. I’ve never understood managers who prefer to be in the business of selling engineering hours. They either don’t care about profit and productivity or they don’t care about customers and don’t mind betraying their customers with an extremely low efficiency.
Another effective way to manage risks is applying incremental delivery. In a recent video with Elon Musk and a NASA manager that went viral, the latter explained that his organization could never have achieved the steep learning with their waterfall development models as what was achieved by the fail-fast models applied by Musk in his SpaceX endeavor.
Many waterfall approaches include a ‘feasibility’ phase leading to a conclusion, such as “it must be possible.” But very often, at the end of the project, unexpected issues pop up. The main reason why the brothers Wright were able to win the race to build the first plane was their incremental development: lift-control-propulsion. Incremental development provides much better transparency on the actual progress in terms of done deliverables rather than the ‘closed activities’ overview used in traditional methods like design, code and test. Finishing testing doesn’t say anything about the progress. Transparency isn’t always fun, though: over a project’s lifecycle, the life of a traditional project manager is far more relaxed as he/she only finds out about major problems in the last phase of the project.
Incremental development is often combined with iterative development, where deliveries are made in a fixed rhythm. Cadence has also proven to be effective in managing uncertainty. So, always release in a fixed cadence, don’t wait until that one feature can be added. You can still decide whether or not to release to a customer. It’s “deliver in cadence, release on demand.”
It’s interesting to see that, while Agile methods with the application of “fail fast, decide late” principles have been proven to be effective in software development, the application of incremental methods in hardware development is only picking up very slowly. I often see hardware development still being organized using a plan, managed by exceptions, so more “fail late, decide early.”
A third way to organize yourself for uncertainty is the application of what I call adaptive project management. We all know the iron triangle of cost, time and spec, sometimes extended with quality. In traditional project management, we freeze the specification and put buffers on time and cost. But, as Goldratt has shown in his excellent book “Critical chain,” buffers on cost and time always fill up because 1. the student syndrome (starting late), 2. Parkinson’s law (work expands to fill the time allotted), and 3. delays can only accumulate, they cannot advance.
The good news is that, in my experience, there’s always a hidden buffer in the specification. In an earlier column, I explained the critical role of the product owner to manage that buffer. By being transparent to the customer and collaborating very closely with the customer on prioritizing, you can together drive the delivery to success and meet customer expectations. The ultimate predictability is if you deliver to the customers what and when they need it and not if you delivered what was agreed upon a long time ago.
I love risk. For me, it’s a key value I can add for my customers and a way to differentiate from the competition. I’d rather create an organization that can quickly respond adequately to the unexpected than one that avoids risks or relies on a list of pre-identified things that may happen.
