Library clips

In the previous post I reviewed a video interview with the talented Jordan Frank from Traction Software, which was on social tools and ad-hoc processes. This video got me inquiring further into what others have said about this over the past couple of years. So I headed to my bookmark collection, and this post is what resulted.

But first I’ll repeat a few highlights from Jordan’s interview:

• Workflow systems are great until they fail…a need to have a collaboration safety net.
• Collaboration is not necessarily about making the things that are planned go right, it’s about dealing with the things that are unplanned that go wrong
• It’s hard to troubleshoot when what happened till now is not easily accessible or not recorded in a raw fashion
• You can’t anticipate a workflow for fixing a problem (with social tools like Teampage) you can model informal processes on the fly
• Make sure when business conditions change your business processes don’t get left behind

I also linked to one of Traction whitepaper’s that demonstrates the bottom-up enabling tools we now have to better cope with getting things done, and by default achieving the original aims of KM and being an agile organisation.

Emergence by default

Social computing is about many things: discovery, connection, conversation, emergence, crowdsourcing, transparency, engagement, innovation, collaboration, findability, diversity, sharing, learning, helping, sense-making…

Helping and sense-making have an immediate impact eg. stuck on an issue, asking a question, getting an answer and moving on…whilst this happened others got to learn for free.

In a way emergence happens anyway as a result of sense-making ie. emergence that surfaces from "In-the-flow" working, which is in contrast to "Above-the-flow" emergence (crowdsourcing, sharing your experience, etc). Either way we have emergence because people are visible and their interactions are documented, all made possible via bottom-up enabling tools.

Another immediate sense-making aspect is dealing with exceptions to processes. Email is our survival tool to not only improvise, but to plain and simply do work. Same goes with MS Word and Excel…then put them together as email and attachments.

James Dellow pins this down:

"Like cockroaches, spreadsheets have continued to thrive despite the growing (perceived) sophistication of modern enterprise information system. They record data, drive barely repeatable processes, they are spread around by email systems and people use them to address problems that other systems fail to solve."

Process vs Practice

I will refer later to "barely repeatable processes", but for now let’s looks at processes and how we need flexibility.

Jack Vinson quotes Mike Gotta on Process vs Practice:

"Process is "how work should be done." And Practice is "how work is actually done." When process fails (exceptions), people use practice to fix things. When process doesn’t exist, practice fills the void. While people don’t realize it when they engage in practice, they actually are tapping into community — an informal social network within or beyond the enterprise to discover expertise and get things done. The problem is that we haven’t had the tools to support good practice."

An interesting comment on Jacks post by Marnix:

"Process is the way work is being done, combining technology and practices. Culture is when this happens unconsciously; ’it is just the way we do things around here’"

Move from pre-defined structure to DIY

Bil Ives says the difference with new social tools is that the people (users) decide on the structure of the process:

"ERP provides infrastructure that often requires work processes to confound to the software structure. Enterprise 2.0 is often attempting to provide tools that will conform to your work practices. With ERP adoption is not the issue, except in the 9% of cases where parallel adoption is used, With ERP the issue is implementation, as people are generally required to use the system. The study stated than 83% of the ERP implementations studied were considered successful."

Bill also says:

"The irony of enterprise 2.0 is that you actually get more control because the free form nature of the tools allow the business people to decide on where structure occurs, not the people who make the software.”

Joe McKendrick gives BPM a new name:

"No matter how automated a workflow may get, there are always stages in which things need to stop for an exception, an approval or a quality check. The role of human interactions has always been a complicating factor in business processes. Introducing Enterprise 2.0 approaches may help shift the emphasis from business process re-engineering to business process re-energizing."

Jim McGee combines the concept of rigid processes and how it relates to emergence:

"In an accounting or ERP system, the system’s designers specify all aspects of workflow, database design, and information structure in advance. Users are expected to select from among pre-defined choices and enter only such data as the designers have provided for. In designing a system for emergence, the designers leave a number of these decisions open; waiting for users to fill in the blanks"

Paula Thornton comments on a past post of mine on this meme:

"Real knowledge work is about handling the exceptions. Everything else can be automated. Thinking about the frustrations you’ve had with anything you’ve tried to accomplish in getting work done (save your own shortcomings or those of others). A good majority of them are either due to over-automation (not allowing for exceptions) or underautomation (leaving you to manage mundane tasks). What IT methodology focuses on assessing for such balances? NONE!"

These are our tools to execute work. They are also the tools that come in especially handy when the process system we should be using is too rigid.

I know when I was doing document management support work the support database was merely used as managing the call, but the conversations happened in email. That is, email is our coping mechanism. I’ve posted on this before, and Larry Hawes has a post on the hybrid use of both process-centric and people-centric tools. The BPM type tool to locate issues, status, who’s on it, blended together with conversational tools where the troubleshooting actually happens. There is a place for both where they complement each other…the road ahead is integration 2.0.

This is when we say social computing isn’t really anything new, it’s just the next survival tool or coping mechanism which is more effective than email. Especially in circumstances where we need help, and ad-hoc collaboration to get through a process. We have phone, then email / IM and MS Office, now we have microblogging, blogs, forums…and wikis to stitch the process together.

Even a janitor is not absent from these non-routine and improvisational working conditions.

Unstructured and Barely Repeatable Processes

Sandy Kemsley notes that Gartner calls this unstructured processes:

“…work activities that are complex, nonroutine processes, predominantly executed by an individual or group highly dependent on the interpretation and judgment of the humans doing the work for their successful completion”and notes that most business processes are made up of both structured and unstructured processes. Unstructured processes are costing organizations a lot of money in lost productivity, lack of compliance and other factors, and you can’t afford to ignore them. Although most processes aimed to meet regulatory requirements are structured, unstructured processes provide a company’s unique identity and often its competitive differentiation, as well as supporting operational activities."

Sandy moves the conversation to Integration 2.0, where social tools are features of existing business process tools

"…the BPMS vendors are looking for ways to incorporate “barely repeatable processes” into their systems, allowing users to create their own ad hoc processes on the fly but still capturing the audit trail so that it’s not just happening over email or the phone in an unaudited fashion. The idea is not to pre-define all of these processes, but to provide tools that allow process participants to have a sufficiently unstructured environment to do what they need to do, and augment that process with their own call-out at that point."

I have posted before on Barely Repeatable Processes, and Exception Handling and am going to re-quote here from some of the pioneers in this movement.

Ross Dawson explains the need to complement an ERP - Easily Repeatable Process, with a BRP - Barely Repeatable Process (via Sigurd Rinde):

“Typically exceptions to the ERPs, anything that involves people in non-rigid flows through education, health, support, government, consulting or the daily unplanned issues that happens in every organisation. The activities that employees spend most of their time on every day. Processes that often starts with an e-mail or a call. A process volume, measured by time and resource spent at organisations, probably larger than for the Easily Repeatable Processes. These are mostly handled and organised - frameworked - by systems like paper based rules and policies, e-mail, meetings, calls and now in more modern organisations by wikis and other collaboration systems and methods. Known by extensive loss of information (e-mails residing on HDDs), little knowledge acquired and reused (typical research says 70% of problems solved before without being known) and most of all, untrustworthy processes (oops, forgot to send that mail). In other words not an iota (well almost) of business process thinking or methodology applied to this huge untapped area of business processes.”

Ross Mayfield on the same meme:

“The way organizations adapt, survive and be productive is through the social interaction that happens outside the lines that we draw by hierarchy, process and organizational structure. The first form of social software to really take off to facilitate these discussions was email. Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process. That’s what they’re doing in their [e-mail] inbox for four hours a day. Email has become the great exception handler.”

Bottom-up structuring of ad-hoc processes

Before I spoke of using social tools to sense-make (get help, get through a process), well the next step are apps created from the bottom-up (by the users), that have noticed how people use social tools in an ad-hoc way, and are offering a way to design or assemble this process into a more visible flow. Basically making your own process, which you can manipulate at any time to suit the situation.

A way to see it is a kind of semi-formal approach where you are agile enough to assemble an app to slightly structure ad-hoc work:

Dennis Howlet talks about Thingamy software:

"…‘barely repeatable processes’ - a good way to look at them - where you need a quickly built app that includes the process loops in order to solve the problem."

And Jacob Ukelson talks about ActionBase:

"One thing to be careful with is that you want to provide enough structure to the process to add value, but not so much as to strangle it. Given that most of these processes are executed today via documents and email, we built our tool as an extension to those standard office tools - allowing the same ad-hoc feel, but adding a layer of management, tracking and reporting. "For many of these processes an initial formal model is overkill (and at odds with the needs of most knowledge workers) - at most you want a guideline or best practice that gets modified as the work gets done. Then these emerging models can later be used to create a more formal model if needed (I’ve blogged on the topic of in-situ process discovery on our blog http://blog.actionbase.com/in-situ-process-discovery)."

When you think of Activities on IBM Lotus Connections they are practicing this in an organic way. Activities (and Google Wave), are a collaboration tool to work on a task, where everything is recorded, and lives on a URL. Common activities can be available as templates eg. if you have to organise an event, there’s no doubt many have done this before using "Activities", so why not start by re-using a template, and re-mix it to your context.

See a video called "The man who should have used Lotus Connections 5 - Innovate or Die"

Human Process Management

ActionBase call this Human Process Management (which is what people may refer to as BPM 2.0).

In the post, The ‘H’ Bomb in Business Process Management, they state how traditional BPM does not reflect the reality of work:

"Human work is: Dynamic Tacit Ad hoc Crossing boundaries and silos Saturated with peer to peer interaction If you want to manage a human workflow like fraud investigation or a product change request or any other, you need to accept the “chaos” and face the facts - structured, rigid process does not fit into this paradigm."

Following on, the post, What is a Human Process?, re-iterates what has already been reviewed in this post, ie. the co-existence of routine and tacit interactions:

"Human processes are business processes that generate a business outcome that is heavily dependent on interactions between people. These are also called “tacit interactions” by economists, which is an attempt to differentiate between routine transactions and interactions that rely heavily on judgment and context. These “tacit interactions” are the most prevalent kind of business processes in which knowledge workers take part. Most of the work of involved in executing these human processes is with the communication, coordination and management aspects of the process. Currently most human processes in business are executed using standard productivity tools (e.g. MS Office), email (e.g. Outlook) and meetings.

I have listed just a few of their characteristics involved in human processes:

"Unstructured - there is a standard framework for the process and how to achieve the intended result, but each case is handled separately and requires human understanding (for both decisions and flow) as part of the process. There isn’t enough standardization between instances of the process that allows for a formal, complete and rigorous description of the process end-to-end. Dynamic - the flow of the process changes on a case by case basis, based on available information and human decisions. A flow can also change while the process is being executed based on new information, or a changing environment."

Then they put it altogether as, What is Human Process Management (HPM)?

Mike Cohn takes this to the human behaviour, and change aspect, where enabling and empowerment from the bottom-up is key to adoption, as workers have a finger in the process pie that they will be using:

"None of the agile processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry. As Alistair Cockburn once told me, “Having a chance to change or personalize a process to fit themselves seems to be a critical success factor for a team to adopt a process. It’s the act of creation that seems to bind teams to ‘their own’ process.”"

Enterprise 2.0 - Complementing and Supplementing existing processes, and assembling new ones

Bertrand Duperrin has an excellent post on the three streams of enterprise 2.0 which puts an understanding out there that enterprise 2.0 is not about some isolated fairy-shary thing that happens on the edges of the organisation…he also posts about it here. Besides serendipity, and formal communications, it’s also about complementing and supplementing existing processes. He says:

"Becoming an enterprise 2.0 is not a goal for any enterprise and should not be. The only one is : improving the way things are done everyday, the way it produces. But what does “production” really mean ?"

1. Formal Production Capability (FPC):

"Being able to produce something defined, following a process in which everyone knows exactly what he has to do, when, and how."

2. Ad-hoc Production Capability (APC):

"Being able to overcome any breakdown or insufficiency […] goods and services have to be more and more customised. As a consequence, production is less and less standardized and the need for readjusting it according to clients who have more and more specific requests is not an accident anymore but a norm […] their unpredictability has to be admitted and a framework has to be defined in order, even if things are not under control in the strict sense of the word, they respect some essential rules. Paying no attention to that and focusing on the traditional FPC causes many dysfunctions and put employees in unbearable situations."

3. Serendipity production Capability (SPC):

"Being able to innovate and produce unexpected things […] has to be facilitated because it’s key in a disruptive economy"

He puts this into perspective using a comparison table, and concludes:

"…businesses have to develop these three points. Not one of them, all of them […] Companies should facilitate the switch between these three systems because it’s what people need to get things done […] There’s no unique satisfactory way of doing things. People have to know how to switch from one to another.

Bertrand has a related post on being adaptive and agile, which I will highlight in a future post.

Co-existence of processes and ad-hoc work

Many I have quoted admit that "process" is a good thing, but extreme standardisation, rules and rigidness can trap people, creating unproductiveness and inefficiencies which is counter to what you are trying to automate in the first place. The key is for some flexibility in the process to cater for change, contexts, and the unpredictable…and to also be able to assemble people and tools to create your own ad-hoc processes.

Ross Mayfield on the folly of process extremism:

"…processes can become calcified and accepted as the rule even when they do not work and make no sense."

I like how Ross sees a process more as a framework, that can be built upon or bendable (similar to Ross Dawson’s view of enterprise 2.0 approaches):

"A process is like a standard. It provides a common definition for others to build upon. This is generally a good thing […] At best, a process should serve as a reference model. Something that others can reference when completing a task. Something that can be leveraged for innovation, a boundary condition for experimentation at the margin."

Nicholas Carr shares his middle ground:

"…meticulously defined and managed processes continue to be a powerful source of competitive advantage for many companies. Look at Toyota, for instance. Its highly engineered manufacturing processes not only give it superior productivity but also provide a platform for constant learning and improvement. The formal structure, which is anything but democratic, spurs both efficiency and innovation - productive innovation - simultaneously"

Nicholas talks about how new tools complement processes:

"The simple group-forming and information-sharing software tools now being introduced and refined will often provide greater flexibility and effectiveness than more complex "knowledge management" systems. But even in these cases, processes aren’t going away; they’re just changing. There can’t be organization without process."

He concludes:

"Bad processes can destroy individual initiative, but well-designed processes, even very formal ones, can encourage individual initiative and, importantly, guide personal and group creativity toward commercially productive ends. I’m not sure you need to balance process and people so much as harmonize them"

Irving Wladawsky-Berger reminds us not all processes deal with unstable environments:

"…we need to standardize those processes where differentiation brings little or no incremental value, so as to avoid the huge inefficiencies involved in re-inventing the same process over and over again."

And also share’s his middle ground:

"An innovative business looks for the proper balance between process - covering those aspects of the business that can be designed, standardized, and increasingly automated - and people - who bring their creativity and adaptability to handle everything else. In a world that keeps getting more and more complicated and is changing faster and faster you need both - but even more, you need the innovation which, when all is said and done, is the truly human element."

Mark Masterson’s insightful take on it is:

“The problem is not business processes. The problem is trying to automate business processes."

Mark’s insight in detail:

"We are more efficient than before, but we’re disappointed nevertheless. Yes, our coordination costs are lower than they were with ad hoc and / or manual processes. But now we want more! We want to keep enjoying these improvements in efficiency and productivity, but we want the creativity and innovativeness back, which we are somehow certain that we’ve lost"

Phil Gilbert reminds us where we started:

“The traditional notion of a business process comes from the manufacturing world where you can standardise the inputs and outputs of a given process,” he explains.“With ‘white collar’ processes, the very reason you have human beings doing them is that you cannot standardise those inputs and outputs.”

Sigurd Rinde reminds us too:

"If work was like a water flow and the given framework was the pipe it flows through, then BPM would be the system whereby pipes were shifted from side to side and valves opened and shut to direct changes to the flows. Good enough if the flow is water. Not so good if the water molecules had a mind of their own and actually were able to make directional decisions underway. Funny thing, people can. And more; it’s wanted because people are smarter than machines and that’s why you hired them. Ever broken business rules or botched the main systems just so you actually can get your job done? But of course you have."

This takes us, as always, to being more effective and agile.

Mike Gotta quotes a HBS article:

"Many organizations struggle to balance the conflicting demands of efficiency and innovation. Organizations can become more efficient in the short run by replacing costly, unpredictable problem solving activity with consistent, streamlined routines. However, this efficiency often comes at the cost of long- run adaptability. The more organizational activity is dominated by stable routines, the less the organization learns, and the more rigid and inflexible it becomes. To escape this fate, the authors of this working paper theorize that highly disciplined organizations must actively engage in strategic and selective perturbation of established routines. A perturbation interrupts an established routine and creates an opportunity to innovate and learn."

Endnote

Often enterprise 2.0 is synonymous with "emergence" and "free-form" which mostly relates to what surfaces from people sharing and conversing about what they know. But "emergence" and "free-form" also relates to "processes"…how do I work around a process by being empowered with new bottom-up enabling tools. And what may emerge from using these free-form tools is things like a wiki page to list what to do in different contexts, troubleshooting tips that complement procedures, etc…see my post, Wikis for exceptions and process failures.

In the future I want to look more deeply into integration 2.0..social computing blended with designed process tools.

This post could keep going but I’ll stop here. Some related areas are; the addiction to Best Practices, stifling innovation, Management 2.0, Plans and Targets, and Complexity (uncertainty, unpredictable)…which I plan to post about.

Related

Socialize your business ? What does it mean ?

The Everything 2.0 discussion - the real issue

Process problems and one answer from thingamy

Process flexibility

People versus Process

On Process, Technology and Work Design

Process is an embedded reaction to prior stupidity

A while ago I posted about using wikis to handle process failures, conversations around objects, and activity-centric collaboration; well these posts highly relate to informal processes and ad-hoc collaboration, which is something Jordan Frank know’s a lot about, and which the software firm he works for (Traction Software) can deliver in a way that really differentiates them from other players in the market like Jive SBS, Socialtext, Open Text Social Workplace, etc… I have left out the IBM Lotus Connections suite as the "Activities" module is in the same ball park as Traction.

Below is the video and some notes.

Jordan talks about processes and ad-hoc work using social tools:

• Workflow systems are great until they fail…a need to have a collaboration safety net.
• Collaboration is not necessarily about making the things that are planned go right, it’s about dealing with the things that are unplanned that go wrong.
• When something challenges the system, and the program team cannot deliver on time (things don’t go to plan…dealing with change and new context).
• We get into case where all of the work, and all of the value for our knowledge workers happens when things break…we change the plan, we discuss the issue, we adjust our priorities
• Besides social tools to help you workaround exceptions to business processes, I like how Jordan alludes to using social tools from the start, as new comers can have access to existing information to help sense-make when something goes wrong (rather then be sent a bunch of emails to make sense of). It’s hard to troubleshoot when what happened till now is not easily accessible or not recorded in a raw fashion…think Google Wave playback as a solution.
• You can’t anticipate a workflow for fixing a problem (with social tools like Teampage) you can model informal processes on the fly
• Jordan talks about a process for document approval, but the problem is by the time it’s developed the process is changed; further to this certain contexts present changes to how you action this process…by the time the process is designed it becomes unable to flex to these other ways to action the same process…and the designers aren’t able to keep up with the people.
• Jordan explains a simple DIY process that doesn’t need a designer and is totally adaptable to changes eg. Document review - tag document "toreview" and send to reviewers, they all leave comments. The person who approves it reads through the comments, and if is happy will tag it "done". This is just one example of a grassroots process using enabling tools that helps workers do their thing…a change from top-down centralised (planned/rigid) to bottom-up distributed (on-the-fly/flexible)
• Shifted from physical imposing of structure through databases and programming, to the more flexible managing by metadata (enforce rules by tribal power rather than constraints that you put into the rules in a program)
• More capable to flexing of today’s needs and changing with tomorrows needs…make sure when business conditions change your business processes don’t get left behind…why do business processes that were designed for two years ago, when we are trying to tackle objectives for today

Here’s a Traction whitepaper that demonstrates using social tools to actually do work.

In another interview on Bas Reus’s blog (which is one of my favourites), Jordan talks about riffing off existing structure and constraints:

"Key is to make use of existing organizational structures, and play with constraints. Keep them, make them or bypass them where necessary. Structures can always change…"

"Zone defense is a bit less structured than man-on-man. Zone defense requires constant adjustments and on-field co-ordination. So, there is a structure indicating an area a player defends at the start, but the structure may change as a play is executed and the players self-organize to adapt."

Here’s a link to a video overview of Traction Software, and a link to the rest of their video’s.

My posts of late have been on the DIY meme, which is possible now that we have enabling social tools. These grassroots tools empower you to achieve part of your vision, and hopefully your visibility will lead to others helping you finalise it.

I’m hoping that my current project I’m tinkering on will be an example of this concept. I’m not building it using social tools, but I will spread the word using social tools.

I figure you get more participation with some good design thinking. That’s why my vision is for a browserless desktop app that streams latest content from our CoPs and allows you post to the CoP eg. something like Tweetdeck.

Now I’m not a techie person, I have limited skills…but my limited skills will get me further than trying to get something approved and developed. This idea would not be seen as important, but hopefully it will be once people are hooked on a Proof of Concept version.

I have made a HTA file on my desktop that opens a little pop-up box. It lists all the blogs, forums and wikis that I regularly use, and even has links to the post entry form for each object.

This is so much better than opening a browser and using my Favourites, and better than a desktop folder with lots of shortcuts. My little app is nicely presented as a list with some fancy javascript accordion features, and a window that rolls-up. BTW - I don’t understand how it works, I just found stuff on the net and chunked it together and tested and tweaked it till it worked.

I can share this file so others can use it. Even better I have the contents of the file in an iFrame the refers to a HTML page on our server. This way I can write new versions and not have to re-issue people new files.

Anyway, so far so good.

But what I really want is to be able to publish content to the CoP from inside the app (which I can already do if the links open within the app, but this is not ideal). I also want to see streamed content. And it would be good if my app could be turned into a generic form so people can easily make their own apps without needing to know any programming.

At the least I hope to see a cosmetic change…since I have taken away the border and the title bar you cannot drag the HTA window, so I’m hoping someone knows how to make my HTA file a window you can drag.

Anyway, my Proof of Concept will be posted in our communities.

Hopefully someone will see it, and get good use out of it, another may know programming and re-mix it to work better, another person may want to rebuild it using MS Silverlight or Adobe Air…who knows.

If it really caught on and people did not want to be without it, it might get some resources thrown at it…all thanks to Proof of Concept and the visibility of Grassroot social tools.

This example is about using social tools to get your invention visible, but further to this the invention itself may be built using the social tools…this is now all possible!!

Glass half-full

To achieve your vision you may not have everything and everyone at your disposal. But that’s OK, just use what you have at your disposal. The important part is having the grassroot tools to enable you to make your thoughts visible.

In a past post I mentioned that our Communities of Practice were originally for people in different teams or even the same teams that had like interests. eg. people from 5 different teams and offices may be experts in "Flash programming", so they set up a group space to benefit from each other.

But since these tools are so flexible we had CoPs being used for unexpected use cases, like initiative task forces, support sites, office website, task rooms, etc…

Our CoPs surfaced all these needs people have that are beyond CoPs. It teased out needs like our official support database needs to be less rigid as some teams are using a CoP instead, business unit spaces need to have social tools as BU’s are using CoPs instead of the official space, etc…

So in a certain light our CoPs have become a "Proof of Concept" for surfacing other unmet needs.

Rather than a team complaining and requesting about a better support database or better business unit spaces, they just used what they had at their disposal to achieve their needs…we are great self-organisers. This is the true essence of grassroot tools.

Due to our CoP tools, and our organic process of creating them we are able to indirectly use them as Proof of Concepts. Perhaps now the official support database may look into a crowdsourcing feature, perhaps business unit areas will have a homepage rather than just a bunch of folders…or perhaps they are happy to stay with what the CoP offers them.

People could of talked about these needs forever, and management may even agree with this need…but things go on the backburner…you have to wait for requests to go through the right channels..approvals…charters…money.

The answer is use whatever tool you have, and rather than talk the talk, walk the walk with a Proof of Concept.

There’s a difference in hearing and discussing something compared to actually using a prototype and getting that "feeling" from using it…it has a more profound effect as it’s experiential.

Summary

You have the idea, and talking gets you nowhere, so you use some grassroot tools (thank-you web 2.0) as a Proof of Concept, and this visibility gets you noticed. People you don’t know see it, and think it’s a good idea, someone else with a similar use case may apply it to a different context, a viral effect may ensue where lots of different groups are using it and improving it, someone else high up in the chain may come across it and may say why isn’t this made official.

You get the idea…visibility is king, and grassroot tools help you get there.

Not only do these social tools help you get there because they bypass the hierarchy, and it’s information flows and approvals (basically your Proof of Concept can go viral and touch lots of people…you no longer need authority as you have influence by reputation…you are networked.) But the actual tools getting you connected, can be the same tools that your Proof of Concept are based on.

In my last post I mentioned some teams have noticed our wiki tool and are self-organising a way to do onboarding. Not high-level onboarding, but at the level of what new comers need to know about working in that business unit. They are not going to wait for an official way, or approval to do it their requested way…instead they are using the tools at hand and going with it. Maybe the idea is to get in trouble, but when you get in trouble they might decide that they like your prototype and give you resources to do it properly.

Get visible, get in trouble (well, be cheeky), get a proof of concept, get social tools.

This goes hand in hand with a culture of autonomy, experimentation and acceptance of failure as the road to better productivity and performance…and innovation.

Previously I posted on the ability for the bottom-up use of free-hosted tools as a way to bypass the usual channels to try something out…basically you don’t need permissions…this may sound anarchistic, but it’s simply true…people may not pay attention to their rogue behaviour for long, all they see is that they are able to work more productively. All companies can do is monitor and observe, and then shut-down or harness.

When you think of it this is a basic principle of emergent systems. The top are open to allow a pot to boil to see what percolates, emergence arises (not all ideas and strategies have to come from the top), and they can then make decisions based on the outcome.

Anyway, in the next post I talked about this type of experimentation and compared it to pilots, in the realm of enterprise 2.0 implementations.

NOTE: I used the term "enterprise 2.0" because more people will pick up that post and read it, but more accurately I mean introducing social platforms and the adoptions of these into the enterprise. Enterprise 2.0 is a state we one day may reach that will transform the structure (hierarchy blended with networks), operations (from competition to cooperation/collaboration), and the way organisations are managed, as described above (complexity eg.the Cynefin framework).

In this post I want to talk about the benefits of experimentation or "Proof of Concept", over a suggestion.

I facilitate many Communities of Practice (CoPs), and I do this by facilitating the facilitators.

Another thing I do is react to things I see around me, and imagine how they can be re-purposed using community tools. I contact the person to make the suggestion, but I’m finding the "suggestion" is not enough…Proof of Concept" speaks louder than words.

Eg. IT send out an email newsletter on Tips and Tricks

• some sections are excerpts and link to a PDF to read more.
• I suggested that each section in the newsletter could be a blog post (more timely, feedback)
• this way the newsletter becomes a digest of the blog posts over the last month, that is presented in newsletter style

In another example I put together a presentation on some recommendations on how social tools can continue the conversation after an event, and how the presenters could have blogged their monthly happenings and roadmaps in a blog as a pre-cursor to the presentation…but it’s still not enough.

Even if they agree, they might not be savvy enough, allow time, or find it hard passing it by their boss.

The new approach is, "Proof of Concept". Just seed it, get it started and then let them take over…you get the ball rolling, rather than talking about a ball rolling. Momentum is king here.

Feeling it, rather than hearing it, has more impact…people just need a little push or offering to get started.

BUT, when you oversee lots and lots of CoPs it’s hard to find time to go further than a suggestion. You need to be able to build a network of volunteer activists to help you out. Sometimes this happens in a self-organised way…some of our CoPs have success in using social tools for a particular use or process, and when these facilitators are in conversation with others they naturally share the success in the way they have done things…this in essence is the viral effect.

Show and Tell

I have lots on my plate at the moment, but my priority is going to become CoPs-in-Action.

What is this?

I have been collecting lots of use cases that have emerged by various CoPs…people are using blogs, forums and wikis in ways I didn’t think would happen. Lots of these are both Above-the-Flow and In-the-Flow, but what I really want to hone in on are the In-the-Flow cases. People are also using CoPs in the way you would imagine like troubleshooting, calls for help, announcements, looking for stuff, sharing stuff, etc…

I’ve already posted about the emergence of different types of CoPs, in this post I’m now talking about the types of activities that have emerged in these CoPs.

At work I’m going to run workshops demonstrating the business value of social tools that goes beyond sharing and learning…these type of use cases are more tangible as they demonstrate what’s already being done only doing it a better way eg. broadcast team announcements, creating lists, discussing and coordinating a task. And showing examples of what people are doing. eg. A project control team using a wiki for answers to common questions, BU’s using wikis as an onboarding tool, the L&D team using blogs, forums and wikis to do a task like a global e-learning initiative (and the actual end product is a wiki), the L&D team using a forum as a place to ask questions after the presentation is over, etc.

…these initiatives didn’t come from top-down, they were grassroots things started by passionate people in those teams…now we have the ideas and have the enabling tools do the execution…no more waiting, as you are empowered.

You may be happy with how social tools spread your idea, or how the tools themselves built the idea…if not at least you built a Proof of Concept, which is more tangible than hearing a pitch…management may like it and throw some resources at it.

These workshops that will demonstrate what others in the company are doing are a Show and Tell exercise..and the intention is a viral effect.

Show and Tell is good as it demonstrates business value and use cases for others to learn from each other. To help the viral effect, or parallel push along side it, exercises like Blog and Wiki Raids are a good way to workshop with a team on an actual use case by using the tool in the workshop. Then when they go back to their seats they have first hand experience, and may continue using the tool.

Sometimes it’s hard to explain the benefits and use of a new tool, it’s better if people "feel" it…it speaks for itself, it has more impact. But it’s just hard to make time to sit with each group, so you may need to find a network of volunteer activists. Ultimately we hope for the viral effect to become so embedded that it becomes part of the culture.

Peer influence

Just the way Proof of Concept and pilots are similar, so is peer influence and the viral effect.

I have talked to managers about CoPs and collaboration and they really see the benefits and intend to use them. But they go back to their seats and don’t have time to experiment.

Yet if they see the benefits that a peer is getting out of them, or a peer recommends the tools saying there is some ground work, but then in the end they are better for it…then they more likely will give it a try.

Training, and presentations only go so far. You are more influenced by people in your peer group, people you trust..these are conditions for a viral effect.

Conclusion

Instead of waiting for what you want or instead of making a suggestion, use grassroots tools to DIY, or as a Proof of Concept. Some of these applications can be as innocent as complementing a newsletter with a blog, or using a forum for discussions after the presentation is over. And some, like perhaps using wikis to onboard BU’s, could be seen as a control and authoritative issue from a management point of view. But from an autonomous point of view your concept may have fans, and you can’t fight the crowd, or something that is viable and has increased productivity…this can be seen as disintermediation, rogue behaviour…or it can be seen as engagement, innovation…a change from extreme management to leadership blended with management.

My previous post, Skip the buy-in and get ’em addicted, is about using a Proof of Concept and beyond model as a fast track to your fulfilling your vision. A way to penetrate the hierarchy in an unorthodox way, and get them to "feel it" and see living proof of it’s usefulness, rather than a Powerpoint pitch, or proposal document (or as living proof of your proposal).

It’s cheeky, but you are doing them a favour at the same time, as you have living contextual proof of the viability (by going ahead and doing it yourself), as opposed to buy-in approval, strategies, time, more time, and some more time…only to not get approved.

The decision-making doesn’t have to be bottom-up, perhaps management agree with a no-cost Proof of Concept as part of the strategy, this is a win for them as they are able to experiment and fail for free, something that was not possible in the enterprise tool arena a couple of years ago. Free hosted sites like Yammer for micro-blogging, and others for blogging, wikis, bookmarking, etc…make all this possible…a move from the Albatross to the Salmon.

Experimentation

The ease of Proof of Concept using social tools is an example of Dave Snowden’s Safe-Fail concept; Clay Shirky also talks of experimentation and low cost failure. Clay talks about organisational costs getting in the way of experimenting and finding the most optimal road. Rather we except sub-standard roads based on them being less risky and more predictable…not really the agile road to innovation at all.

Clay says:

“…most organisations attempt to reduce the effect of failure by reducing its likelihood [and cost]. Imagine that you are spearheading an effort for a firm that wants to become more innovative. You are given a list of promising but speculative ideas, and you have to choose some subset of them for investment. You thus have to guess the likelihood of success or failure for each project. The obvious problem is that no one knows for certain what will succeed and what will fail. A less obvious but potentially more significant problem is that the possible value of various projects is unconnected to anything their designers say about them…in these circumstances, you will inevitably green-light failures and pass on potential successes. Worse still, more people will remember you saying yes to a failure than saying no to a radical but promising idea. Given this asymmetry, you will be pushed to make safe choices, thus systematically undermining the rationale for trying to be more innovative in the first place”

But now with social tools you can experiment many options, which in the end is less risky as you are doing what you propose but at a low cost, if not free. What more would a manager want…they don’t have to predict the worthiness, they can see it and taste it. In economics this is collapsing the "opportunity cost".

The other important point is "emergence". You really don’t know what unexpected behaviours/uses may surface unless some experimentation happens. A product is not it’s design, a product is how it’s used. Just look at Twitter; it’s original intention/design was SMS text messaging, but look how it’s being used now; SMS is probably the least way people use it. And look how many different ways you can access it; 3rd party web, apps, toolbars, system tray,etc..And look at the new core features like, re-tweets and mentions, that have been incorporated into the design because people were using it this way. And look at all the use cases, originally it was about sharing what you are doing at that moment, now it’s being used as a customer service and promotions tool by the biggest companies on the planet…personally I use it for research, sharing links, getting help, and talking to rockstar consultants.

Imagine a project like Twitter was given the red-light as it seemed too risky, or other projects seemed less risky. We don’t even know the impact of the initial features and conceptual use case till we use it, let alone all that emergence (it manifests/has it’s own life…a teme).

[ADDED 12/05/2010: Some of the unexpected ways Twitter is being used may be an example of Exaptation]

Pilots

Proof of Concept is kind of similar to the idea of a pilot or even a prototype…you do something light weight and on a small scale.

But is a pilot different to experimentation?

Pilots are not about feasibility, aren’t they just the stage before release?

Usually pilots are more official. A product has been chosen, there is a strategy behind it, and the pilot is simply an early run before launching to make sure everything is working OK. But prior to this, did you experiment with other products, or did you choose the less risky or what seems as the more appropriate?

Is experimentation the stage before a pilot or is it an alternative to pilots?

The labels "experimentation" and "pilots" are sometimes interchanged. A while back at work I made a request to use a micro-blogging tool from our current content management vendor. There were many meetings (plans, security papers signed for hosted data) and away I went. I was given the product and invited a group of people to use it. At the time this product was performing badly (pretty much alpha stage so we didn’t take it further). But if it became a successful run we may have decided to purchase it, but from the beginning this was not the explicit intention, rather it was to have a go and see what it does (we did not have any strategy documents or a roadmap).

So did we run a pilot or experiment?

Does the fact that it wasn’t open to everyone have any weight on this distinction? Maybe, because of the low numbers it was a more controlled experiment, rather than a pilot?

Maybe it was an experiment because we had not bought the product as of yet, there was no strategy or roadmap?

Or maybe it was "experimentation" because it was bottom-up, rather than a top-down strategy. But I do not see why top-down ideas cannot be experimented, rather than deciding and planning on one path of action.

The context of pilots, and groups vs networks

You can pilot a Community of Practice (CoP) to get an idea of how a group works and coordinates in this new environment. All you need is a group of people to manifest the concept. And then we imagine it’s success would work for other types of groups…not always the case.
A good idea in your pilot would be to run a few different types of groups, to showcase the flexibility of these tools, and how their unstructured nature lends to different use cases ie. these tools aren’t necessarily used in one way, like an ATM machine is designed to be used one way.

One thing you can’t measure or see the benefits in piloting group spaces is see the value that visitors get from your community. Visitors to your community may ask questions, or provide answers, or read a wiki page or blog post and utilise that information. I say this because a pilot is a small scale, which means you ’aint gonna have many visitors, unless they are members of another CoP within the pilot.

I guess what I’m saying is that a pilot will not show the signs of cross CoP action. It will not demonstrate awareness and communication across groups…you know that silo bridging thing.

Just to be thorough when it comes to another dynamic like social networks, a pilot really isn’t as useful.

Unlike group spaces, social networks rely on network effects to reveal their usefulness and emergent nature.

eg. your telephone becomes more useful when someone else gets a new phone (ie. they join the network). A pilot with 5 people isn’t going to show the potential benefits and use cases that emerge when everyone is connected.

eg. Same goes with Facebook, etc. When I’m connected enterprise-wide I can see tag clouds, I get recommendations, I can see who is connected to who, serendipity will lead me to useful content by someone I don’t know but need to know…critical mass is needed for optimal emergence or gifts you receive from taking part in the system.

Andy Mcafee in his Drop the pilot post talks about the limitation of pilots in the context of social networks. Themes I got out of it are: #emergence #serendipity #awareness #diversity

From this post:

"How many of us have found great information in some weird corner of the Web, someplace far from the presumed authorities? How many have had a question answered on Twitter by a stranger? Received unexpected praise or good wishes on Facebook or LinkedIn from someone we hadn’t thought of in a while? The smaller the scale of an ESSP deployment, the less likely all these good things become. These realizations lead to an answer to the second question posed above. Enterprise 2.0 enthusiasts should abandon pilots and go as broad as possible right away. The risks of doing this are small and manageable, and the serendipitous benefits are many."

For more on this see my post, Do group tools get more traction due to not requiring network effects and being in the context of certainty, which was inspired by a couple of posts by Michael Idinopulos called Skip the Pilot, and Launch E2.0 broad, then go deep.

Microblogging as a Stepping stone

In the latter link Michael talks about low threshold participation tools like micro-messaging as a stepping stone to higher effort tools. And he is serious about this as the company he works for, Socialtext, have their micro-blogging product, "Signals", both within the social software suite offering, and also as a standalone product. Michael says:

"Signals was not just a useful tool, it was also a stepping stone that helped participants move to the right on the Participation curve (see image above). As participants started to get the hang of Signals, many started to ask about Socialtext’s other collaborative features: What are workspaces? How do I use the Dashboard? How do I look up an individual? After the webinar was over, a number of users wanted to go deeper by creating wiki workspaces to collaborate on tasks, projects, documentation, etc. We scheduled follow-up time with them to understand their collaborative needs and build tailored solutions. This story describes a launch approach that simultaneously achieves seemingly conflicting objectives: Launch quickly and cheaply, without investing a ton of time or money in training and content creation. Achieve scale by inviting lots of people. Minimize risk by making participation opt-in rather than mandatory Generate active participation through interactive launch events that don’t require a lot of training or engagement from the new user. Deliver deep value by following up with local champions who want to invest time and effort in more robust, group-specific forms of collaboration."

Pilots as learning stage

A post by Bertrand Duperrin about the Enterprise 2.0 Forum relates to pilots being about learning (rather than testing) before the official release, which is different to experimentation where something has just been made available, and is more about trying and testing:

"It’s not a game anymore. Now projects are global and carried by the top management. That’s the end of social bubbles disconnected from reality. Companies think global and pilots are not made to test but are the learning stage before global rollout. I really appreciated Claire Flanagan’s approach that set a time limit (5 month) instead of limiting the number of users what allowed her to quickly get a critical mass (nearly 30 000 users) with an opt-in policy."

In another post Bertrand reinforces this point:

"The purpose is not to decide to carry on or not but to learn what will be needed to drive the program at a wider scale later

Bertrand also mentions not to throw the baby out with the bath water, that we have to learn from failure, that failure is part of the path. An analogy of a car is quoted:

"…if a car does not function it’s not because the concept of a car is bad, but because either the fuel is not good, the transmission is brocken or the engine is not well set."

I often say that just say someone new to a vegetarian diet finds themselves not feeling very well, it doesn’t mean the vegetarian diet as a lifestyle is wrong, it just means that person was not very good at being one as they were not aware of all the food groups they need to cover to be healthy. Maybe they were not eating enough foods with vitamin B12, they can learn from failure and keep going on their new path.

Bertrand then says something related to the Clay Shirky excerpt at the start of this post, and that’s the notion of "risk"…and the use of the word "experiment" may have bad connotations (as does the word "social" in a business context), where usually business decisions are very carefully thought out to minimise risk

"We can be sure that employee will think, even unconsciously “I’m fed up with all their crazes…I won’t buy before it’s definitive and official…no time to waste for something than can be shut down at any time…being a part of it may expose me and it may be a bad idea if the project goes wrong”. I already heard an employee saying “experimentation…do they think we are guinea-pigs ?”. Explaining that the experimentation is not “on” them but “with” them is easy…but never happens. Anyway, we must be aware that this word means lack of visibility and indecision, what is not reassuring when trying to engage employees."

Bertrand goes on to compare this to pilots where it’s not about feasibility, but rather a decision has been made, and the pilot is just the phase before the release, but it’s important to understand that…

"…the direction is known but that the path will be decided with them, hence the pilot…the company knows where to head to but must be aware of not being too directive or interventionist."

---

[ADDED 12/05/10: Drop the Pilot, Part 2

“…you wouldn’t dream of piloting a telephone with a small team.”

“We recently persuaded a large Socialtext client in the publishing industry to abandon a pilot-first strategy and launch enterprise-wide. They were glad they did. Their intended pilot audience showed adoption which was good, but not great. In the meantime, the rest of the company started using Socialtext to create all kinds of unintended interactions […] A lot of that would never have happened in a pilot-first scenario.”

“Andrew, I couldn’t agree more with dropping a “limited reach” pilot. As you know, CSC did run a pilot, but it was limited only in duration, not in audience. That meant any of our possible 92K+ employees could participate if they chose on an opt in basis. This allowed us to truly validate the viral nature, if in fact our strategy met the mark, and allowed us to watch collaboration patterns emerge… We created a multi-layer advocate program that included a top down and bottoms up approach. We emphasized self-service over a traditional centrally managed approach to communities. We seeded our environment with compelling business use cases prior to launch so users were greeted with real business groups and communities. And we also remembered the value of a “watercooler” in forging strong bonds across the globe. These practices, and more, combined to make the pilot so successful that the results truly demonstrated to our leadership how this could be used for business, solidifying our business case. Our users had clearly voted with their feet – and we had the data to prove it. It was an easy decision for our executive sponsors and CTO to continue funding operations into a “production contract”.”

“Sometimes something needs to be called a pilot to get executive buy in. So labeling a phase a pilot is a clear way to signal to your company (and perhaps even your vendor) that you really are in a trial stage where the commitment, risk and investment are limited. That is often a huge way to start something sooner while a larger business case is evaluated. So I think the label of a “pilot” has very strong political meaning…” Michaelbierly evidently agrees with this; he wrote: “will [not having a ‘pilot’] work? not in a typical corporation. Too much culture to change on decision making around IT to say we aren’t going to pilot.”]

[ADDED 21/05/10: Setting up a pilot is not only a matter of sizing

1°) The question of a preliminary phase

Before going further, what matters is to know if a preliminary phase is needed before scaling up the project. Obviously the answer is yes : businesses need to be sure they can manage things and get some kind of benefits on a smaller scale before applying a new concept to the whole organization.]

[ADDED 5/06/10: Piloting Social Media Creates More Risk Than It Mitigates

“This practice is not prudent for social media where the software complexity should be minimal and the primary goal is to get people interacting. Community participants are fickle and unforgiving (especially external communities). You may only get one shot at catalyzing community formulation. Don’t pilot, test, prototype, or experiment on the community. Don’t artificially restrict participation. The law of numbers is a critical factor in building a thriving and productive community. Why would you only go after a small subset of a target audience when mass adoption is a critical success factor?”]

[ADDED 16/06/10: Stephen Bounds

“I’d say that the essence of “safe-fail” is (a) trying multiple things in parallel; (b) not picking winners in advance and (c) always proceeding incrementally.

For example, most pilot projects run in two phases. First, run a proof of concept. If that works, roll out to the whole organisation.

Safe-fail breaks the process down much further. The idea is to always do things in chunks small enough to allow for roll-back if negative results occur. So an old-style “roll out” might instead happen as a dozen or more “safe fail” experiments, at each point confirming that results are positive before proceeding further down that path.”]