Outcomes and the problem you are trying to solve

A project is defined, in part, by its outcomes. They describe us what it looks like at our intended project destination, in terms of where we are but also in terms of what we have learned, gained, developed. By defining good outcomes, we actually develop a great way to regularly check whether we are still on course. You typically do this at regular intervals, for example when you are performing a (weekly) review.

But sometimes formulating these outcomes is difficult, not to say almost impossible. I want to take a quick look at this type of situation, what may be a cause and how we can attempt to solve it.

What defines a good outcome?

A good outcome should be SMART. If your outcome is specific, measurable, attainable, realistic and time bound, it becomes adequately concrete to be followed up. There is a reference, an adequately concrete basis for developing a baseline. I've written about this before here.

what can go wrong? A concrete example

Now, theoretically I'm very much aware of what a good outcome should be. I mean, I've even adapted some text expander snippets for that exact purpose. However, the following happened to me only a couple of days ago.

In the course of my weekly review I bumped into the following inbox item (duly captured in my GTD process) "learn python". The source of this idea was an interesting post on MacStories by Federico Viticci on Pythonista for iOS. I'm a real pushover for this kind of excellent articles.

I knew this was not a simple next action. After all, you cannot 'do' learn python. So, it's a project. A project has both a defined 'why' and an outcome. The why was easy. Because I am curious about python. Okay, now the outcome. What does it look like when I get to the other side? Mmm ... Well, I know python. But what does that mean? Knowing is not adequately concrete. I cannot measure knowledge of python unless I define an objective benchmark. But I don't know enough about python to be able to define such a bench mark. ...

It turns out I never really considered what relevance python has or can have for me. I actually did not have enough information on python to assess its use for me. I simply did not have enough basis yet to motivate my (significant) investment in learning this language.

So I converted the project into "research relevance of programming languages for BTC, casmo and personal activities." In Covey speak, I did not have the end in mind. My project now has a number of steps aimed at identifying languages, understanding what I can do with them and matching or approximating this to a need I have or may have in the future.

Now, The answer may be that I have no need for learning a programming language. Perhaps I need to focus on bettering my CSS skills first. But at least I will not be off squandering my time on a no doubt interesting topic that will not contribute to my development or efficiency.

Don't get me wrong. I may still find arguments to learn python, even if it will not yield direct and measurable benefits. But, and that is a highly relevant difference, it will be a considered choice. That choice may mean I need to give up a number of other projects. But it will be considered.

what happened?

I failed to properly formulate a smart outcome for a project. While I was very motivated to learn python, I did not have a good enough reason for committing to it yet. There was no project, only enthusiasm about a potentially interesting subject matter I could get lost in.

While sometimes it may be your subconscious resistance to work that is pushing you in that direction, this was just an inadequately considered idea. Which is why doing the necessary research is a smart sub project to execute.

what has this taught me?

Well, first it taught me there are quite a few potential projects in my inbox or equivalent that are significant time sinks that I have yet to define a good outcome for. As long as the outcome is not clear, as long as they don't qualify as a real problem or issue I am trying to solve, I do not engage with them other than doing some research to clarify my thinking about the end I have in mind.

It also taught that that the SMART framework, heavy as it may be, has a marked advantage: if you fail the SMART test, you have an outcome issue. You are not clear enough. So you need to go back and think it over, again.

For those of you interested in the outcome of this specific issue, you may be interested to know that post my research I decided not to study python yet, and 'learn AppleScript first, as it allows me to automate more on my Mac. This will more directly impact my productivity.

Perfectly put

Once in a while, just once in a long while you come across a blog post so to the point, so well written, that it stops you in your tracks and you hear yourself thinking, almost aloud: "They're talking about me!"

I had that experience with Stephen P. Anderson's "What is User Experience?". It says everything, and it says it well.

Now, I'm not a User Experience Designer, as Stephen is. I am an auditor. But just read the following quote:

"At the end of the day, there are those people who will go quietly about their jobs, perhaps grumbling about not having a “seat at the table.” These people may have also been taught the right way to do things. Then, there are others who–regardless of their titles or position–will stand up and say, “Wait a minute, why are we doing it this way?”"

Yep, that last sentence, right there, is why I became an internal auditor. I could go on to quote the entire wonderful post. I won't. Go and read it. Now. You won't regret it, in whatever business you are. Because this is about us.

Assessing real risk appetite

Attending an IIA training in Brussels today on Corporate Governance audits, an excellent training by the way, we (the participants) started discussing risk appetite. The discussion got me thinking about the way we establish or validate risk appetite and the issues that come with that. Let me take you through my thoughts ...

A reflection of stated risk appetites

Let's look at a traditional process of establishing risk appetites.
Following COSO-ERM, the board has established some kind of risk appetite. In order to translate this to an operational reality, we start with a risk analysis, often based on risk maps specific to your industry. Management and process owners assess impact, probability of occurrence within a certain time interval and current risk coverage. They follow this with an assessment of the adequacy of that coverage in order to determine their "appetite" for the specific identified risks ...

Well, there is a bit of a problem with that approach. This approach gives us a reflection of the stated or expressed risk appetite, the stated preferences of the participants with respect to these risks.
What we don't know is whether this is a truly accurate reflection of the risk appetite, or whether it is a subjective response reflecting what management believes it should answer as a truthful interpretation of the expressed preferences of the board.

In other words, is this a reflection of how they really would behave with respect to these risks, or of how they believe they should behave.

Real risk appetite is reflected by exhibited risk appetite

There is one good way of finding out real risk related behaviour. For risks which occur with some frequency, we can observe the behaviour of management and process owners.

How? Well, any actual behaviour towards risks is reflected in the day-to-day decision making and action taking. In other words, our operational behaviour is an accurate reflection of risk related behaviour. From a risk management point of view, we can look at evidence of this behaviour, such as:

  • publications which exhibit our opinion on certain key issues in our industry which may be related to one or more risks, hence giving some information on our real risk appetite;
  • project choices and priorities give information on our preferences in terms of organisational strategies that we want to focus on as we deem them relevant;
  • meeting minutes of and reports presented to the board and exco give us information on which decisions are being taken as to where the organisation should focus.

In essence, these real life rather than stated set of choices reflect our actual attitude as an organisation, a management team, a division with respect to risks and our exposures to these risks: in other words, our risk appetite.

Using the results

Okay, what can we do with the information we gathered? Recapping, we have information on the stated, expressed behaviour of management and process owners towards risk and we have information as to the actual behaviour exhibited by the management and the owners regarding these risks.

We can perform the following analyses:

  1. Internal interpretation of the board's risk appetite: When we compare the board's risk appetite with the stated management and process owner risk preferences;
  2. Actual versus stated risk appetite: When we compare the stated management and process owner preferences with the exhibited preferences.

For any discrepancies, I would ask management or process owners to come up with a good explanation which motivates the deviations. They may be relevant and valid, but they need to be in line with the board's choices.

Tools I use - Reeder for RSS based information capture

A lot of the information I deal with, either for my day job or for my teaching or blogging, I get from different web published sources, be it blogs or websites. As I really don't have the time to visit each of these sites every single day, I make use of the RSS feeds where these sites provide them. I gather all that information in a so-called RSS reader.

What is Reeder?

Well, Reeder is my preferred multi-platform (iOS and OS X) RSS feed reader. The tool syncs with my Google Reader account to bring me all the information in a well designed format when I want it, or as long as I am within reach of a good 3G/4G or trusted WIFI network.
There are other RSS readers with a good reputation, both on iOS and OS X, but Reeder has an aesthetic that I have to date failed to find in other RSS readers. It provides a truly pleasant scanning/reading experience.

How I use Reeder

Those of you who have read my post on Instapaper know that I do not read in my RSS reader. I actually use it to scan through the articles. In my scanning, I follow a basic GTD approach:

  • An article I don't particularly care about gets passed. As I don't do anything with it, Reeder marks it as read and will remove it from my reading queue.
  • An article I must read or do something with for my day job gets send to Evernote and tagged as 'review'. This way, it ends up in a workflow I will write about later.
  • An article I want to read, but with no direct urgency, gets send to Instapaper, where I follow the process I described in this post.
  • In exceptional cases where I want someone to take direct action on an article, I will forward it through mail, but this happens seldom. I avoid it because this implies a delegated task, which I would rather manage through OmniFocus. Reeder does not allow for OmniFocus sharing as Instapaper or, with some effort, Evernote does.

Of course, as GTD adepts may be quick and correct to point out, I do not comply with the basic premise of GTD that I should touch every piece of stuff only once. I actually 'process' it twice, both in capture and in review. Well, it's not a perfect world. This is the best I can get my process now.

Which platforms can you find Reeder on?

Well, this is what I really like. There is an Reeder iPad application, a dedicated Reeder iPhone/iPod Touch application, and an OS X application. I can pretty much scan through my feeds whenever I have a couple of minutes of downtime, or during morning breakfast when I leave early and no one else is awake yet.

What are disadvantages and how do I deal with them?

Now, Reeder is a great but not a perfect application. I currently have two gripes about it:

  • The first one is a big one. I cannot directly add feeds in the iOS app. For this, I have a different Google Reader client call Mr. Reader. I have this app on my iOS devices for no other reason. Why not switch to Mr. Reader completely? Well, aesthetics mostly.
  • The second one is a truly nerdish one: as I don't trust Google for the full 100% never to suddenly kill Google Reader, I have set up a separate RSS aggregation solution called Fever. While not as fast or as complete as Google Reader, it works for my purposes of having a back-up solution available. Sadly, only my Reeder iPhone client works with Fever. Neither the iPad nor the OS X application support Fever.

In conclusion

Reeder is an excellent application that provides me with access to my RSS feeds when I want it. It allows me to perform good capture of that inflow of information into my workflows.

Reeder's main screen, with all my RSS feeds

Reeder's main screen, with all my RSS feeds

A view of my unread articles stack for this evening

A view of my unread articles stack for this evening

Reeder's sharing interface. I've configured it to show only those services I use or am experimenting with

Reeder's sharing interface. I've configured it to show only those services I use or am experimenting with

Tools I use - Instapaper as a GTD capture and review bucket

I’ve been a long term user of Instapaper, especially of Marco Arment’s excellent iOS app. I understand there is even an Android application available. Let me illustrate how I use it in my workflow.

Gathering inputs

I have a rather long commute to work. It takes me about 15 minutes by car and then another 45 minutes by train, followed by a 10 minute walk. What is great about it is that the two times 45 minutes by train per day give me the time to write and read. As the 3G availability on the train is bad to non-existent, I usually read what is in my reading queue. Enter Instapaper.

My Google Reader and Fever client (Reeder, subject for another review) allows me to easily send articles to be read to Instapaper (i.e. the capture phase). I do this for articles I would like to read, instead of articles I need to read, which I put into Evernote (yet another review). Instapaper is my true ‘to read sometime’ review bucket. Before I started to commute by train I never got around to review this bucket, now I am fairly up to speed.

Up to date at all times, with minimal effort

Instapaper’s geolocation support allows for easy synchronisation when I am close to a friendly wifi source, so I really don’t have to worry about synchronisation. My articles are with me at all times, on my iOS device (usually my iPad).

From bucket to to-do list in one simple step

So, I’m on the train, with my synchronized articles which I want to read. I go through them one by one. Instapaper has a choice of fonts and lay-outs, some of which are optimized for the iPad’s retina display, if you care about that. It’s kinda nice you have this level of customization available to you, on the other hand, as with many tools, too many buttons and features may actually distract. Marco Arment has erred on the side of caution here ... but still I am sometimes distracted into tweaking my Instapaper set-up.

Going through my articles, I apply a simple GTD algorithm: it’s either a next action which I can do here and now (using the 2 minute rule), a next action which needs to land into my task list, a task to be delegated or a document to be thrashed. Let’s go over how Instapaper supports each of these choices:

  1. Next action now: this is not necessarily directly supported in Instapaper, but iOS makes it easy to switch between an article and any other application. Instapaper allows me to copy the full text which I can then easily paste into any text editor I want to use.
  2. Next action later: Instapaper allows for very easy export to Omnifocus or Evernote. As I use both tools, I’ve usually worked with export to Omnifocus. One (small) gripe is that this function only exports the URL, and not the text in its entirety. I’ve recently adapted my workflow and for those situations in which I need direct access to the document, I send the task through Evernote with a ‘review’ tag attached to it. This in combination with a script on my iMac at home makes sure it gets processed and send to Omnifocus with a link to Evernote.
  3. Delegation: As Instapaper allows for email full text, I can easily send an article with some comments to a collaborator or a client and have them work on it. Of course, good delegation practices apply.
  4. Thrash document: Of course, documents that I’ve read and that have no further direct value can either be deleted or archived into the Instapaper archive queue.

In conclusion

Instapaper is my one and only “want to read” bucket. Given the functionality of the tool and its many export functions, it is an excellent bucket application. It integrates well in my workflow.

Instapaper article interface

Instapaper article interface

Instapaper's update location menu, highlighting its geofencing usage

Instapaper's update location menu, highlighting its geofencing usage

Instapaper's 'share' interface

Instapaper's 'share' interface

The impact of learned helplessness on audit recommendations

Learned helplessness in organisations has become an agent of the resistance

Ron Ashkenas wrote a very interesting article on the HBR blog a while back: in "Learned helplessness in organisations" he addresses the "external" excuses that process owners manage to come up with in order not to change their process. To quote him:

"This phenomenon — which one of my clients has dubbed "learned helplessness" — has the power to permeate the culture of an organization. Like a spreading infection, managers pass on learned helplessness from group to group and level to level. Eventually the standard response to any initiative is some variation of, "We'd love to do that, but we really can't.""

Auditors are frequently confronted with change resistance

It’s a statement very familiar to internal auditors, especially during the recommendation phase. Proposed solutions are rejected or never implemented because the process owners use this phrase as a defense (less frequent) or are genuinely convinced (more frequent) they are not able to change and optimize a process because of external constraints.

It gets worse: lack of or inconsistent understanding by supervisory bodies which are tasked to check compliance with certain rules and regulations, either internal or external, often leads to requirements being imposed on process owners which are (at best) not conforming to the intention of the rules and regulations or (at worst) diametrically opposed to the rules. Let me share a real life situation I once encountered:

During a process reengineering project we were interviewing clients of the organisation we were reengineering. As it was a government organisation with a significant role in checking compliance of actors active in their regulatory space, we wanted to determine the relevance of their compliance requirements. The client of the organisation told us that they had adapted their procedures to comply to the requirements as imposed by one inspector, only to find that these requirements were overturned by the next inspector that visited them. Both inspectors came from the same organisation.

How to approach change resistance

Well, it takes persistence. Ron Ashkenas recalls:

”Undaunted by their response, my colleague asked the managers to simply list all of their reports, approval procedures, reviews, audits, metrics, decision forums, standing meetings, and other management processes. He then had them identify which ones the government required, and which had been created internally. Much to the managers' amazement, the vast majority of these management processes were self-generated — which meant that they could streamline much more than they had thought.”

So the key challenge to the internal auditor is whether you accept the statements of your auditees as to their capability to change certain processes, or whether you are critical enough to challenge aspects that may actually lie beyond the scope of your audit or indeed even beyond your technical capabilities. Another story:

We were once auditing an organisation which did some of its technical testing using certain crystals in a destructive testing procedure. These crystals were either worth a lot or nothing at all, depending on the quality of the crystal. According to the engineers, there was no way to value the crystals other than destructive testing. The value of an individual crystal was material to the financial statements of the organisation. We consulted with an expert, a university professor, who was nice enough to give us his opinion for free, and he pointed us to some recent research which allowed for non-destructive testing and hence better valuation of the crystals. The engineers at the organisation had not been aware of recent developments, and had assumed the only way to test was destructive.

As far as I am concerned, the value of your audit is of course the reasonable assurance that can be derived from the auditing work itself, but also, and often ignored, the added value of relevant recommendations. These recommendations need to be as relevant as possible, and where required need to break through certain assumptions that have been underlying the current procedures, often for years, that are no longer valid.

How many possible worlds can you see?

I’ve been thinking about the entire subsection of GTD which relates to better definition of outcomes and ultimately better results. The storytelling and delegation post can be considered as a couple of ideas aiming to solve a subset of that entire issue, which can pretty much be summarized as follows: “How do I make sure that I define my projects, even single action projects, in such a way that I myself or those I delegate to are most likely to succeed?”

The easy solution

There is an easy solution to this ... make your outcome definition as weak as possible so you can check off the project action as done or achieved without lying to yourself. Of course, this is how you shoot yourself in the foot over the long term. If you continually undermine your own outcomes, your achievements will not amount to much. Then you can blame the methodology for not supporting you, and it won’t be on you. I’m starting from the assumption that you, dear reader, are not that kind of person. Although sometimes we all are.

The difficult solution

Defining your outcomes, what you want to achieve, is very much about having a clear view on what the outcomes can be, and what you believe the outcome should ultimately be. Fully understanding what the outcomes can be requires you to be able to see multiple future worlds. And therein lies the rub.

The quality of outcomes

When conducting brainstorming exercises, the number of ideas the group is asked to generate is often a multiple of the actual number of ideas used. There’s a reason for this: if you ask a group of people for their best five ideas, they are likely to give you their first five ideas or at most the best of their first ten ideas. This is why we often ask people to generate 50 our more ideas.

Our self-imposed educational limitations

The reason is simple: we tend to settle for less, as a group and as individuals. The same goes for outcomes. When we define them, we tend to look for one relevant outcome, and not the breath nor width of options available to us.

By the way, I strongly believe that our current educational system is limiting our children in their ability to see enough worlds out there. The insistence on keeping them occupied as well as the truly ancient way of educating people to conform to standards of performance which are only useful in a production, not a knowledge worker context, is robbing our children of their inate natural flexibility of seeing multiple possible outcomes. But that’s another post.

The interesting thing is that some people that choose to ‘adapt’ the educational structures for their own purposes, such as Steve Jobs and Marc Zuckerberg, have succeeded in keeping that capacity for broad visioning alive. It’s a trait sorely lacking in a lot of so-called business and other leaders today.

What we lose if we don’t define better outcomes

If our outcomes are limited by our daring to be creative, our lives are limited by the quality of those outcomes. So, we really owe it to ourselves to provide our projects with high quality outcomes which take in account that the environment and the context in which we try to achieve these outcomes may change.

How to

Alright, but what can we do to enhance our outcomes? I’ve made a shortlist of a couple of key ideas which will get you started:

  1. Look further than first outcomes: when defining a project, look at other possible outcomes of your actions and how they will count to furthering the achievement of your project.
  2. Quantify some kind of metrics around your larger project outcomes: what do you consider good enough? You should not necessarily go for 100% perfection, but you need to know when you can count on your results enough to further the achievement of your broader goals.
  3. Self-evaluate regularly: regular self-evaluation will help you in checking where you are in terms of the achievement of your goals. I like journaling for this purpose, but there are many other approaches that are as good or better. See what works for you, but stick with it.
  4. Close out your projects when your outcomes are within the brackets you defined: sometimes we tend to continue on in a project even when we have achieved what we needed to achieve. This is often the case if we fear shipping our results. Committing to closing a project when we have achieved what needed to be done, when it is good enough, is another element which really helps me.

If you try to do at least these things in a consistent manner for your larger projects, I’m certain you will see a marked improvement in your results. Good luck.

The advantages of risk and evidence based reengineering

I've expanded on a post I wrote for my old reengineering blog in 2010. Enjoy!

I’ve seen a lot of failed reengineering attempts. There are a lot of reasons why reengineering exercises fail and it’s not the purpose of this blog post to evaluate all possible reasons. What I do want to discuss, briefly, is why evidence based reengineering is a relevant, different and I believe more successful approach.

Reengineering 101

Traditionally, the top line activities in reengineering are executed according to the following pattern:

  1. the assessment of the current, or as-is situation
  2. the establishment of a wanted, future, or to-be situation
  3. the analysis of the differences between what is now and where we want to be, or the gap analysis
  4. the development and execution of an action plan to change the current into the wanted, future situation.

For anyone who has ever looked in awe at a consultant, well, this is pretty much what reengineering experts do. They’ll tell you it’s much more complex than this, but in essence, this is what it really boils down to.

Reengineering failures

Among the reasons why a project potentially goes awry is the very blatant one of starting from the wrong assessment of the as is.

How is that possible? Lack of validation is likely to be one, but a more likely one is a situation where the findings were validated by the management, but ultimately proved to be wrong anyway, because management did not have all information or was not aware of certain issues. After all, management is not deity (although behaviorally, this tends to be assumed in some cases) and therefore management can fail.

This is exactly where evidence enter the picture.

What is reengineering evidence and how do you use it?

Evidence is most certainly not interviews, especially not internal interviews. Most as is assessments are based on interviews with management and close collaborators of management. Consultants often assume that this information is complete, accurate, relevant and timely, but often this is anything but. Especially interviews with internal collaborators tend to confirm whatever it is that the collaborator thinks his management thinks or wants to hear.

Now, any auditor can tell you that internal evidence is the weakest of all evidence material, and reengineering interviews confirm this. Therefore, if interviews are the only information source, execute interviews with multiple independent sources with a clear view on the actual situation of the enterprise. Think clients, suppliers … even competition.

Oh, by the way, interviewing competitors to learn better practices under the guise of "research" is a common practice among some of the better known consulting organisations.

Relevant evidence

Better yet, start gathering hard data. Payroll data, other direct and indirect cost data, information from internal systems but also information gathered from banks, other lenders or financiers when it concerns financial information.

Go outside to clients and suppliers. A supplier will tell you if there are payment delays. A client will inform you of quality issues with products or services, of delay in delivery, of issues with execution … former clients are often a source of highly relevant information.

I remember a reengineering project I was involved in a couple of years ago where, in response to a simple request for information on payment terms and reasons for late payment by the specific client, we received an envelope full of evidence on very operational and quality issues. Following up with this third party, we finally understood what management was reluctant to share with us: significant quality control issues after a production line moved to a new location with lower labor cost and more manual interaction in the production process. None of the managers, afraid for the resulting backlash, was willing to share this.

Risk models as a basis for evidence gathering

A good means to structure the work is around risk models. I am a very big fan of risk based reengineering, and using risk models as a basis for reengineering is a good way to approach this exercise. Risk models allow for structuring of potential exposures in an organization, and will result in targeted exercises where the cost of reengineering is balanced as compared to the added benefit it entails.

Wall Street traders are hackers

A quick post on a very interesting article I recently read by the hand of Mark Cuban. It compares Wall Street traders to hackers. You can find the link by clicking on this blog post title.

I found it quite interesting to learn that any regulatory measure runs way behind. From an internal control point of view, it says a lot that the regulatory framework is out of touch with the actual business that is being conducted. Very worrying and one of the key reasons why lines of defense, such as internal audit, need to remain as flexible as possible.

Storytelling for better delegation

How often have you uttered ‘I can do it better’ and taken back a responsibility you delegated because you felt it was not appropriately executed? How often have you had the feeling that those reporting to you failed you because they did not ‘adequately’ execute a task? If ‘quite often’ is the answer, there may be an issue with your delegation. You may well be the issue here and not their performance.

Proper delegation is one of the most difficult tasks

If that sound harsh, well, I intend to be. Proper delegation is one of the most difficult tasks there is, and we do not, not by far, spend enough time learning it or teaching it to people. As a result, delegation is an archetypical wheel, being reinvented time and again.

Delegation issues sometimes relate to lack of storytelling skills

I’m convinced there is a correlation between issues with delegation and a lack of storytelling skills. Let me explain what I believe good delegation consists of and how it relates to storytelling.

Good delegation requires you to paint a picture

If you delegate a task or a responsibility, you need to paint a clear picture of the future you envision. You need to clarify what you want in as clear and concise a manner as possible. Storytelling is a good way of painting that picture. Happily ever after is usually preceded by a detailed account of how the situation turned out after the witch had been beaten. It describes a to be situation in adequate but not excessive detail. It clarifies both what needs to be achieved while leaving enough room for individual creativity by those aiming for the results.

As storytelling delegators, we are also responsible to make sure those we delegate to know what we want them to achieve, while leaving enough freedom for them to be creative about it.

Good delegation requires you to describe the lay of the land

Describing what needs to be achieved is not enough. Contrary to the outcome, stories go into a lot of detail when describing the lay of the land, the situation and the context in which a certain objective needs to be reached. The witch is described in elaborate detail. The trails of the hero and the adversity he faces are described with loving detail.

As delegating storytellers, we are responsible to describe in as much detail as possible our experiences and our understanding of what they will be faced with when executing the task.

Good delegation leaves room from own creativity

Stories are a powerful medium. They are made more powerful by what they do not tell. They leave a lot of room for interpretation, hence for creativity. This, in an aside, is what was reduced by radioshows and almost completely lost by tv shows ... our minds are less stimulated to fill in the blanks.

As delegators who tell stories, we are responsible to leave room for creativity, by allowing those we delegate to to bring their own solutions to the table.

Delegation through storytelling requires an investment ... from you

In short, storytelling provides a good framework for delegation. However, it requires some time to tell a good story. Delegation is therefore not pushing away tasks, but it requires a real investment in time and means from your side as well. Doing this will, if you work with motivated people, lead to better outcomes. Try it sometime.

Apple's retina 'mistake'?

A short post, but one I started thinking about when I was reading an article on the new HTC Droid and its 440 PPI display. Reading the article, I suddenly became aware that the retina display was the first time I am aware of Apple tried to differentiate itself on the technology, and not on the use case.

My choice for Apple, however, is not because of the best technology on board. They often don't, and I really don't care. Much as I don't care about the retina ipad 3/4 versus ipad mini debate. What is relevant for me is the usability.

As this excellent review by Patrick Rhone on Minimal Mac has eloquently illustrated, I want my tools to be boring, to blend into the background so I can get on with using my tools. I've been the nerd, hacking my android phone and installing CyanogenMod builds. No more. It just takes too much time to make other tools do what I want them to do.

So I really believe Apple slipped on that one. It's never about the "new", unproven technology inside. It is always, to me, about the ease of use.

Good public governance - the other side of using public means

Having to spend time in bed and at home dealing with a severe bronchitis is a good way of writing out some thoughts in a more profound manner than otherwise possible. I try to avoid gibberish as a result of having to swallow multiple antibiotics.

My former colleague and fellow blogger Simon Perks wrote an interesting post on his Sockmonkey consulting blog. I invite you to read it first, then come back, because I want to present the other side of that quite challenging problem for all public administrations: which money to use and how to use it, or rather, how to account for its use in the most transparent way possible.

Accountability

Simon states, and I entirely agree with his position, that any (public) entity needs to be aware of where they accept money from, as it may well come with some implicit or explicit strings attached. I like his idea on a three pronged approach using a policy, an approval process and a register. These will clearly enhance transparency.

However, there is one key responsibility that comes attached to any use of public means, which is accountability. As head of internal audit of a government agency, I am charged with providing reasonable assurance on good governance, and accountability is an essential aspect of good governance.

When the cure is worse than the disease

In our traditional command and control environment, which is much of any Western structure, be it public or private, we've always implemented the so-called lines of defence, with as much as possible a segregation of duties between the lines. In a command and control environment, this makes perfect sense. The big problem is that these structures tend to disenfranchise the process owners from their right and responsibility to be accountable for the good governance. By building additional control structures, we've taken away the burden of good usage of public funds by those directly responsible for its use. At the operational level, we may have actually reduced the direct feeling of responsibility for good use of means that we all pay for. At that point, the well intended cure becomes worse than the disease.

This is no longer about the process

Before anyone goes off on a rant about public sector, this appears to be one of the key failures of that mother of all private sectors, the banking industry. Too much power combined with too few direct responsibilities to the ultimate stakeholders leads to a real disconnection of the consequences of your actions. You will just think about you or those in your immediate vicinity. And any ex post control activity will either come to late or may not even detect what is going on until the exposure is significant.

If you factor into that the recent HBR article which states that one out of every two managers is terrible at accountability, it becomes clear that this is really no longer about the process. The process may be well tuned to situations where everyone is acting as a rational operator, but reality shows us time and again that that is not what is really going on in the workplace. Behavioral economist Dan Arlely has a wonderful quote up on Explore:

"If you think about the whole financial crisis, we've taken people and we've put them in situations which basically are guaranteed to blind or, at least, to distort their vision. And we expect people to overcome that."

Developing true accountability

One way of developing true accountability is to make the process owners directly accountable to their ultimate stakeholders.

Now, I'm not talking about direct elections here, which are more of a popularity contest than anything else. No, I'm talking about establishing clearly defined metrics which are in line with the expectations of the ultimate stakeholders. The people responsible for the activities or the project are then asked to explain why they achieved certain scores, explain both why they did not meet expectations or exceeded them. The ultimate stakeholders can then either judge the competence and adequacy of the responsables themselves or transfer their votes to an expert which will do it for them. This process has been described at length by Steven Johnson in his excellent book Future Perfect: the case for progress in a networked age

To date, we have failed to do this in our political process, which explains the phenomenon of political free riders that abandon functions when accountability nears to aim for a higher, often better compensated function. I know this phenomenon is also present in larger corporate organisations.

Lessons from development aid

It's my experience that development aid has a long history in developing metrics and evaluations for this type of situation. The Logical Framework, the Results Framework and other similar exercises are all examples of donors or agencies looking to establish accountability for results beyond the easily available metrics of the pure monetary aspects.

Perhaps the business world needs to look at what we have done ... and perhaps they can take some pointers of our industry.

Using Textexpander in setting outcomes for projects

Positive affirmation

I’m sure that most of the GTD practitioners are aware that positive affirmation really tends to work, not because of some magical properties, but because it helps you as an individual focus on a preferred outcome, rather than be all over the place.

Car accidents

A friend of mine recently took a crash course. A real one. A course designed to help you react in the correct manner if you are ever involved in a crash. I’m making abstraction of a lot he told me but one aspect really stuck with me:

Most people, when about to be involved in a multiple car pile-up, look at the accident they are trying to avoid. This apparently contributes to them hitting the other cars. An expert driver apparently should focus on where he wants his car to go. All other things remaining equal (driving ability, reaction time ...) the driver focusing on the way out is less likely to hit the pile-up than the driver focusing on the accident.

Now, I am not an expert driver, and cannot vouch for the relevance of that advice. So while this should not be taken as an advice, and I don’t claim this to be the ideal way to avoid getting in pile-ups, which you really should avoid at all cost, it does make sense. The driver focuses on what he wants to achieve and both consciously and subconsciously focuses on the achievement of that specific goal. In this case, it’s escaping the accident.

A similar approach has been shown to work for any type of higher rates of goal achievement. The Asian Efficiency blog has some great articles on this here.

The TextExpander snippet

I’ve created a textexpander snippet based on that very article. I invoke it through “;outcomes”, but of course you can use any textexpander shortcut you consider relevant. I launch this snippet in the freeform text field of the first action which I enter for each significant project I have in OmniFocus: the “Achieve my intented outcomes” action. It is the last action that gets cleared at the end of each project, and it is the action I check prior to going and doing any action on a project I have not worked on for a while.
Just clarifying my outcomes at the beginning and checking them on a regular basis allows me to ensure that I am formulating the right actions in the context of what I intend to do with that project.

You can see the structure of the snippet in the screenshot below. If you don’t know Textexpander from Smile software, get some more information here.

An (almost) device-independent information capture and treatment workflow with Evernote and Omnifocus

The information capture problem

When I am reviewing the new articles which landed in my Google Reader of Fever feed (yes, I am experimenting with Fever for when Google turns off Reader's lights) I often find myself saving articles to Instapaper. When I read them in Instapaper, I can easily transfer them to Omnifocus, but there I hit a snag ... when I do that, it assumes I can go online and retrieve the article itself, because Instapaper only sends URL information to Omnifocus.

This works fine when I am online, but less so when I have no internet connection. And given that my work takes me to Africa from time to time, and that good internet connections in some parts of Africa are either non-existent or prohibitively expensive, I needed another solution.

Enter Evernote

Reeder, my application of choice for going through my RSS feeds, allows me to send articles to Evernote. Granted, I will need to open Evernote and download the articles onto my device, but when preparing for an audit, that is a standard practice. I make sure I have a local copy available on my system. Granted, I could achieve the same outcome with Instapaper, but it would cost me a lot more steps to do just that.

Linking Evernote to Omnifocus

I was not out of the woods yet. Because now I have these documents in Evernote, but how will I remember I need to do something with them? Enter Thanh Pham from AsianEfficiency, whom I discovered through Sven Fechner's excellent and highly recommended blog "SimplicityBliss", which is an essential read for any self-respecting GTD practitioner with a Mac. In this article, he links to Thanh Pham's automated solution. I just set it up and configured it with no changes.

Whenever I go through Evernote now, and I find a document that needs a next action, I just tag it with a "review" tag. It gets linked to Omnifocus based on the Lingon Script that runs on a regular basis, and I have those links ready in Omnifocus when I need them.

There is an added benefit as well, which I only recently discovered: any links which I made on my iMac remain valid both on my Macbook Air which has a synced version of Omnifocus installed and, to my surprise, also on my iPad. I just navigate to the "notes" field, press on the link in the note field (an evernote:/// link) and if you press long enough, you get the option to open or copy. Pressing "open" launches Evernote and opens the document.

Thanks to both Sven and Thanh for the excellent developments that made my life so much easier.

Apple's device independence: achieved

Yesterday, while continuing to develop a document which I had started work on at the office on my MacBook Air and took with me on the train on my iPad, I suddenly realised the future is already here.

Between my MacBook Air, my iPad, my iPhone and my iMac, I am completely device independent ... as long as the device is a Mac, and when writing in Sublime Text 2, I can work on a PC as well (only not that well ...)

That device independence lies, as far as I can tell, at the core of Apple's strategy. They make great devices, devices which are the best to use by far, but between those devices, information should be and now can be seamlessly transferred.

Whereas before, my set-up influenced my workflow, I can now honestly say that my workflow is determining my set-up.

What meaning is all about ...

I often find myself wondering why I do certain things and not others, and whether my driver, whatever it may be, is the relevant one. I often 'meta' ask myself whether the way in which I approach this is the best possible way. In the context of one of these researches, I bumped into yet another excellent article by Umair Haque, in which he brings meaning to meaning. Pun most certainly intended. Read this:

Meaning, then, is something like a responsibility — not merely a need. It resides and resounds, like the human experience, between us. It transcends the narrow confines of the self — and connects us, through the power of grace and purpose, to the human world around us. It is the act of investing in what we profess to care about; in caring about what we profess to love; in not merely “expressing our values,” but valuing that which is worthwhile in lasting human terms, and so arcing the trajectory of not just our own tiny lives, but those of the people around us, towards the just-glimpsed sunrise of mattering.

It almost reads like poetry.

You need to go and read the entire article. Now. Really, go! The link is embedded in the title of this blog post.

Okay, now what does this have to do with GTD? Well, think about it. If all you are doing is working in pursuit of a self-centered set of goals which but focus on the me and the now, you will get very effective and efficient in killing the you inside of you.

Perhaps that is not what life is about.