I originally wrote this over two years ago but never got around to posting it. It's mildly depressing that it's still pretty pertinent today:

In an ideal world, business processes would be thoughtfully and iteratively reviewed by any and all stakeholders. Modeled processes should reflect the operational realities of an organisation but also capture any process aspirations and goals.

The challenge is to not "finish" capturing the business process too soon (if at all) but to retain a focus on it at all times. The business process should be a primary factor in any technical (e.g. architecture, implementation) decisions that are made.

One of the most common mistakes that I see are business process diagrams that can’t readily be understood and leveraged by business users.

I would argue (based on experience) that an excellent Process Architect and mediocre Developers will produce something with a higher ROI (if that's the ultimate measure of BPM success) than a mediocre Process Architect and excellent Developers.

The business process (including it’s tangible representation on a BPM platform) should be wholly owned by the process owner. Process owners mustn’t be reluctant participants in BPM activities and their involvement and interest should not dwindle over time.

The challenge is to implement a cultural change whereby the business processes *belong* to a process owner and where the process owners lead any discussions about changes to the business process. It is critical that appropriate and empowered process owners are engaged.

You are not making the most of BPM when the process owner does not drive and is not directly engaged in changes (however small) to the business process.

Equally, you are not a "process owner" if it's just an arbitrary label that's hesitantly or reluctantly assigned to an individual at the start of a BPM project.

I would argue that an engaged process owner with a non-optimal process will enjoy an easier life (especially as time passes) than a disinterested process owner with a process that has been "optimised" by a third-party (e.g. an Implementation Team).

BPM Platforms are inherently collaborative and intentionally agile. It takes literally seconds to start mapping processes and, in most cases, only minutes to build simple user interfaces. You should be making regular and non-trivial changes to your processes (especially during the early stages).

The challenge is to help the stakeholders understand that their role has changed. They are now active and ongoing participants in defining and building the operational tools of the business. Their role is no longer just to review but to contribute.

If early process mapping or user interface prototyping sessions yield few changes then either these sessions have been over-prepared (and the wrong people have been making decisions) or the stakeholders haven’t been properly engaged and they think that they've just seen a demo, rather than a prototype (a subtle but important distinction).

Placing too much pride in a prototype is a common mistake for Developers.

I would argue that quickly produced but discarded (or changed beyond all recognition) process diagrams and user interfaces can be more valuable than carefully constructed prototypes that evolve into the final solution.