Flexible, on-demand process instantiation

May 2nd, 2007 by Kamal Ahluwalia

Process mature organizations define and tailor processes at various organizational unit or domain levels. IRIS Process Author (IPA) provides the tooling to manage process assets structured within the enterprise process architecture. Apart from subject matter experts and process engineers, many project managers tailor processes based on project execution environment - for a specific engagement or a specific project. A process can be tailored by a process engineer or a project manager to better suit a particular project or category of projects. In addition to process tailoring there is a need for a flexible, on-demand instantiation of tailored process anytime during enactment. This is because not all aspects of the process usage are known ahead of time. For example, number of different iterations only becomes apparent as the project progresses. Also this gives the flexibility of re-instantiating any part of the process as needed. For example, the workflow for change request can be instantiated any number of times, anytime during the project.

Process tailoring only takes place before start of the project. Flexible, on-demand instantiation of process only happens after the start of project.

Process element instantiation is the creation of executable project work items that drive process enactment in real projects. In first generation enactment systems such as IRIS Process Live v1.0, there was a 1:1 mapping between process definition elements and process enactment elements. Based on experiences and lessons learned this has proven to be a rigid and “artificial” way of looking at process enactment. Our second generation enactment tooling addresses this project team’s need to create project work items in an “as-many” and “any-where” manner.

Project work items may be created in response to either/both of the following two conditions. In the first case, the project team simply creates as many instances of project work items as needed by the progress they have made at any time during the project. In this case the process definition elements are instantiated to create these project work items. For example teams decide on the number of iterations needed in the midst of a live project, IRIS Process Live would let them decide on the composition and quantity of iterations in a flexible adhoc manner. In this case even though teams have full flexibility in creating these instances, they are still following the prescribed process since they create instances of process elements from the pre-defined process definition

Although it is expected that the teams follow the defined process to create these instances, it is not uncommon that they may create additional process enactment elements, for example, adding a “review” activity after use cases were refined that was missing in the process definition. In this second case, the project team has the ability to add missing process definition elements (and treating them as process enactment elements) without giving up on the original process definition completely.

In both cases, the process element instantiation is tracked to prepare reports on the type and nature of instantiation during a project lifecycle a well as overall process compliance. To facilitate process improvement, lessons learned by tracking the number and nature of project work item instances creation is also studied by process engineers.

I will continue to share similar advancement in the state of art around process enactment and how our tooling continues to evolve using the feedback from an expanding community of process mature enterprise organizations.

Last 5 posts by Kamal Ahluwalia

One Response to “Flexible, on-demand process instantiation”

  1. The Osellus Blogs » Blog Archive » Support for SPEM 2.0 Says:

    […] for the modeled software processes enabling successful delivery of software projects. As I have noted in the past, it is not possible to come up with a sustainable process definition without enacting […]

Leave a Reply