Embrace emergent behavior to be successful with Enterprise 2.0

Stewart Mader offers insight and adoption advice for enterprise 2.0 projects. I appreciate his take on the subject, especially about allowing emergence:

[…] If you begin using a wiki in your organization and users start doing something differently, don’t stop them, and don’t just let them – encourage them! What they’re doing is probably better then the previous way, and by encouraging them, you’re building loyalty to the new tool that increases its chances of success. […]

Yes, and it’s a good idea to keep it simple, until seeing the patterns that evolve, and then supporting these. This calls for management to let go of its acquired (and hard-earned they are!) competencies and mindset. Yet, modifying deeply ingrained traits is hard.

So, in the light of social software in the enterprise it’s not primary the people, but the architects of organizational collaboration that need to change. This expands the common understanding of change management, and makes clear that enterprise 2.0 implementation efforts must not only address the primary users of the tools.

Organization, ad-hoc or well-defined?

Jack Vinson has some thoughts on an issue Jeffrey Philipps brought up (and that was discussed yesterday evening in a local meeting of enterprise 2.0 folks I attended):

People don’t bother defining their processes because they can’t see how it matters. Maybe they don’t believe they have an impact on the overall business. Or they are trying to protect their “turf” by being purposefully opaque. Or they’ve had a dozen other improvement efforts come through and there has been no real impact on the bottom line.
[…]
Understanding processes is helpful, but it is just as important to know which processes need to be understood. This is a common complaint of flavor-of-the-day programs: the idea is applied to everything in the hopes that it will do some good. It makes much more sense to look at the business and find the few places to apply an improvement that will actually make a difference to the business.

I’d add that
– neat orderly processes are not that ubiquitous and
– that they aren’t as important as most people think.

Especially knowledge (or innovation) work processes can’t be standardized (granted you can support parts and pieces of these processes with standard workflow gear), so trying to manage them into (computerized) workflows and all is not feasible and no worthwhile goal, whereas more freeform tools and concepts like wikis can be easily adapted to variable requirements – and even allow (process) solutions to emerge from within the organizational system.

If you want to know more and are looking for social software support and consulting assistance, contact me.

CIOs on Enterprise 2.0 …

Here’s a lengthy piece from Information Week on Enterprise 2.0, based on a study of 250 business technologists on the merits of going web 2.0 in the enterprise. It holds that business technology people are concerned about the security aspects of Enterprise 2.0 offerings.

Well, yes, compliance, due diligence, compatibility with IT governance and integration into existing infrastructure are valid concerns, and constant topic in my discussions with colleagues and fellow enterprise 2.0 folks.

But overall the article is not too negative about the prospects of enterprise 2.0, because it shows that the concept is gaining traction while being aware that these issues must be dealt with. So I have no doubt that more and more IT departments will start to facilitate the use of “2.0”-tools and concepts, if only because Enterprise 2.0 is essential for extended value net organizations:

It’s a new architecture defined by easier, faster, and contextual organization of and access to information, expertise, and business contacts – whether co-workers, partners, or customers. And all with a degree of personalization sprinkled in.

Yet,

[there’s] this tension between the IT department that wants to have this orderly, planned infrastructure, and you’ve got end users out there experimenting with all these different collaboration tools.

Susan Scrupski tracks some discussions in this field, i.e. the role of CIOs, of IT departments etc.

Equally interesting is Mike Gottas take on the article here.

What is a Blog? A Wiki?

Jordan Frank im Traction Software Blog mit einer Übersicht über Social Software, die u.a. auch auf die Anfänge und Vorläufer eingeht.

Seine Definition (“a baseline definition for both blogs and wikis”) gefällt mir gut, sie ist kurz und macht sehr deutlich, dass diese Werkzeuge Teil eines umfangreicheren Kontexts “Social Software” sind:

a system for posting, editing, and managing a collection of hypertext pages (generally pertaining to a certain topic or purpose)…

Blog: …displayed as a set of pages in time order…

Wiki: …displayed by page as a set of linked pages…

…and optionally including comments, tags or categories or labels, permalinks, and RSS (or other notification mechanisms) among other features.

Fragen der Definition sind meiner Erfahrung nach nur vordergründig akademisch, sondern stehen auch in der Beratung oft am Anfang.

Haben Sie Fragen zu den Möglichkeiten (und Hintergründen) von Social Software?

Sprechen Sie frogpond an! Hier ist das Kontaktformular. Antworten folgen.

Using collective intelligence and the wiki to improve how you work, as you work

Stewart Mader outlines wiki uses in “continuous organizational (team work/knowledge work/innovation work etc.) improvement”:

the wiki can help any group work better by adapting to how they work, and letting them see where they’re strong and weak. Because it doesn’t define the terms of interaction and collaboration from the outset, and allows structure to be created, modified and removed as needed, the wiki quickly becomes a desirable tool because it “learns” how people work as they work, not after the fact.

He’s just right, now I’ll try to elaborate:

One could argue that wikis offer space for emergence, i.e. organizational self-organization.

And one could further add that they are ideally suited to support complex adaptive systems (CAS), and that their inherent capacity for connectivity is fine too.

But all this sounds much too theoretical, and well, we’re running real enterprises – no fluffy complex organizational systems stuff – don’t we?

But theory can be useful sometimes, so calling on the theoretical background of complex systems and systems thinking is a good idea. And when we accept that organizations can be modelled and understood as a complex adaptive system, employing social software concepts and tools feels just right, exactly because they can deal with this complexity …

Is SharePoint Scalable?

Mauro Cardarelli asks the right question, i.e. whether organizations are ready for collaboration software. He puts it like this:

I ask “Is SharePoint scalable [in this organization]?” That is, can this company set the proper governance policies and business process changes to maximize its SharePoint investment to take advantage

Well, on the one hand this is true, but do we always need to fiddle with business processes? Software should be freeform and adaptable to a variety of organizational settings, and social software in the enterprise starts with this premise. In fact I would argue that one huge advantage of e.g. wikis in the workplace is that they can adapt to a multitude of settings …

But his requirements (and best practices) for implementation projects are good:

It starts with building the right advisory team and setting the proper procedures (in writing) that define the guidelines for all users to maximize their experience as consumers AND contributors of corporate content. With that, SharePoint scales… throughout the organization… into your partner/client community… and out into the internet world.

No arguing with this, especially the right staffing of an advisory team (and perhaps also employing external specialist consultants like me, hint hint …) is important.

Does Best Practice exist?

Here comes the question that lies behind many discussions I’ve had in the last days (e.g. here) …

I have started to think about what is best practice in a complex system – can it exist? In complex systems every situation is unique. Whilst practitioners closest to the problem will find a way of solving it, does that mean that the solution to this problem can be adequately codified and be laid over a totally different situation and applied in another context? Chances are that in a small team setting you might get away with this and build models to assist in finding the best solution. But as the number of people involved, and the problems to be solved increase, you will quickly move into new territory with a different frame of reference and set of contexts – so would one “best practice” work?

Hardly, yet best practices are important, which can be used when situations, tasks and (underlying) patterns are similar. Of course best practices shouldn’t be carved in stone but be open to adaptation and tweaking – it’s a start when we don’t understand them as “products” but as processes.

In regard of Enterprise 2.0 for complex organizational systems this makes it clear, that one advantage of light-weight and freeform enterprise social software systems is that they can be constantly improved and refined, whereas (customized) packaged software can’t be tweaked and optimized this way. This follows open-source concepts such as “release early and often” or “fail fast” and puts them to use in enterprise software projects.

This calls for a small start, that is expanded constantly with new services, from which one can quickly learn from user feedback …