CMW Lab Blog

Managing Projects, Processes and Cases

In reality, however, most organizations have to deal with processes, projects and cases which are somewhere between the two. Therefore they need a balanced, unbiased view of projects, processes and cases that in essence are just different kinds of collaborative work. Projects, projects and cases have more in common than it may seem at the first glance: whatever approach is taken, there always is an initial state, resources and goals to be reached.

Yet it’s hard to be an expert in different knowledge areas. One can learn the theory but it takes years to become an experienced practitioner. That’s why it’s relatively easy for an organization to find a project or process experts but there is risk that they will overestimate the importance of one approach at the expense of the other.

As for the business people, they often confuse these approaches. It’s not unusual for a conversation to start from projects and suddenly switch to processes and vice versa.

To make things more complicated, project-oriented people talk a lot about processes – e.g. the Project Management Body of Knowledge (PMBOK) is more about processes governing projects planning, execution and control than about projects themselves. Yet the way PMBOK defines a process differs considerably from process definition given in the Business Process Management Body of Knowledge (BPM CBOK).

At the end of the day, projects, processes and cases are just different methods to solve the issues that every mid to large organization faces – the “silo mindset” and the gap between the business units’ targets and the goals of the organization. The root problem of these issues is the division of labor.

Business needs to resolve these issues by whatever means. It may be project management or process management but there is also adaptive/dynamic case management, document-oriented workflow, issue tracking… Easy to get confused, right?

This article aims at the following:
  1. To help choosing the best approach (or combination of approaches) to collaborative work depending on organization profile.
  2. To provide a basic understanding of available software tools supporting these approaches.
  3. To analyze the differences and similarities between these approaches and define the vision of the integrated software product implementing them all.
The first two discussions are not new but hopefully will be useful for practitioners. The third part is based on the researches currently performed at Comindware and therefore may be considered as a request to comments.
  1. The Forms of Collaborative Work
We will not consider the work performed by an individual – only the teamwork – and will not consider the essence of the work, only the coordination aspects of the teamwork.

Definitions: Note: “defined” here and below means “defined before the beginning of work”. By contrast, “some” means “defined in the course of work”. Note: terms “process” and “business process”, “activity” and “work” are used as synonymous here.
  1. Classifying Attributes of Collaborative Work
The boundaries between the different forms of collaborative work are often blurred. For example, the new product development may be considered as a project, process, case or even docflow depending on the industry, type of product and organization culture.

Nevertheless, they may be differentiated by the following aspects:
  1. Repeatable. Is it possible to typify the sequence of activities, i.e. to give multiple instances a common name? The answer is positive for processes, cases and docflows. Projects and issues are not repeatable, speaking generally. (Although repeating projects and issues may occur, indeed.)
  2. Predictable. Is it possible to define a sequence of activities in advance or is it determined “on the go”? Cases, docflows and issues are not predictable, speaking generally. A case is “rolled out” – next activities are resulted from activities already performed. A document in a typical docflow system may be reassigned at any step. In contrast, a process is fully predictable: although there may be gateways, all options and conditions are known in advance. A project is predictable, too – the project plan comprises a complete list of tasks. There is some degree of unpredictability because the project plan may be amended as the project progresses, yet it’s common to consider projects as predictable.
  3. Structured. Is it possible to describe the work input and output by structured data? Processes and cases deal with structured data: numbers, amounts, dates, references, etc. Projects, documents, issues deal with unstructured information: text descriptions, attached spreadsheets and other content.
Let us summarize the above:
Table 1. Attributes of collaborative work
  Repeatable Predictable Structured
Process
Project
Case
Document
Issue
The table above shows that processes and issues are two poles: repeatable, predictable and structured processes and unique, unpredictable and unstructured issues. Other forms are somewhere in between.

  1. Framing Collaborative Work
At first glance, it may seem that the check marks in Table 1 are placed randomly. To make a system of it, we’ll use the classifying attributes as dimensional axis. Let’s start with “repeated” and “structured”:

Framing Collaborative Work

The Fig.1 shows the correlation of structured and repeatable work. When dealing with a recurring, typified work (even unpredictable, as cases), it may be expected that the work is performed on the same type of business objects. Therefore the information can be presented as structured data rather than documents.

It’s worth to note here that while processes and cases are able to work with structured data, they can also process unstructured content.

Working with structured data has clear advantages – Document-oriented workflows in Fig. 1 look like an exception: repeatable and yet unstructured. The docflow approach is often criticized for doing not more than simply replacing carbon-based documents by electronic ones. More value could be produced if structure was applied to the information. Not surprisingly, the complexity of integration with enterprise systems is a well-known weakness of docflow systems.

With regards to projects and issues, when dealing with truly unique work, the information will be unstructured. This is inevitable and hence justified. But if we treat not-unique, recurring work as project or issue instead of case or process then the benefits of processing structured data are lost.

Now let’s look at repeatable/predictable axis:



All cells are filled, only documents and cases overlap. In fact, case management and docflow software are close relatives; with the advent of ACM some ECM vendors re-labelled their offerings as ACM.

It may be expected that in the future ACM software will fully replace docflow because it’s able to process both unstructured content and structured data. On the other side, today docflow software is generally more mature. (It should be emphasized that author’s criticism is aimed solely at the document-oriented workflow as a way to organize collaboration and doesn’t span to the content storage and delivery provided by Enterprise Content Management systems.)

Fig. 3 depicts the full matrix with illogical combination “repeatable+unstructured” (Documents) excluded:

  1. Pure Forms and Mixed Work
In reality purely project or process work are rare, more common is a mix of work. Projects, processes, cases 1) execute (“call”) each other and 2) transform to each other over time. Some examples: Unfortunately most existing tools support just one form of collaborative work and therefore do not support interoperability and transformation. This makes a room for the new generation of integrating tools that support all kinds of collaborative work and any combinations. We will present the vision of such tool in the final part.
Exit mobile version