Skip to Content

A Note: One of the joys in participating in a Community is to get that exhilarating feeling of momentum when various participants start to blog or talk about the same thing.  As I’m writing this blog, Dennis Howlett recently Collaboration Workspace: a process game changer? about the Collaboration Workspace and mentioned the Innovation Games. You can view my blog as complementary content to Dennis’ blog

I have been thinking a lot about the current Web 2.0 tools and comparing them to what I feel are relevant business requirements and I often come away with the feeling that there is a huge gap between what these tools can offer and what organizations require to achieve their goals.  I stumbled across a blog from Sigurd Rinde entitled “No ownership, no accountability – wikis, collaboration software, social media, Enterprise 2.0 and how not to get things done.” and I thought he really describes the dilemma succinctly.

It’s rather simple:

1.      Business is a value chain, a social value chain with a clear purpose.

2.      I am a part of a value chain and will have to do my part. For that I need ownership to what I’m supposed to do. Either I do it or somebody else does it.

3.      We all need accountability, if somebody else is dependent on what I’m supposed to do I better get down to it. And vice versa.

In social continuous processes, aka the value chains, ownership has to be clear and accountability towards the owner and all that is dependent on my work is a must. That’s the reality meeting Web 2.0 when it redefines itself to Enterprise 2.0.

One of aspects that Sig doesn’t explore but which is at the heart of this “social value chain” deals with decision-making. A critical activity in making decision is often concerned with setting priorities:  What should I do with limited resources? Often, decisions are made by a single individual and then must be accepted by the entire organization.  This often leads to problems in that there is no collective agreement that forms the basis for the decision. This shortcoming is mirrored in the nature of existing collaboration tools (wiki, blogs, etc.) that support this decision-making process by supplying those involved with information but ends there. The problem becomes even more apparent when decisions affect hundreds or thousands of individuals – in a virtual community or in a corporation. Besides the obvious problems associated with getting everyone in one location at one time to participate in a collaboration, how would you go about collecting and collating all this information.

A note: This point is related to The ESME Collaboration and what it tells us about Web 2.0 which looked at the importance of examining how Enterprise 2.0 tools can complement one another. Wikis and blogs may play one part in the “social value chain” but, if used in isolation, they can not be successful to meet more “complex” corporate requirements.

A Caveat: Now you may be thinking to yourself, “But someone has to make the final decision. Someone has to sign on the dotted line.” True but the process leading up to this decision might be a collective action.

Wouldn’t it be cool if the same collaborative spirit that was involved in the content creation could somehow applied to the decision-making process, so more people could participate (perhaps by ranking ideas).

Let’s take a look at an example to explore some of the shortcomings of current Web 2.0 settings. Imagine you are on a product development team that includes internal and external participants (including customers) who are trying to define the features of the next release for your washing machine. You use a wiki to collect the information from the participants and those involved can structure the contents and describe the features as they wish. At the end of a month, you have a wiki full of content created by the collaborators.   But how do you figure out which features are the most important.

Introducing Innovation Games®

I was introduced to Enthiosys by Aaron Williams (Vice President, Enterprise Services Community) when we were discussing various aspects of the new collaborative platform – Collaborative Workspace (CW). I was asking about what tools were being used in this environment and Aaron started taking about their usage of Innovation Games to facilitate better prioritization of use cases involved in the Enterprise Service community. I was fascinated by Aaron’s short description of their involvement and wanted to know more. I contacted Luke Hohmann (CEO of Enthiosys) to find out more details.  Luke describes their interaction with CW in this manner.

Our relationship to SAP/Plexus is that Aaron has been a customer of our face-to-face games in Use Case Roll-In Workshops. In this regard, he’s used the more open-ended games such as Spider Web and Start Your Day with small groups of customers (typically less than 30 in a group) to identify possible Use Cases for the SAP platform. As is common with our approach, the games tend to produce a large number of ideas. As a result, Aaron and the CDG leaders are faced with a prioritization problem — how to engage the larger Plexus community. We believe that Buy a Feature online will enable him to do this. The basic workflow is that a Plexus user will prepare a document with special Innovation Games tags. Our ClearSpace plug-in will process these tags and produce a game. When played, interaction will be given to our code and users will be using our system (running at SAP). The results will then be exported to Plexus.

(The bold typeface is from me). I found it quite intriguing to think abut this new environment enhance the collaborative process. If you want to know how Luke views this cooperation with SAP, take a look at his recent blog “Innovation in 3 Steps — Core Lessons from SAP”

 Before I describe why I find this interaction so intriguing, let’s take a closer look at “Innovation Games” and the “Buy a Feature” Game.  Innovation Games are a series of interactive techniques (“serious games”) that help determine product management -related issues.   I’ll just borrow the description of the game and why it works from the Innovation Games site to provide some details.

The Game

Create a list of features with an estimated cost. Customers buy features that they want in the next release. Make certain that some features are priced high enough that no one customer can buy them. This will help motivate negotiations between customers as to which features are most important. Encourage customers to pool their money to buy especially important / expensive features. Works best with 4-5 customers in a group, so that you can create more opportunities for customers to pool their money through negotiating..

Why It Works

Product planners often fall into the trap of thinking that customers have clearly defined product priorities. Some do. Most don’t. When presented with a set of options, many customers will simply say “I want them all!”, and put the responsibility for prioritizing their requests on your shoulders. Alternatively, product managers often gather feature priorities by working with customers one-on-one, and in the process once again taking responsibility for prioritizing features. By engaging customers as a group, and giving them a limited amount of resources, you give them the opportunity to prioritize their requirements as a group. But that’s not where the magic lies. The magic lies in structuring the conversations so that your customers are negotiating among each other for specific features. It is this negotiation that enhances your understanding of what your customers really want.

 

(I added the bold text). Thus, the community (group) collaborates on prioritizing the desired features.  If you take a look at screenshots from the game, you will see that it provides a user-interface that focuses on collaboration between individuals via chat and other means. Through an a analysis of the content created during this collaborative process, the game can discover what really motivates those involved and can more closely ascertain their reasoning behind feature preferences.  

 

Another technical note: The Innovation Game “Buy-A-Feature” is based on Scala / Lift Framework which is the same framework that is being used for the Community Project – Enterprise Social Messaging Experiment (ESME) .

Introduction

The first thing that I thought of when I heard about the “Buy a Feature” game was Dell’s Ideastorm. It also represents the ability for users to collaborate on making feature decisions.  In an email, Luke mentions the shortcomings of such systems:

Simplistic voting systems try to get around this problem by letting communities of users “vote” (e.g., “thumbs up” or “thumbs down”). These systems suffer from a variety of problems, including order bias (once an item is at the top it is rarely dislodged, because it stays at the top) and cognitive overload (most users only scan a few items).

The offer

I wanted to take this game out for a test drive. I talked to Luke and he said that he would provide an environment for seven players to test out the environment. We have to pick out features to prioritize, so I think possible features for the SDN / BPX site would be an excellent choice. The first seven people who send me an email (look at my SDN Business card) can join me in experiencing this new game online.

The system is still a work in progress, and the team working on the application is rapidly innovating and focusing on improving on the user interface based on feedback from customers / users.  So, here is your chance to influence how this innovative software will evolve.

Conclusion

When I first heard about these games, I realized that they were collaborative gaming instead of competitive gaming.  This focus allows these games to fit perfectly into a Web 2.0 environment. Indeed, this is another example of how Web 2.0 tools can and should complement one another. For example, it would be interesting to see if users in a game might combine a wiki / blog to deal with some sort of decision that must be made. There are a variety of other Innovation Games available. I’ll be curious to see how they fit into corporate environment.

In my opinion, current Web 2.0 tools are not flawed – they just have to be used appropriately.  Innovation Games is a good example of software that matches an understanding of corporate requirements – especially those concerned with collective decision-making – and the Web 2.0 collaborative metaphor.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Darren Hague
    Hi Dick,

    Funnily enough, as well as using Scala+/lift/ on NetWeaver Java as the platform for ESME, I was thinking we might use Buy A Feature to organise our development schedule. Perhaps we should set up a CW space for this, and invite some potential “customers”?

    – Darren

    (0) 
    1. Richard Hirsch Post author
      I was thinking of that as well. One of the next steps is to create a feature list for ESME. Once we have that the “Buy-A-Feature” would be the perfect way to pick which features were developed.

      Dick

      (0) 
  2. Mark Finnern
    Hi Richard,

    Thanks for pointing out this interesting concept.

    “Customers buy features that they want in the next release. Make certain that some features are priced high enough that no one customer can buy them.”

    I checked out their game page and it looks like it is funny money that you give to all the parties that are involved. Then negotiations between the different parties begin.

    Would it be possible to do this with real money? You have a service contract with us, the bigger that contract is, the more money you get to spend on features. If you need more money to get your most urgent features developed this year, buy a bigger service contract. The rest is a big bazaar very cool.

    Thanks, Mark. 

    (0) 
    1. Richard Hirsch Post author
      I’ll have to pass this idea – real money –  along to Luke.

      I liked the fact that “Buy-A-Feature” was focused on cooperation rather than competition. It is the interaction between team players that reveals the most information on their motivations.

      I’d be curious to see what sort of SDN-related features would bubble to top if ALL SDN members could play in the game together.

      Dick

      (0) 
  3. Luke Hohmann
    Mark –
    The idea for using real money is one that we’re actively exploring. As we gain more confidence and experience with our current platform expect us to provide additional collaboration services around the core game. But, these will have to wait — our backlog for what we want to add to our current offering is pretty long :-).

    Regards,
    Luke Hohmann
    http://www.enthiosys.com
    http://www.innovationgames.com

    (0) 
  4. Sigurd Rinde
    Hi Dick,

    excellent post!

    I agree heartily that decisions are, eh, important! 🙂
    I really did not included that in the post your linked to as a separate issue. I’m more of the school that decisions are everywhere, every time and the main ingredient in any task – no decisions nothing done so to speak.

    And as you say – the decision affecting many or only one, from prioritising limited resource use for many or my decision to send next task to Peter or to Mary, send the broken arm to another Xray or directly to plastering – can only become better with input from others. But at the end of the day no decision will come forth without ownership and accountability. The physician with the patient in front of him has that and will make the decision, the developer with a task to better the GUI will choose the path to follow…

    That is one of the issues I sometimes have when E 2.0 is touted as the fix-everything (not that you are though!), the other is the lack of process – social software is inherently single task support, and very good at that.

    But I really like the way Dennis described the ESME in the video – “one chap has a task, then fires up the ESME”. Precisely. One chap has the ownership and accountability, and then he will push the process forward.

    With integration into some underlying process (Netveawer?) you get a double whammy – capture of the in-task-process as well, an other term for (timeline) context. The often forgotten important ingredient in “knowledge”…

    Oops, too much of a rant now 😉

    Sig

    (0) 
  5. Natascha Thomson
    Dick:

    thanks for introducing me (and many others) to the gaming concept. It is intriguing, and I hope to read soon about new BPX features that people would like to see. Should you run short on interest to participate in the SDN/BPX feature game, I’d be interested.

    (0) 

Leave a Reply