How Do I Know This Is The Right Process?

If you have been involved in very many BPM projects you have inevitably seen some which progressed through the entire development lifecycle with no major warning signs only to fail when put into production.  They fail because the delivered system does not solve the problem which the business needs solved.  They typically go through a complete lifecycle with verification at each stage.  The Business writes its requirements.  Business Analysts turn these into a functional requirements document, approved by the business.  The development team creates then implements designs and finally QA tests the system and verifies that it satisfies the documented requirements.  Yet in spite of all of this, the resulting system is not usable for its intended purpose. 

How does this happen?  There are many causes and several potential solutions.  This article will describe one simple approach which we have found can significantly improve outcomes.  One of the primary sources of problems is the many hand-offs between different teams with different skills and communication techniques.  Each of these involves a translation of content from one team and format to another.  At each of these interfaces, it should not be assumed that either team completely understands or communicates perfectly with the other.  In fact, it is prudent to assume significant information loss at each of these hand-offs.  To achieve success, it is necessary to take extra steps to identify and correct these errors immediately.  We will describe an approach to use of widely adopted requirements and design artifacts which can help bridge these gaps and insure improved communications between teams.

Use Cases are a key part of the requirements documentation for many projects.  For BPM projects, they are uniquely well suited.  Use Cases provide a narrative description of the behavior of a system to achieve a particular outcome in response to a request from a stakeholder.  They identifier all of the actors and the sequence of steps required to reach the goal.  The also define variants and exceptions.  In Agile methodologies, simpler Stories serve the equivalent purpose.  One reason for their popularity is that they are understandable by typical business users, yet well written ones are precise enough to provide direction to developers.  As valuable as this is, for traditional code based development there is still a formidable translation process from the narrative of a use case to a set of modules to be designed and developed.  This is the translation problem described above.  However, with a BPM project, use cases can be structured to have a very direct correspondence to the process model.  The key correspondences are listed in the table below.  The Use Case terminology is from Cockburn (Adolph, Steve, Alistair Cockburn, and Paul Bramble. Patterns for effective use cases. Addison-Wesley Longman Publishing Co., Inc., 2002.) .  BPMN 2.0 is used for Process definition.

For a BPM project, well-structured Use Cases and an appropriate supporting methodology can largely eliminate the highest risk handoff in typical projects.  The rest of this article will discuss how to effectively achieve the benefits of this. 

One key change is to start process modeling much earlier than in typical methodologies.  Instead of beginning after completion of Use Cases, it must proceed is parallel.  These will not be working executable process models, but rather what the BPMN standard describes as Descriptive models.  These descriptive models are more of a requirements artifact than a design artifact.  The Process Model and Use Case must tell exactly the same story, but each communicates different aspects effectively.  The validity rules of BPMN identify flaws in Use Case logic early, and the Use Case steps and extensions identify the sequence flows and branching in the process.  The Use Case authors are probably not experts in BPMN, but by following proper conventions and standards, they can understand the BPMN models and be confident that they match the Use case intent completely.  Combined, they are much more likely to produce the right solution than separate sequential development. 

One problem we have often observed with any form of requirements documentation, but especially Use Cases is that the authors are typically domain subject matter experts and are given little or no training in writing use cases.  This approach requires more formal structure than some other methodologies and training is essential, for both authors and reviewers.  Standards for both Use Case and Descriptive Process Models must be documented and training provided.  This must be supported by a peer review process.  In addition to the usual review of each artifact separately, it is essential to add an alignment review which verifies that the Use Case and Process Model define exactly the same system.  Doing this at the earliest stage significantly reduces risk, as the Process Model is evolved into the final solution.

Following the above approach gets us across the first hand-off, requirements to high level process design with high confidence.  To achieve success, it is necessary to continue the discipline through development of the executable processes from the design models.  Fortunately, this is easier as the executable process is defined in the same notation and tools as the Descriptive model.  Refinement of the Descriptive process model into executable consists primarily of defining the implementation details of each Activity, Gateway and Event in the descriptive model.  It should never Add, Remove or reorder components without going through a Configuration Management process to validate that the business intent is preserved.  This needn’t be a burdensome process, but it must be followed.  Just as we recommended an  alignment review between the Use Cases and the Descriptive BPDs, a similar alignment review is necessary between the Descriptive and Executable BPDs.

In this article, we have briefly described a modeling approach which we have found to significantly improve the outcome of BPM development projects by insuring at each transition in the project life-cycle the intent of the previous stage is correctly carried into subsequent stages.  It is a lightweight process and the added structure can actually reduce the time spent reviewing and approving requirements and design artifacts, since they are defined in compliance with well documented and understood standards.  There is a small investment required to develop the standards and train the participants, but in any enterprise Process implementation, or even a large project, it will pay back quickly in better results.