thingamy

Gamification?

One recent buzzword that I hear a lot is "gamification". Especially gamification of utterly boring Enterprise Software and consumer experiences in commercial transactions. A heroic attempt to solve one of life's mysteries; why work sometimes drifts towards boring and in particular why ESW tend to be so unimaginative.

On the surface it looks like nothing but a positive thing to do, who can protest the use of words like "game" or "fun"? It might even throw a dyed-in-the-wool sceptic like myself off the scent, a scent of potentially fallacious assumptions. But heretics have warning bells ringing when something sounds that good.

What triggers my scepticism is the "verbification" of the noun indicating that you take something existing, without challenging the assumptions nor changing the underlying, then simply... eh... gamify it. If the underlying part is not good enough, adding, combining or tweaking really seldom works well, history is full of examples from clunky flying cars to walking machines with wheels (Segway anyone?).

I even get this image of the Louis XV court at Versailles - infrequent bathing and worse, all doused by perfume in a feeble effort to cover the lack of some basic concepts. Sorry for that image, could not resist.

The purpose of "Gamification" seems to be to cover up some manual and tedious process in an effort to make it more "fun" (that word makes me double suspicious). I see it being applied as a fix-all in business settings for one single purpose; get the user to use what he's supposed to use without having to flog him. A classic manager and now IT vendor quandary. 

But what about checking the original assumptions and see if not the tedious and manual part could be removed instead of being hidden under a new "fun" layer? Try the soap before the perfume so to speak?

 The better solution

Games could give an answer, no doubt, but the question is; what to learn from games, what works and what is the core? Then apply the core learning to Enterprise Software instead of adding a flimsy layer on top.

Disregarding puzzle games for a moment; games are often about a narrative, a story, with characters to know and conflicts that shall be solved, and it must allow decisions and meaningful choices, still with uncertain outcomes that spurs reactions and results moving the story forward another notch in unexpected directions. Note the word "direction" there.

In short, story dwelling instead of story telling; play the game, live the life, immerse oneself in a sequence of partly self directed activities with a meaning (aka process, or indeed work).

Sounds like simulation does it not? Sounds like a real work process stripped of the boring stuff does it not? And indeed it is, both.

But simulation of real life processes, which equals an opportunity to run those, requires a "process engine" that can deliver any sequence of activities and punt back the resulting reactive activities. Manual wiki'ish dashboardy, send-mail-from-Word, or browse and select from long to-do lists does not cut it. Look instead to any multiplayer game on the net and that is precisely what you find at the back end; a pure process engine.

That's what most Enterprise Software for Barely Repeatable Processes lacks, they're mostly manual, no underlying process engine, no instantness. Rebuild the BRP ESW on top of a real process engine, take away that tedious, boring and repetitive manual flow-work, automate the flow-work and let the user focus on what's happening, what to do now at this precise moment, manipulate the process in the quest for solved issues and done work, in short focus on the work story.

That would create real world stories, that would be living the life story, that would be the most effective work modus, and that would be the ultimate game. 

On Productivity

"Productive effort, measured in terms of the rate of output per unit of input"

And I bet you that the next word that is popping up in your head now is efficiency: "Achieving maximum productivity with minimum wasted effort or expense"

All well and good and what managers are focused on every day at the office. And of course what Enterprise Software is all about; faster, better, more.

But hang on a second, so far we have talked about "how we do things", so far not much about "what we do".

Which of course would be highly interesting for the profits and the long term wellbeing of any project or company. In fact, that's the only place where growth comes from. When did you last find any volume growth in efficiency increases?

Eight chaps engaging in effective water transport instead of rowing efficiently in eight different boats.

Where did the pursuit of effectiveness go? Who's focused on "what we do" and the effectiveness of the whole organisation and business endeavour? Of course the founders when they started, that goes without saying, then the board every now and then under the umbrella of "strategy".

But should it not be a daily focus for all I wonder...

After all effectiveness always beats efficiency. Efficiency is all about running faster from A to B, while finding out if going to B is a waste of time and that walking directly to C makes better overall sense is about effectiveness. 
In reality efforts to increase effectiveness should precede efforts to increase efficiency every day. That's logical.

The problem is threefold I think:

• Efficiency is like the daily shower, results are instantly measurable, the feeling is warm and fuzzy. Hence something that becomes an easy habit, enticing management to choose this above addressing effectiveness issues with way harder to measure results.
• Efficiency is on the micro level; anybody can do something with it, while effectiveness involves many.
• IT is all focused, and indeed created, to increase efficiency, not at all built for changes to "what we do". On the contrary, effectiveness enhancements often means changes to, or even replacement, of IT systems.

Add that efficiency has a smaller and smaller incremental potential over time, the curve simply flattens out. While effectiveness is a never ending pursuit with definitely no smooth curve, it produces leaps and bounds in profits and overall success.

I think it's time to put the pursuit of efficiency where it belongs, behind the effectiveness pursuit. Both becoming daily pursuits.

Now only to find the IT that suits that approach!

[Guess you know me so you don't need much of a hint...]