Project Plans and Process Definitions

I love my job... I really do.  Every month or so I start a new assignment to help a "new to BPM" client get a quick return on their investment and to help them become self-sufficient so they won't need me to help them "next time" - In essence my job is to  "work myself out of a job".

By working with such a variety of "new to BPM" clients I am constantly challenged by new "process problems" to solve.  Many of my client's problems are hauntingly familiar (so I already "kind of know" the answer), but I still often find that the types of "process problems" that  I already know how to solve aren't the type of "process problem" that a new client wants me to solve.

Just a few days ago I was talking to some folks and realized that what they thought BPM could do for their business wasn't at all what I usually think that BPM can do for a business.  They aren't crazy, far from it, they just have a different type of problem then that which I am used to solving.

The process that I usually help clients manage goes something like this:

"Every week we get a new X, and we have to do a lot of steps to produce a Y."

The problems that I usually deal with go something like this:

"We never know who is doing what, and sometimes things get dropped in the cracks.  We also feel that the process could be made more efficient, but we're not sure how."

Of course X and Y are never the same, and the steps for getting from X to Y are never the same, but it's always a process that is clearly defined and the client does it over, and over, and over again.  You might call these business "operational" processes.

BPM suites (as I usually apply them) are perfectly suited for this type of operational process, because I can create a process definition that my Automated Process Manager can "run" over and over again, and I can instrument the process to tell me (over time) how smoothly the process is (or isn't) running.  Once I have metrics from the completed processes, I can make suggestions on how to improve it.

My new client has something else in mind... It "seems" very closely related, but the devil's in the details and it's really something sort of familiar yet different.

My client does in fact have a process that they need to define... but they will only ever run this process once.  They will certainly run slight variants of this process many times in the future... but every time the process definition will (most likely) be edited.

In fact, what my new clients want is to be able to define a process that will manage a project plan, and have an Automated Project Manager to govern that plan.

It's actually pretty easy to look at a project plan and transform it into a process definition (the converse is more problematic).  Look at a typical project plan Gantt Chart and you can pull out the activities that need to be performed, who does them, and the general flow from activity to activity (image below is from Wikipedia).

With my favorite BPM suite, I can easily review the project plan's Gantt Chart and define a process (using BPMN) that corresponds to their project plan (diagram from WebSphere Lombardi Edition).

Once I have the process definition, my Automated Process Manager can in fact do everything, and I mean everything, that my client wants their Automated Project Manager to do.
I am only highlighting distinctions to point out how a one time Project differs from a many instance Process.

There is a nagging disconnect (from the project manager's perspective) between what you can represent on a Gantt Chart and what you can represent on a BPMN diagram.  Project managers are very fond of Gantt Charts because they are a very good representation of a project's timeline and dependencies.  BPMN diagrams do have a general sense of time (left to right or top to bottom), but they don't represent durations at all.  All activities are the same size.  There's no visual indication of the (predicted) time that it will take to complete a task... so information that is of primary importance from the perspective of the project manager is missing.

The more important distinction between the "operational" processes that I usually deal with and a "project" process has to do with adapting the plan as the process progresses...

With an operational process, you may over time change the process definition to make the process more efficient.  All new "instances" of the process will use the new and improved definition, and the instances that are "in flight" may or may not be migrated to the new and improved definition.

With a "project" process there's a real likelihood that the plan itself - the process definition - will be changed "on the fly" to respond to current events.  When activities don't get completed "on time", a good project manager will adapt the plan to try to make up for lost time.  These changes may be minor, or they may be extensive, but they are always immediately applied to a single running project.  The project manager is tweaking a specific running project to make it run better now, not changing the steps so that some future project may run smoother.

It's not a big leap of intuition to envision how the "project needs tweaking" scenario could be handled by a BPM suite... but to "make this easy" I think you'd want to tailor a Human Interface for the "process designer" tool to make it very obvious, and very easy, for the project manager to define and apply changes for a single running process/project.

The morals of the story (if there are any) are that BPMN isn't the be all and end all for all your process definition needs and that a set of tools that are very good for dealing with "operational processes" may not be the set of tools that you need for "project processes".  Sometimes a BPMN oriented tool is what you need, sometimes you need a Gantt Chart oriented tool, and sometimes you just need a Checklist.

Update: An IBM colleague of mine pointed out the similarity between what I have described and Advanced Case Management, and pointed me to a very interesting David Yockelson blog posting that contrasts the goals of BPM versus Advanced Case Management.  Quoting David:

"Business process management focuses on optimization of a process with a key goal to increase the volume of throughput or work completed for an individual process. 

Case management has a different “design goal” and focuses on optimization of outcomes for individual cases by providing an integrated set of information and services for the case worker. "