Introduction
Going through my mailbox a couple of weeks ago, I was surprised (and very thrilled) to find an email from Kourosh Dini, the author of “Creating flow with OmniFocus”, which is the unofficial reference book on how to set up your OmniFocus configuration and process. He thanked me for a reference to his book in a post. He recently wrote another book, titled “Workflow, Beyond Productivity”, a book I highly appreciate.
In the short email exchange we had, he mentioned it would be interesting to see how his ideas and concepts applied to a larger organization. And I happen to be an internal auditor of a larger organization, and have worked for larger organizations for most of my professional life.
So, rather than just reviewing the book, I will take some of the ideas and concepts from the book and apply them to the reference model of organizations which I carry around in my head. This reference model is a compound of all organizations I ever worked for or with.
I do hope these articles entice you to start reading Kourosh’s book(s). I like to think about him as the Neil Stephenson of non-fiction. The first paragraphs are kind of hard to get into, it does take an effort because of his beautiful but very intense writing style. Then, all of a sudden, he hits you with an idea so clear and so relevant that it blows you out of the water and leaves you on the shore, wondering how it is possible that something so clear and obvious never occurred to you. That, my friends, is genius.
So, I will work my way through the book, and try to write an article a week on it, touching some of his ideas and bringing them into a context I am familiar with. Again, get the book and read it. If you are even slightly interested in the dynamics of process and workflow, this is a great place to start.
Thresholds of organization
Quoting Kourosh, “the availability of some objects may not appear until a threshold of organization is reach for one or several other objects”, which he rephrases as “much of mastery is mastery of the basics.”
He offers a number of examples, among which “Certain uses of a program or application do not come to mind as possibilities until reaching a deftness with the program’s associated commands.”
What Kourosh says is “learn the keys”, “learn the language” and then you will be able to achieve a deeper, more relevant and longer lasting result because you will be able to do things, to execute certain actions you were not able to execute before.
While this is essential to people, it is essential to organizations as well. Let me explain how this works.
The magical black box
Many organizations believe there is a one size fits all solution for their – often administrative – challenges out there. It used to be ERP, the much touted Enterprise Resource Planning systems such as SAP or Oracle.
I remember an ERP implementation in the late 1990’s, early 2000’s with a client in which millions of euros were invested in getting the system implemented in the most speedy way possible. And while configurations of these types of systems require a lot of work and are prone to parametrization failures, this one project actually turned out pretty good. At least on the technical side.
There was, however, one key problem. In their enthousiasm to get the system working, they failed to adequately train the people responsible for all the administrative coding of data – an essential part of any system – in how to use it. The end result: lots of garbage went in, and even more garbage came out. The people who had to use the system, and were never trained to do so, were initially held responsible for the failure. They, in turn, rebelled against the system, and started to structurally refuse to use it. Alternative systems were developed, in obscurity at first, but more and more openly as they saw the support for the system from the highers-up was waning. After all, they were not getting the information they needed. In the end, the entire effort was abandoned, and the organization moved to a lighter, more agile and less cumbersome system.
But was it the fault of the system? No, the organzation failed to provide its collaborators the opportunity to master the basics. Hence, real mastery was impossible.
Quick and dirty risk management
I have another example for you. Risk management is a true management fad right now. Implementations of GRC (Governance, Risk & Compliance) systems are earning quite a few consultancy organizations a huge amount of money.
Now, I’ve been involved in developing risk management approaches from the early 2000’s, writing a COSO ERM based methodology before COSO ERM was even released in draft. Together with my co-author, we received the 2009 European Risk Management award for best public sector risk management approach in Europe. Bear with me, I’m going somewhere with this.
In the process of developing the risk management methodology, we realized that one of the key contributing factors of high quality risk management is completeness and relevance or proximity of the identified risks. In short, you want to make sure you are as complete as possible in your risk identification, and you want to make these risks as recognizable as possible for the people that need to deal with them. You want to identify Donald Rumsfeld’s “known knowns” and “known unknowns”.
However, we are noticing that completeness and proximity are becoming less and less important in current day risk management. Rather than identifying all the risks, let’s focus on the top 5 risks. And let’s make these as abstract as possible, in order to make them accessible to all, and not specific to one.
In addition to identifying not the top, but the first 5 risks, the abstraction will not make the risks more, but actually less accessible. A generic description tends to be more theoretical and less personal, less engaging. In other words, current day risk management practices tend to create a false sense of security, because we do not adequately take the time to master the basics of the application of good risk management.
A failure to engage
I’ve referred to Patrick Rhone’s article “The Farmer” more than once in the past. My interpretation of the article is that you need to do what you do for the love of what you do, and that you need to have the patience to go at it again, and again, and again, even if you do not see a concrete, tangible progress every single day. You are mastering the subject, and mastery comes with setbacks. But once a certain level of proficiency is reached, new avenues open up.
However, both individuals and organizations focus more on the tools than on the key mastery of the basics. They want to go too fast, want to show results now (quarterly earnings, anyone?) and fail to realize that the key factor is at the same time the weakest link: it is the human in the system who needs to take his or her time to truly assimilate what is going on in order to extract the maximum (human) value. Which actually also tends to be the highest long term value.
Exploring The Black Box 