Swimlanes - The Tide Is Turning

Theo Priestley has been making waves by kicking off a LinkedIn discussion on one of the great dividing lines of our age: swimlanes.  The humble swimlane continues to inspire remarkable passions,as that discussion demonstrates. Forget a future for the process consumer of iPhones and avatars. The swimlane was there in the Garden of Eden and will probably be eternal, according to its many fans.

But, after working just this week with two more clients eager to escape the swimlane mindset, let me take the plunge [ok, no more swimlane jokes] and offer this thought: outside of BPMN and the simplest of processes - that is, in most of the real world - swimlanes are about as useful as Latin for communicating information about processes.

Swimlanes do have a place. Swimlanes can work for simple linear processes with a clear happy path that aren't connected to much else. Swimlanes can also be a useful aid for process analysts and the IT community at design time. [Nimbus Control has a neat feature to auto-generate swimlane views from the storyboards created for end-user training, which can help with use case analysis and testing at design time.] 

It's true that swimlanes and pools are also fundamental to BPMN, but that's slightly irrelevant here because the rigour of BPMN makes it a language for the IT community - not a language to enable end users to embrace process and drive continuous improvement.

Swimlanes don't work as a way to engage process stakeholders and end users, because they can't handle the reality that life is complex and integrated.  So they can be extremely convoluted, covering many metres of wall space and requiring the intellectual capacity of a chess grandmaster to understand. More usually though, to avoid that complexity, swimlanes drive process fragmentation. Cutting and slicing processes into manageable chunks is the only way that swimlane thinking can be made to work.   

Process fragmentation comes at a very high cost.  We lose visibility of the coherent whole, and risk creating all sorts of sub-optimal results. We are denying the operational reality that many activities within any the enterprise are inter-related and inter-dependent in complex ways. Basically, swimlanes are a 2D way of managing a 3D world.  

Swimlane fans argue that their customers 'love swimlanes'. But the truth is that their customers don't know any better. They prefer processes in the graphical image of swimlanes instead of a 50-page Word document - who wouldn't? They aren't aware that there is a better form of graphical representation that can cope with the operational realities.

Imagine if Twitter had been invented before pen and paper. We would 'love' our poetry and literature that had been developed within the bounds of a 140-character limit. Until pen and paper came along, we would have no idea that poetry and literature could be any other way.  Swimlanes are a similar boundary on our thinking.

The limitations of swimlanes as a means of engaging process stakeholders and end users was one of the drivers for the development of the Nimbus Universal Process Notation language, created as an easy-to-read structured business process notation for business people [and made freely available for adoption by others].

Gulp - challenging the swimlane orthodoxy! Choppy waters ahead ;-)

Comments

[Ashish Bhagwat]

Mike,

I agree with you on some of the challenges that swimlanes may bring in. It's easy to challenge a concept and count the negatives, but let's also agree that swimlanes have continued for the good reasons - all pointed out by the supporters as well.

For a moment, if everyone agrees to this, what would be the solution that you intend to propose? Easy to challenge a concept, but witout an alternative that is stronger and better, this is futile exercise...

Ashish

[Adamdeane.wordpress.com]

There seems to be a bit of a backlash on swimlanes lately. Personally I don’t see why.
I don’t see a reason for bashing swimlanes – they serve their purpose.

I tend to use the old simple flowcharts. Flowcharts have been around longer than swimlane designs and are simplier to use and understand.
Flowcharts are very useful when sitting with non-architects (for example: sitting with the finance department to design their workflows).
It is maybe not the “formal” way to do it but it makes understanding the process easier. It enables me to get feedback from business users and the end-users collaborate more on the design. This should be not instead of a formal process design.

By drawing the process from start downwards (instead of left to right) and writing the recipients on each activity (instead of moving activities into swimlanes) I get nearly the same results as a swimlane design, but without the complexity.

Some BPMSs show the processes in flowchart format, some in swimlanes.
The difference is in their market (architects or non- architects). A good BPMS, I believe, should show both

[Steve Romero, IT Governance Evangelist]

I agree swimlanes can be a less than effective means to engage Process Stakeholders and end-users - when the process proponent takes a one-size-fits-all approach.

Processes requiring "metres of wall space" to show in their entirety are a reality. But are these "full versions" required to engage process stakeholders and end users? My first question would be, "Engage them to do what?"

How often are these process participants required to view or even know the entire detailed process? I would argue many of the discussions require only a condensed or abbreviated view to meet the objective of the engagement. This multiple version approach should eliminate the problem of being a chess master to understand the process.

Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceevangelist/

[Adam Garland]

Process is moving on. Swimlanes met the requirements of business especially as most buisnesses where operating in units or silos. Mapping a handful of process in a unit showing the client representive their touchpoints for that particular stream, job done, swimlanes.

However the business landscape has been changing, it's more complex, more competitive, doing more with less consequently process requirements have changed. They want a more informed and better educated workforce. Business wants to see what the business looks like joined up, what it costs, what all the dependancies are, what the volumes are etc

Business success depends on what the company does and how it does it and that starts by mapping what the business looks like on an activity by activity basis and then delivering the right information, to the right people and rightaway.

As process professionals we need to keep pace with changes in technology and competitive drivers.

Businesses want multi skilled workforces, the want to effectively support a growing mobile workforce, support the lone worker, they want to meet growing compliance and regulatroy drivers, reduce costs and much more and it is our job to meet those requirements.

How impressed would our clients be if we could deliver process to workers via a mobile device in context to their role in the organistions?

For me it is not about bashing swimlanes methodolgy, it is more a question of the relevance of swimlanes in todays business landscape.

We should be helping out clients gain and maintain competitive edge and to do this we need to embrace technology based solutions.