Project Management versus Business Process Management
Blog: KWKeirstead's Blog
Corporations can get into a lot of trouble by picking the wrong technology.
Rule #1 is “First the problem, then the solution”.
Suppose you want to improve outcomes and you state your need as “workflow and workload management” software.
Vendors offering project management (CPM) software will immediately detail how their software addresses workflows and workload management, backing this up with a list of satisfied customers.
Vendors of Business Process Management (BPM) software will immediately deliver the exact same pitch, with satisfied customers.
How can two very different technologies satisfy the same needs?
The answer is they don’t and won’t.
The reason is prospective buyers typically fail to state whether, for their scenario, workflow logic and timing can be predicted (as in the construction business) or whether workflow logic and timing cannot be predicted (as in knowledge work).
CPM delivers its promise i.e. to calculate the “critical path” which involves predicting project completion dates and predicting costs at completion. This implies advance knowledge of workflow logic and advance knowledge of task durations and costs.
Some flavors of BPM deliver the BPM promise (i.e. providing orchestration to knowledge workers via background BPM) via facilities that allow periodic assessment of progress toward stated goals/objectives. In most work, workflow logic will vary over part of the lifecycle of the initiative but otherwise follow workflow logic. As for costs, well, these will not be predictable, as they are tied to how long it takes to complete tasks that end up needing to be performed.
The CPM methodology has been around since the mid-1950’s with antecedents invented before 1900. If you see terminology like “early-start, early-finish, late-start, late-finish, critical path and float” you know you are dealing with CPM software. “Simplified” CPM software drops formal task logic, giving users Gantt Charts, timelines etc. With CPM, you are doing “project management”.
The BPM methodology dates back to the early 1990’s. Early BPM solutions had an almost exclusive focus on process documenting, process modeling and process improvement. Aspiring BPM practitioners had to first master a BPM notation (e.g. BPMN) before undertaking their 1st BPM project.
BPM consultants and BPM software vendors soon realized that what customers wanted/needed was not “Business ‘Process Management’ ” but “Business (Process) Management”. This led to a method called Adaptive Case Management (ACM) where the focus is on managing workload to reach Case goals/objectives with the help of orchestration from background BPM workflows called “best practices”.
Whereas BPM is a plan-side method, ACM is strictly a run-time-side method and it needs two additional methods called RALB (Resource Allocation Leveling and Balancing), with obvious implications, plus FOMM (Figure of Merit Matrices) that gives Case Managers the ability to make periodic non-subjective assessments of progress toward Case goals/objectives. ACM also requires “Rule Sets” to provide governance (i.e. the prevention of extreme unwanted deviation away from “best practices”). With ACM/BPM you are doing Case Management.
Discovery that customers wanted/needed ‘Business (Process) Management’ led to a temporary paradox of encouraging workers, on the one hand, to make consistent use of “best practices” (orchestration), yet instructing these same workers that they should feel free to deviate from “best practices” where appropriate, with the proviso not to engage in extreme unwanted deviation away from ‘best practices” (governance).
Steve Jobs summed it all up nicely “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”
Bottom line, if you are looking for workflow/workload management solutions, make sure you know the type of work you want to manage and then, only, focus on CPM or ACM/BPM.
Steer clear of CRM, DCM and other narrow ‘solutions’ – these are likely to address a portion of your needs, but not all of your stated needs.
The thing about needs is you ideally want something capable of satisfying your unanticipated future needs, not just your current needs.