Sunday, January 22, 2017

Addressing risk does not mean eliminating it

"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the best books written on risk management.

The last time I wrote about risk I focused mainly on the project level of things. Recent discussions led me to revisit thins topic within the context of the risks themselves.

Eliminating risks also takes away opportunities. Big time.

Depending on the source there are many different definitions of the term "risk." Mmost of the time it comes down to the severity of an unwanted outcome multiplied by the probability of that scenario. The names for “unwanted outcome” and “probability” differ from field to field, but the gist stays the same.
There are so many things one can do with risks.

  • risks can be mitigated (seatbealts mitigate the risk of a crash)
  • risks can be avoided (staying at home avoids the risk of a car crash)
  • risks can be compensated (first aid at the scene of a crash compensates –a little bit– for the risk of the crash)
  • risks can be reduced (distance sensors and assisted driving reduce the risk of a crash. So do speed limits)

Obviously (?) the option that avoids the risk is also the option that takes away the possibilities, the upside potential. You'd basically be going nowhere.

So when you look at your risk list and try to “eliminate them all” you might want think about other ways of addressing risk than just eliminating them altogether.

till next time
  Michael Mahlberg

Sunday, January 08, 2017

The “Pay to Learn” phase of projects

We should try to avoid waste. (Really?)

Nobody wants to create something just so it can be thrown away. (Really?)

Since “all universal quantifiers are always wrong”, those statements are probably not the whole story.

Even in lean eliminating waste is not as high a priority as one might think

In new product development – and re-implementing things in a different environment is new product development as well – a lot of effort goes into determining what the product actually is. And how to best build it.

Therefore some efforts are not waste at all, even if their results never go into production. In manufacturing and construction this is obvious for things like molds or scaffolding, but the same is true in knowledge-work as well.

Sometimes it makes a lot of sense to build something that will be thrown away, just to learn the right way to do it. Or at least a good way to do it.

Let’s have a look at Twitter for example. Twitter initially was build in Ruby (Ruby on rails to be exact). After a while it was rebuilt using different tools and techniques. So “obviously” the original implementation had to be “thrown away” at that time.
Does that mean that they shouldn‘t have started with Ruby? On the contrary – they ran with it for a couple of years. And they learned what they wanted to do with it.

But there are other things that you might not need in the later stages of product development – like dummy implementations of surrounding systems, paper mock-ups of user interaction, simulated server-roundtrips and a gazzilion more – but all of those help you learn.

And this "pay-to-learn" phase (with the willingness to throw away stuff that no longer is needed) is what often differentiates a really good product from a mediocre one.

till next time
  Michael Mahlberg