Which is the best path for building out new process models? Following the path of least resistance is your best bet in most circumstances for optimized Process Modeling. 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 with the new process models the better your odds on alignment to key values and business advantage.
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.
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.
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.
Partner with Princeton Blue for all Process Modeling needs your company. Visit our website at www.princetonblue.com and request to have us contact you, or you may reach out to us directly at (908)369-0961. Feel free to engage with us on Facebook, LinkedIn, Twitter & Google+ to get updates about BPM and related technologies.