Interestingly, when you meet a certified project manager, he/she almost immediately starts talking about how important is to manage projects and how it should be done. Similarly, a process management expert looks at the world through processes.

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 inpidual – only the teamwork – and will not consider the essence of the work, only the coordination aspects of the teamwork.

Definitions:

• Project is a sequence of activities following a defined plan and aimed at delivering unique result, product or service. Example: road construction.

Note: “defined” here and below means “defined before the beginning of work”. By contrast, “some” means “defined in the course of work”.

• Process is a defined and repeating sequence of activities started by a defined event and producing a defined result, product, or service. Example: processing of customer order.

Note: terms “process” and “business process”, “activity” and “work” are used as synonymous here.

• Case is some sequence of activities aimed at defined goal. Examples: patient’s treatment at the hospital, legal case.
• Docflow (document-oriented workflow) is a defined sequence of activities related to a particular document. Examples: contract approval, incoming mail processing.
• Issue is a defined event that needs to be addressed by some sequence of activities aimed at defined result. Example: help desk ticket.

2. 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:

	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.

3. 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”:

Fig.1. Structured vs. Repeatable

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 –

• Verification. While any information can be entered into a text document, an input to a screen field bound to a database table column can be thoroughly checked and verified. E.g. the phone number entered matches the telephone number mask, the date for the returning flight is later than the date of the originating flight etc.
• Ability to integrate with enterprise systems. E.g. if the expense report is submitted as a text file, then its processing will be manual and error-prone. The same report implemented by a business process management software will be well-structured and passing the report to accounting system would be a matter of copying from one database to another.

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:

Fig.2. Repeatable vs. Predictable

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:

Fig.3. Collaboration Matrix

4. 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:

• The IT help desk operations are often treated as a process work: first and second lines of support are introduced, SLA and escalations established etc. Yet it’s only about control; as for the physical work that should be done to resolve the issue, it can be virtually anything and therefore should be presented as a case. Here a process executes are case.
• Classical project management follows similar pattern: project initiation, project closure, project rescheduling may be presented as well-defined process that execute or communicate with the project.
• A patient in the hospital emergency room is an opposite example. It’s hardly possible to present the medical treatment as a process because there are too many hardly predictable variants. Hence the top level is a case. But on the lower levels there are treatments and tests that very well can be defined as processes. Here we see a case executing a series of processes.
• An organization may treat a collaborative work which is essentially a process (highly predictable and repeatable) as a project or case work because modeling a process requires skills, efforts and time. For example, a pharmaceutical company treated the new drug development as a project for years and then, when the “recipe” of this work became clear, they implemented it as process.

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.

(To be completed.)

• Originally published at BPM.com