A model with seemingly infinite detail, and without the right abstractions to make it easy to understand. A model's first best purpose is to be understood by others.
A process model will be not a success if it is not machine-executable. As we know, each people will understand the same model differently.
Very simple : You model for a purpose. If the model doesn't support you in your purpose, it is a failure.
When it suits the purpose, we can argue what should be on a process model to make it readable and effective.You can for example also agree some conventions around this, just for the simple purpose that everyone uses similar 'language' to understand each other better.
And don't forget the quote from George E. P. Box: "Essentially, all models are wrong, but some are useful"
The model is doomed to failure when graphic process maps cannot immediately be compiled to generate run-time template instances in a Case management environment
Without an ability to carve up a map into individual sequenced steps and automatically post tasks by role as per BPM logical sequencing at individual Cases (insurance claims, legal cases, patients, customer job shop orders) with resource leveling and balancing facilities, thing quickly go off the rails.
The problems start when there is no seamless transition from plan side to run time side - the organization has no way to manage arbitrary mixes of ad hoc and structured steps at Cases (workers and others inserting ad hoc tasks, users micro-scheduling their tasks, supervisors leveling and balancing workload across Cases based on resource pool levels and changing priorities).
With the up-front premise that it's going to be implemented on a new BPMS then "when the process model looks exactly like how they do it now." Hanging an existing, as-is process(es) on a new BPMS is, has always been, will always be, a sure-fire recipe for ugliness down the road.
But the real answer of course is:
When it doesn't fit on one page and doesn't have 5 +/- 2 sub processes.
Spaghetti. If your process model looks like spaghetti -- AND the business team in the room intuitively know that the process shouldn't look like spaghetti -- then your process model is doomed from the get-go (i.e. the model or the sale won't be approved).
The solution is that any artefacts unrelated to business process need to be abstracted out (integrations, ESB, SOA etc.). And any business rule collections need to be captured appropriately in a decision table (ideally via DMN). Judicious use of collapsable sub-processes is helpful too. The before and after is amazing.
Great answers so far! I'll add a physical symptom of a process that is going to fail.
Someone is concerned with access to a plotter to print the process.
I have personally seen this a few times and none of them have worked out. 1998 called, they want their plotter back.
When the people who do the work you're capturing in the model don't use it.
No matter how many other people may refer to it or use it, it won't matter because it won't be up-to-date if the people executing it aren't using it, finding it value added and making sure it's updated and relevant.
Amazing how many of the comments above imply the following (unpopular) conclusion without actually saying it:
Your model is doomed to fail if it's built on a flowchart of greater than trivial complexity.
Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model. They can be valuable for documentation purposes (for example, swim lane diagrams). But having now spent a generation trying to square the circle by using flowcharts as the programming language of business process, it's time to bid them a fond farewell and move to a model that doesn't require a plotter, doesn't look like spaghetti, and doesn't run off the page in a way that makes it impossible to follow.
If you cannot explain it. Then you cannot follow it. Therefore it is doomed.
Agnostic to the tools and platforms you choose to use for modeling and executing business processes, the process model needs to be easily explainable. Process, more specifically bad process, often outlives the human capital that manages it or is required to interact with it.
Complexity seems to be a recurring theme in this thread as to what makes process doomed. Meaning you are able to assess a process end to end in order to determine it's level of complexity relative to another process you have encountered. In order for this to happen someone had to explain it and someone had to document it. Complexity is also subjective.
Risk = BadProcess
What is the complexity score of a process model that cannot be explained?!
1. If people working on the model use the term 'process' very loosely and don't adhere to any notation but continue investing into design of such process 'models'
2. If the model mixes activities from many levels of the process architecture (poor decomposition)
3. If the process model attempts to describe activities that cannot be described by the model i.e. work stages
4. If the process model is overly complicated
5. If the process model attempts to describe dynamic work handling requirements using notation that won't fit the bill
6. If the process describes modeler' perspective of one's work without properly validating it with the process stakeholder. People view processes differently during execution vs. modeling
Reading over the 17 responses plus a fair number of comments on many of these, are we all on the same page as to what a "process model" is?
1. Is a "process model" a simplification of an actual process such that it has communicative value but no value for "managing a process" in a run time environment?
2. Do the contributors make a distinction between a "process model" and "modelling a process" (the latter meaning piloting a run-time process template\instance with a small group of stakeholders with a view to identifying logic errors, bad forms and then improving that process)?
3. At what point in a changing mix from one Case to another of ad hoc interventions versus end-to-end processes do we say we are doing adaptive case management as opposed to hosting processes in a BPMs environment?
4. For other than simple processes at Cases, if there are multiple branching decision boxes and roles change from one step to the next, do the contributors agree that the level of detail for run-time Case management is a new node when the performing skill changes, or when there is a change in the resources needed to perform a next step? An exception to this rule is one step, performed by one resource over a very long period of time- here we need milestones (i.e. multiple steps) to facilitate assessment of progress.
Maya Angelou once said: 'people will forget what you said...but people will never forget how you made them feel.'
If models don't make people feel positive, reassured and confident, they are doomed. Models are created to be useful, purposeful, compliant and accurate (as depicted by countless answers in this forum). However, if the modeler and/or consumer don't 'feel' good about them, it's wasted. This has been my biggest professional challenge.