IBM is preparing to release RPM v 7.1 next month:

“IBM Rational Portfolio Manager v.7.1 is an enterprise project management solution that can be used by everyone in an organization - CIO, project managers, business analysts, developers - to balance IT investments and identify service priorities. A new Web 2.0 interface allows team members to manage their work, submit time and expense reports, and a tight integration between Rational Portfolio Manager and IBM’s Rational portfolio helps ensure software projects are conceived, built, tested, deployed and provisioned on schedule. An analytical component to Rational Portfolio Manager enables automated decision and approval cycles for software development teams while finding trends and overlaps in projects. Project teams can increase efficiency with new templates and best practices that generate compliance reports and ease project start up.”

Source: http://www.ebizq.net/news/8035.html

From what I read, IBM is trying to make this RPM dot release appear as a process enactment solution for developers while keeping the focus on solving a compliancy need. In my view this is a wrong approach to take and does not make sense at all. In fact this is completely opposite to the second generation process enactment tooling approach Osellus is taking. Why do I say this?

As I have mentioned in my earlier blog posts, a command and control approach to software process has proven to be a failure. Our approach is to reduce the overhead associated to process enactment. Process should be instrumented into the developer tools (IDE) delivered in a non-intrusive friction-free manner. Our second generation tooling on process enactment is bringing us closer to the ultimate objective of making process invisible during a project. Instead, from the information I have seen till now, IBM has chosen to take a mature portfolio management tool and as part of a dot release tried to inject process enactment into it. Developers who had no reason to use this tool will now be asked to update it during project enactment. I don’t see this working. In fact just yesterday I was in a meeting with one of the largest banks in Canada where they mentioned that their current investment in a portfolio management tool is underutilized. Project managers and other management folks do not want to go through the hassle of managing yet another tool simply to follow a process and get compliancy reports.

Osellus will continue to work with its partners to ensure that we take the practioners tools (such as IDE) and make them process-aware rather than imposing another tool simply to follow a process and compliancy reporting.

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.