I read an interesting article in the last issue of Communications of the ACM on “Evolutionary System Development” by Peter J. Denning, Chris Gunderson and Rick Hayes-Roth. In the article they lament the fact that many large scale software based systems fail (either completely, or fail to deliver on their original promise). Their basic insight is that in order to “minimize risk” before implementing a new system organizations fall back on careful preplanning, anticipation and analysis. The problem is that in today’s ever changing world – by time all that is done (and implemented), the requirements from the system have changed and it no longer meets user needs. Not only that – the system will need to continually adapt since the world continually changes and that doesn’t fit with traditional software engineering techniques. BPM systems help with at least some of the issues, but to be honest I think most BPM system implementations and methodologies suffer from the same ills as the article describes (though with much quicker time to product) – investing too heavily on analysis and modeling before some “good enough” system can be created for users to use and evolve. So even though a good BPMS will help immensely in speeding up the implementation time of structured business processes – the tools and methodologies just aren’t appropriate for most unstructured, ad-hoc human processes. 

The only way to make a usable human process management system is to embrace evolutionary development throughout -from process discovery, all the way through design and implementation. A long discovery, modeling and implementation process just isn’t viable for when providing support tools for human processes. That is why so many human processes are implemented (defacto) using email and documents. Even though email and documents are far from a perfect methodology (and require a lot of human intervention) – their critical advantage is that a “good enough” process can be available immediately, created by the people involved without the need IT involvement. For an HPMS to be successful it too needs to enable a quick first-blush ”good enough” implementation that people can use, and a simple way for the users to evolve that implementation as the process changes (either as a result of changes in the business environment, learning, or to handle various unexpected exceptions). If it can provide that (along with a familiar email and document interface), then the additional benefits of tracking, followup, status visibility and reuse should make it the preferred tool for human process management.

In my next posts I’ll address the first step – using email and ActionMail to create a fast “good enough” first implementation of the existing process that can (and will!) evolve as needed.