SharePoint is on fire. It the fastest-growing server product Microsoft has ever released. Bill Gates, during 2008’s SharePoint conference, remarked “SharePoint is a product that’s based on a vision of letting workers share information in a better way, and making sure that it’s done in a very broad fashion, creating a product that you can assume everyone in a company has access to, and creating templates that everybody is familiar with and they just use as a matter of course to get their job done.”
It has done a very good job of that on the document side. It provides a shared workspace that users can create themselves, and allows to groups to quickly form a collaborative site without IT involvement. In a report I read looking at actual usage of shared workspaces in the enterprise (actually done with EMC, not Sharepoint), the Gilbain Group states “a shared workspace fulfills several roles. It’s important to be able to access easily the single source of ‘the truth’ – most up-to-date versions of items where the shared workspace is the repository of reference. Proactive communications is also a factor. One-third of our respondents use a shared workspace for its communicative capabilities exchanging information, often as part of an ad hoc business process or a collaborative task, and a step beyond sending and receiving email messages.” – Collaboration and Social Media-2008, Taking Stock of Today’s Experiences and Tomorrow’s Opportunities, Geoffrey Bock , Steve Paxhia, The Gilbane Group June 9, 2008.
So how do link SharePoint with the group’s human processes? Well, you could try and use Workflow Foundation – but that is a developer tool – which means you have to get IT involved (to model and code the process, not exactly ad-hoc). You could use another BPM tool that supports SharePoint but again you need IT involved (to model and code the process, not exactly going to happen with ad-hoc processes). So most people just resort to using plain old email along with SharePoint workspaces for their ad-hoc, collaborative processes (same is true for all the other shared workspace products link EMC’s e-room). The problem is SharePoint (just like every other shared workspace product) has no real support for email based processes. That is exactly what “ActionBase for SharePoint” solves – finally a way to support ad-hoc, human email based processes in SharePoint. You can kick off email based processes from SharePoint, and manage and monitor the processes from both Outlook and SharePoint.

I read an interesting post about ECM meets Enterprise 2.0 – 7 key trends. From a Human Process Management perspective the most interesing of the 7 trends was – “Trend #6 Conversations - Content is Just Something to Talk About”. This something I have been mentioning in previous posts – that the conversation (or the way we prefer to call it – the human process) provides that context for documents that are used by the participants in the process. ECM vendors lose this context  since they don’t keep track of the conversations (or human processes) that relate to the document. BPM vendors have the context – but only for structured processes - and they don’t link even that to content.

This also came up during the last WfMC meeting where we spent the day discussing “adaptive case management” (which in my opinion yet another name for what I have been calling Human Process Management). Other people call it unstructured processes (Gartner), some call it Advanced Case Management (Forrestor), some call it Adaptive Case Management (WfMC), some call it Human Process Management (ActionBase), some call it Wave(Google) and some call it plain old Case Management (Global360)  - but it is clear that the space between collaboration\documents(ECM\Web 2.0)  and process (BPM) - is receiving lot of interest.

After reading Keith Swenson’s recent post, I’m convined; we really are addicted to email. There’s no doubt about it. Or rather, we’re addicted to the methodology and mindset of email – responding with messages and attachments when and where they appear.
This, of course, causes complications, not the least of which is tracking progress and status. But we also have the issue of mutliple instances of documents, multiple copies of mailboxes if you log in elsewhere, and in the case of the bottomless pit of information that is Gmail, a complete mess of any and all content.

Are we stuck in a rut?

I’ll be honest, it’s difficult to wade through the multitude of solutions available for collaboration and communication, that are supposed to be the end of email.

Even among my peers, I encounter a strong resistance to web apps and online collaboration tools, and they still prefer emailing documents back and forth.

If we are to fight this phenomenon, it’s likely going to be a long and arduous battle. It took email years to work its way into the workplace, and now it seems well and truly entrenched. Education is a critical component, and teaching people to “put their toys away”, as Mr. Swenson suggests, is an important lesson.

But we don’t like to be told we’re wrong.  We like our familiar tools, we like what we know. New things come along, but Facebook doesn’t help most of us get more work done.

Getting over ourselves

What most of the collaborative tools and web apps I’ve mentioned try to do is make using them almost fun.

37 Signals have a design philosophy that makes their applications sexy, in computing terms. On the other hand, it doesn’t look like something that belongs in an Enterprise environment. It’s also not suited for non-project work, such as ad-hoc processes and short-term collaboration.

MediaWiki puts Wikipedia in our hands, but it’s got a tough markup, and getting into using it is a tough hurdle for many individuals whose time is too valuable learning new tools.

Google’s applications are so ubiquitous, it almost makes sense to default to using them whenever you need to collaborate with someone who’s not in the same organization as you are.

While these tools make a lot of sense for small companies, freelancers, and highly tech-savvy teams, the same is not always true for large-scale companies in the Enterprise category. Their employees are diverse in their levels of use of technology, the organization often wants to have a lot of control over access to internal information, and compliance requirements are higher than ever — something most of these tools aren’t concerned with.

From a user’s perspective, they are all far from providing the kind of control that users feel they have with MS Word, Outlook, and a good solid connection to a Windows network drive.

I myself, being a fan of many things web, am not crazy about having to login on a half-dozen different web apps, chucking things into The Cloud, and trying to convince my colleagues that this NEW web app is the one.

The key, apparently, is letting people use what they like and what they’re familiar with. Don’t try to force-educate your users – they won’t appreciate it. Leverage their existing skills, and work in your philosophy through there. The idea that email, and desktop applications like Outlook and Word are going to vanish tomorrow just because Google release a new application, browser and operating system for netbooks tomorrow, is naive. We’re not selling buggy whips just yet (Or so I hope…)

I have been thinking of how someone would try to specify a “best practice” for a process they are familiar with. The way I describe a best practice is “standard” way of accomplishing a task, based on repeatable procedures that have proven themselves in a specific organization (a bit different then the way Wikipedia describes a best practice). For our purposes the specification of the best practice should be unintimidating, something that anyone can use and understand. It doesn’t need to be rigorously defined, since it is meant for humans, not machines. A while back it seemed to me that writing instructions was the closest to what I was looking for, and I started searching for some guidelines for how good instructions should be written. I found some guidelines on how to write instructions which were all very common sense, but for the life of me I can’t remember where I found them (so please excuse the fact there is no link, anyone that recognizes them please let me know).

Below there is an excerpt of what I found (which focuses on the flow – rather than how to write the tasks themselves) which seems to cover the most used BPMN control-flow elements as found by Michael zur Muehlen at a level which a person can understand. This fits very nicely with how we think of human processes at ActionBase – this type of best practice is a recommendation of how the process should be done – not a rigorous model that dictates it. Having such a best practice document enables us to recommend a next step to each participant in the process – without forcing it upon them. Here

Structure and format. Normally, we imagine a set of instructions as being formatted as vertical numbered lists. And most are in fact. Normally, you format your actual step-by-step instructions this way. There are some variations, however, as well as some other considerations:
• Fixed-order steps are steps that must be performed in the order presented. For example, if you are changing the oil in a car, draining the oil is a step that must come before putting the new oil. These are numbered lists (usually, vertical numbered lists).
• Variable-order steps are steps that can be performed in practically any order. Good examples are those troubleshooting guides that tell you to check this, check that where you are trying to fix something. You can do these kinds of steps in practically any order. With this type, the bulleted list is the appropriate format.
• Alternate steps are those in which two or more ways to accomplish the same thing are presented. Alternate steps are also used when various conditions might exist. Use bulleted lists with this type, with OR inserted between the alternatives, or the lead-in indicating that alternatives are about to be presented.
• Nested steps. In some cases, individual steps within a procedure can be rather complex in their own right and need to be broken down into substeps. In this case, you indent further and sequence the substeps as a, b, c, and so on.
• “Stepless” instructions. And finally there exist instructions that really cannot use numbered vertical list and that do little if any straightforward instructional-style directing of the reader. Some situations must be so generalized or so variable that steps cannot be stated.

I was thinking a lot about the UI in our next version.

ActionBase V6 will have Office 2007 Like user interface and Ribbon command buttons instead of the ordinary toolbar scheme. It only made sense since Office 2007 is gaining momentum and since we believe most of our customers will soon migrate to Office 2007, a toolbar based UI will seem somewhat out of date.

Here is why i think anyone who takes the time to write a meeting minutes document is practically wasting his/her time.
In general we take the time to put things in writing as a way of documenting the decisions, action items and agreements made in a meeting. The problem everyone faces is that two seconds and even before the digital ink dried on your meeting minutes paper things start to change.
Responsibilities, due dates, the nature of action items etc… that is the dynamic nature of people as they work together.
Writing a meeting minutes document is like taking a photo of a specific point in space-time and thinking that this is what is still going on right now…

As things change, people seldomly revisit the document and edit these changes, so the document becomes obsolete, a fossil of a meeting that once took place somewhere in time.

What we really need is a way of extracting these logical entities (decisions, action items etc) from the document and be able to work on them in a collaborative nature like email.
Think of a mechanism that allows you to define action items in a document, and when you are done, these action items are magically transferred to the relevant people and as they work on them, any response, change or collaborative information gathered is documented on the same action item.
Furthermore, the next time you open the document, the changes made in ‘real life’ are propagated back to the document so your ‘photo’ is actually a ‘video’ or a real time snap shot of the ever changing reality – these are actionable documents we call ActionDocs.