Wednesday, August 26, 2009

What is case management? Well I've written a little in the past about about case management as a concept, a component and a product (I won't bore you with a full list, just search the blog) . And Bruce Silver has just put together a nice paper on the subject, using the Case360 product (which I used to product manage during my time at my previous company) as the core for describing the many facets that make up the case management concept.

By using a product to describe the concept of case management, the definition that Bruce creates is both clearer (with real world examples) as well as being skewed by the product. But don't get me wrong - Case360 is a product that I am still very proud of having been involved in, and I know for sure that it lives up to many of the claims. It is also a highly flexible and therefore often overly technical product, and for that it can sometime make the goal of case management harder.

What do I mean? For me, the fundamental attribute of case management is the flexibility it affords knowledge workers to do their job, using their knowledge of what needs to be done. A case management tool should provide a template for guiding work, while allowing 80% of this being unstructured work to comfortably sit inside (or on top of) the 20% of structured processing that exists. For me, the formality of BPM, modeling, simulation, optimization and all the rest, delays the delivery of a solution that should be largely flexible, collaborative and semi-structured. The structured stuff often gets in the way, or forcibly tries to take over the case working that needs to be done. This ends up with the (anti)pattern I strongly believe in: if it's not structured chaos, it doesn't need BPM. When processes get complex, its because they are not being flexible.

At the end of everything, the right tool is the one that workers adopt when they can use it to improve the way they work. I believe that the examples given by Bruce are hard to dispute. I also think that for similar requirements, there is another way. Am I being vague? Yes - and its intentional! Stay tuned...

Thursday, August 20, 2009

'Pave the cowpath' is a term commonly used in workflows and BPM to indicate a rapid implementation that takes the current flow of work, automating it as-is. The cowpath (or goat-track) exists because its a commonly trodden path followed by workers to get the job done, some based on rules (there's a fence in the way and a gate to go through) and some based on convention (a well trodden track is easier to follow than blazing a new course through the long grass).

Yesterday, @dhinchcliffe 'tweeted' about a bulletin for the American Society for Information Science and Technology, which mentions the 'cowpath' in the context of social websites:

This article presents paving the cowpath as the first of five patterns for the design of social websites and applications that are trying to put social elements on top of them. Crumlish's insights apply to workflow and BPM as well in my opinion:

[...]study some of your potential customers. How do they do what they do today? Yes, of course, the thing you want them to do will be better, but is it really entirely different? Can you offer people a way to continue doing most of the things they’re comfortable doing today as you introduce new possibilities into their lives, or are you really going to insist on them changing everything at once?

I know that this goes against the philosophy of process reengineering and methodologies such as six-sigma, since in paving the cowpath you are doing little to remove the wasteful activities in the process. Slapping a tool on to help move work around does not necessarily enhance the underlying process, but it does make it quicker and reduce wasted time while people wait for work to get to them (which is not necessarily a bad thing). In not removing waste or adding more rules, according to Crumlish:

Often the impulse is to stamp out these rogue behaviors and enforce draconian rules requiring only the behaviors you had planned for. This course of action really only makes sense if the behaviors you are trying to stamp out are truly destructive or evil. There are many anecdotes about thriving social sites that killed themselves off by legislating against fun and forcing their users into exile to find the activities they had been improvising “incorrectly” in the site they had to leave.

I also have many anecdotes about business workflows that were overly restrictive and prevented knowledge workers using their brains (1, 2, oh and the one I never wrote about 'cos its not a flattering story) that led to a similar effect: the application failed and was not adopted.

The great thing about paving the cowpath is that you can implement quickly, assuming you don't try and automate some of the completely ridiculous manual things that are done today, and just let people realize they are ridiculous and stop doing them in their own time. With the right tool, you can also play into the second half of Crumlish's cowpath definition:

A better plan is to support the behaviors your users are engaged in. Let your users tell you what the best and highest use of your interface may turn out to be. Don’t be so arrogant as to assume you know everything about how the social dynamics you’ve unleashed need to evolve.

In a business context this means that you, the business analyst or process analyst does not have to sit for 8 hours a day doing the work of the potential workflow users. Analysis can be done quickly and a flexible system implemented equally quickly. And do not assume you know best when it comes to the way workers must interact or handle exceptions to the rules.

Given some time and professional assistance from a process analyst and workflow tool, users can improve their own processes. The process analyst will need to be strong, since 'Management' will always have the desire to put in more rules, not take them out. Go ahead, pave the cowpath, and give the workers a chance to see how a new system might improve their operations. With a new tool in place (e.g. a lawnmower), users could be presented the freedom to forge a completely new cowpath that works better for them. It would be a shame to prevent user innovation through initially overdesigning a new workflow.

Tuesday, August 18, 2009

I always love going back to London, as it gives me the chance to catch up with friends. One such friend is a serial entrepreneur, learning and improving his art with every new venture. His ideas are a source of constant lively discussion and debate, especially when enjoying a local brew. Currently, he's directing the technical side of a social networking site for avid readers, called BookRabbit. Since I knew nothing about the site, we started chatting about its target audience, who was using it currently.

The BookRabbit site is a platform for the broad target audience of 'avid readers' to get together and discuss the books they are currently reading and their favourites of all time. It uses the cool concept of taking a photo of the reader's bookshelf and tagging it with the actual identification of the books on it. This provides the starting point for seeing who else has your taste in books, then providing the tools to build a reading relationship with them. Its a nice idea that has drawn a population of thousands of active users.

So our discussion of the target audience started... The site is targeted at the UK, through design. I initially guessed this design was a technical limitation around the book catalogue the site could use for all book references, and it seemed odd to me that you would limit your potential user base through something as 'silly' as a technical limitation! After all, would it not be better to open your audience to the US, with the potential of adding maybe five times the population? The answer as it was explained to me was 'no', and I have learned something important from this.

The BookRabbit site is targeted at 'avid readers in the UK', since there is just a far better chance that these readers are reading the same books and have similar interests to share. This is what makes the community work. By attempting to bring in the US book catalogue, and a US user base, the community would be diluted, or at least split into distinct groups that would be based on geographical, rather than interest-based boundaries. That makes for a bit of a disfunctional (or rather unscalable) approach to building a community, since the geographical users do not gain much benefit from the presence of the other country and the technology does not automatically enable their presence.

OK, lesson learned. Don't assume that more users makes a stronger community. BookRabbit is smart for sticking to its guns. And I have learned a little more about the marketing and mechanics of social networking sites that are based on specific interests.

So if you are an avid reader in the UK (or at least with a strong interest in British books), and you want to share your reading experience with like minded individuals, take a look at BookRabbit and upload your bookshelf.

Monday, August 17, 2009

To any regular reader who wondered why I dropped off the face of the planet (again...), I apologize. My project in Mexico finished in a blaze of activity (to time and to budget), and was followed by some crazy 'life admin' stuff back in London, then a much needed vacation with the missus.

Get ready for the next round of blogging, now I have my feet back on Boston soil...