On process instantiation during flexible process enactment

June 5th, 2007 by Kamal Ahluwalia

In my last post, I talked about the concepts of flexible process enactment as illustrated by the scientific research findings by John Noll et al. in this domain. Our first generation tooling for process enactment has already implemented these concepts that have been commercially offered for more than three years now. We have received numerous lessons learnt and other feedback from process mature organizations that have tried to implement this tooling in their development teams. Based on that we have come to a conclusion that flexible process enactment (as explained by John Noll et al.), although an essential first step needs to be further augmented for a successful process enactment in real-life projects.

There are two key aspects in our approach that incorporates the idea of a flexible instantiation of a process model. First, the model being followed is kept separate from the project work item instances which represent the instances of the process. That is, even though practioners have a view into the process model they are following, the project work items they are executing are handled independently by the tool. Second, practioners have a view into the model and the flexibility to create as many instances of whole/part of the process model as the project progresses.

Let me take an example to illustrate this approach. The left hand side of Figure 1 shows a work breakdown structure that has been created in a process modeling tool. Our first generation enactment tooling would have created a single instantiation of this process model resulting in a 1:1 mapping of process model elements and project work items. This is similar to a straightforward object-oriented modeling approach of instantiating a class. Unfortunately this also results in an unrealistic single monolithic instantiation of the complete process model that is unsuitable in a dynamic project environment consisting of knowledge workers as practioners.

Process Instantiation
Figure 1

In our new approach, the process model would serve as a reference to create project work items on the fly. This would need to address both – known unknowns and unknown unknowns. For example to handle “known unknowns” such as instantiating iterations, a practioner would simply instantiate those process elements that are needed at a given point of time in the project. In our example only the “Determine Requirements” work definition has been instantiated as part of “Iteration 0” in the first series or thread. Later on, practioners have opened another series that has instantiated “Iteration 0” complexly. Next, they have chosen to instantiate “Iteration 1..n” as part of two series. At any time, practioners can double click the process work breakdown element on the left hand side to study published process guidance for that element. Another scenario could have been where a change control workflow is triggered each time a change request is entered into the system. Again this is a known unknown since the model cannot predict how many times the change request is raised but it can define a reference workflow that may be triggered in complete or in part depending on the nature of every change request raised. The series or threads would facilitate concurrency in the project environment as these threads could be executed simultaneously.

Process Instantiation - new process elements
Figure 2

The “unknown unknowns” are handled by allowing practioners to create additional project work items that do not map to any process element (since that knowledge was not known at time of modeling). For example as shown in Figure 2, I can create a related activity that although not defined by the process model is needed as part of the project and follows the activity “demonstrate the architecture”. The enactment system would enable us to track and log how these instances are created. One use of this information would be to act as lessons learned to improve the process models for other projects that are being implemented in a similar environment as this project.

One Response to “On process instantiation during flexible process enactment”

  1. The Osellus Blogs » Blog Archive » Examining “tailoring” of processes Says:

    [...] as and when a change work item is added. I would call this instantiation of process definition as flexible process enactment. Keep in mind that the project manager can also add additional work items that are not defined in [...]

Leave a Reply