The Next Big Thing
Posts about next generation technologies and their effect on business.

Case Management for Project Management

The OMG (Object Management Group) is in the early stages of development of a Case Management Process Modeling (CMPM) specification.  The topic of this post is to consider the relevance of case management to project management.  Case management involves business processes that cannot be defined ahead of time, but are defined and adapted based on evolution of the particular undertaking.

I first talked about case management in Case Management: The Missing Link in BPM.  More recently I discussed Case Management for Managers in which I explored how automation might assist managers in managing and coordinating activities to achieve business objectives.

For case management, a process is not designed for repeated use.  Instead a process is planned interactively for the particular case as it evolves.  An initial plan for a case may specify everything that is needed to reach an objective assuming everything goes as expected, or it may be as little as the things currently being done and some consequential action such as the next activities or a session to plan what to do next.  In either case, the actual plan is expected to be adapted in response to actual needs and events.  This is similar to the actual process of many project management efforts except that project management usually relies on a pre-defined project plan with corrective action for deviations.

Modeling for case management includes the specification of various patterns-what we have been calling process fragments in discussions of the CMPM specifications.  These fragments have dependencies on inputs and may produce outputs that subsequent activities depend upon.  A case management effort will involve the specification of these fragments along with specific activities and events to evolve what needs to be done and when.  The model for a type of case may define the high-level phases that are typical of such cases.  The pre-defined fragments will incorporate insights and best practices at a finer level of granularity so that they can be leveraged for many undertakings.  Over time these fragments can be refined and extended to improve the efficiency, timeliness and quality of case management.

I'll use the Eclipse Process Framework (EPF) and the Open Unified Process (OpenUP) as a basis for considering the impact of case management on project management.  EPF is a set of open source tools developed by the Eclipse Foundation for managing development processes, and OpenUP is a methodology and associated process patterns for software engineering that is supported by EPF.  EPF implements SPEM (Software and Systems Process Engineering Metamodel), a development process modeling specification from the OMG.

In case management, the primary process structure of OpenUP can be used as case phases supported by the OpenUP patterns as process fragments the same as with EPF.  The difference is that the process can be continuously updated with the addition or modification of process fragments at runtime, as the project progresses and evolves and as more becomes known.  Case management will also track project activities including the addition or repetition of activities that actually occur in a project.  Tracking will provide insight for further improvement of the planning fragments for future projects.

EPF would allow the development process to be adapted, but adaptation is expected to be an off-line activity.  Case management can exploit the availability of the Internet and mobile devices to go beyond traditional project management with monitoring and responding to events and engaging participants more directly.  Management of the activities and adaptation of the process involves on-going interaction with participants.  The activities may also be more fine-grained to track progress and changes more closely.  Activities in the case management process may engage outside services and track their completion.  In addition, the case file will maintain access to information artifacts that define the state of the project and flag events that drive subsequent tasks, planning and decision-making.

I believe these added capabilities will foster project management that is more responsive, more closely tracks project progress, improves collaboration and communications, reduces delays through prompting based on events, and provides history to reduce delays and improve efficiency and quality of results.

Why Not Use UML to Model Everything?

UML (Unified Modeling Language) provides a powerful capability for modeling software systems.  The various modeling elements and views, along with an extensibility mechanism, can be applied for modeling other systems.  So why not use UML to model any system? Users would only need to buy one modeling tool, and the market for UML tools would be expanded.

Standard extensions of UML for specialized applications are called "UML profiles."  OMG (Object Management Group) has defined a number of UML profiles.  For example, there is a UML profile for modeling physical systems called SysML, a UML profile for modeling software development processes called SPEM (Software Process Engineering Metamodel), a UML profile that extends UML for specification and integration of services called SoaML, and a UML profile for DODAF (Department of Defense Architecture Framework) and MODAF (Ministry of Defense Architecture Framework) called UPDM.  

A UML profile can be imported into a standard UML tool to create a specialized modeling environment.  UML tools support views (graphical displays) that are appropriate to a variety of modeling applications.  The extensibility mechanisms of UML enable existing UML elements to be adapted as new types of model elements and attributes.  While a UML tool may be able to support useful diagrams, in the long-term users will suffer from a limited modeling capability.

There are three basic limitations: (1) the UML modeling elements were designed to represent the concepts of a software system design, (2) the graphical representations are not designed for most effective human understanding of the models, and (3) a UML tool does not provide the computational support for structural consistency and functional analysis.

One of the problems encountered in the design of a UML profile is the design baggage that restricts the use of UML elements.  Design of a UML profile (a specialized language) requires deep knowledge of the design of UML in order to work around these restrictions.  The result is a compromise that provides a less than ideal representation of the problem domain.  The semantics of the profile are in the profile documentation and minds of the users.  The tool only reflects the semantics of software design. 

UML does not provide good quality graphical representations for modeling software, and this does not get any better for UML profiles.  An excellent paper by Daniel L. Moody, "The Physics of Notation: Towards a Scientific Basis for Constructing Visual Notations in Software Engineering," refers to UML for examples of the ineffective use of graphical notation.  Users should be able to quickly associate the graphical representation of a concept with its semantics.  In many cases UML makes very limited use of visual variables, thus obscuring semantic distinctions, and in many cases combinations of these variables create complexity.  For example, combinations of three visual variables (shape, brightness and texture) are used to distinguish 20 different types of relationships in a UML class diagram.  In a UML profile, a text label is often used to identify a concept.  Text requires less efficient, serial human interpretation (reading) while distinctions using graphical shapes are interpreted through parallel, image recognition.  As a result, good graphics make it easier and faster for users to grasp the meaning of a diagram.

Perhaps the most important limitation of a UML profile is that the modeling tool does not provide computational support for structural consistency and functional analysis of the model.  Enforcement of structural consistency of the model using a UML profile is based on consistency of UML software design models.

A good modeling tool will help the user develop a consistent and complete model.  Furthermore, a robust tool will assist in the analysis and improvement of the model.  For example, BPMN 2.0 (not a UML profile) defines a modeling language for specification of business processes. This includes modeling of executable processes and choreographies-interactions between participants supported by their executable internal processes.  A good BPMN tool will support analysis of compliance of an internal process with the requirements of interactions specified by a choreography.  A robust tool might also provide simulation capabilities to analyze the flow of business transactions. 

These functional capabilities are not defined by the standard, but will be developed as differentiators by the modeling tool vendors.  Addition of such functional capabilities for a UML profile would require implementation of functionality that may not be consistent with the use of the tool for generic UML.  The resulting profile language would still not be the best representation and visualization of the problem domain. 

The development of UML profiles may provide a quick and cheap solution to modeling new problem domains, but, in the long term, it provides less effective domain representation and visualizations, and it undermines the market incentives for development of functionality that improves modeling efficiency and the quality of results.

Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.