Which is the best path for building out new process models? Following the path of least resistance is your best bet in most circumstances. There are a few grey areas in this answer which I’ll cover later – the key point is that guidance is focused on rapid turnaround on process models. Advantage being that the sooner your business is hands-on new process models the better your odds on alignment to key values and business advantage.
How do we stay on path?
Process Modeling versus Software Development
Avoid Blindly Following Software Development Life-Cycle (SDLC) Best Practices
Use only those practices which deliver on increased efficiencies. Process development is not software development. Process development, though thoroughly taking full advantage of the various components and services flowing out of SDLC, does NOT do SDLC. Process is exempt – reason is that once a process requires, for example, full QA support, it’s slipped into application “mode”. Meaning that your team has fallen into the practice of building-out point solutions as apposed to business process models. A process is not an application.
Measure Process Construction On Its Own Terms
Best example is “on time delivery” and “completeness”. If the BPM team falls behind on delivery, the WORST follow-up is corrective action on old-school software project management (PM) reporting. Seems obvious, from above, not following PM reporting methods on a project not… following SDLC. This is a common experience though – pushing the BPM team into wrong methods and practice via non-sequitur measurements and reporting.
The solution is to track/measure towards (reporting on) alignment to business value and vision. This requires the process model be “played back” (demonstrated) before a live business audience (this is not your QA team). The question is asked and answered, “is this the model you asked for and does it help our business?” Simple measurement on value – we only care about value. And, more importantly, the path towards good process construction demands the capability to discover, deviate, and remain on target – no exceptions to this rule! Success is business value.
Cut Unnecessary Complexity
A tight balancing act in that system architecture and user interface is important… to whom? This is hindsight. I’ve fallen into the trap more often than I care to admit. Situation is that key stakeholders often lack understanding on the problem-at-hand. In lacking clarity the “light” only shines on familiar items and patterns, though with reasonable history, lack application on BPM projects.
Examples are the fancy, if not beautiful user interface (UI), and wonderfully elegant system architecture. This is like speaking Latin. As the tribe (organization) hears what’s understood. And this understanding is unfortunately bound to irrelevant complexity.
There is no solution here – no courseware training, presentations, discussion…
I recommend the BPM team work in isolation and report only to key, knowledgeable business stakeholders. And, if discussion drifts, quickly rein the team – remind them of alignment, vision, and business value. You may need to drop and replace participants – better shift distractions out early rather than bog the project down on irrelevant complexities.
