Rather obvious, isn’t it, so how come people have problems understanding the concept of a Case?
In respect of discrete manufacturing, or, work in the office/services area where no two initiatives are likely to be performed the exact same way, you have structured tasks being performed by multiple individuals along “best practices” instances and you have unstructured (ad hoc) interventions being performed by the same or other multiple individuals.
The data that is collected as proof of performance has to go somewhere and the best place for this is a database management system, not Windows file folders.
So, “Case” means a repository for data but Case also satisfies another important need which is the ability to provide a foundation for decision support at Cases.
There are two major types of decisions that rely on Case content – one is decisions relating to open options at the time of performance of a structured task / performance of an ad hoc intervention, the other is decisions relating to achieving the objectives and goals of a Case.
In assembly line work and construction, when you get to the last step or you cut the ribbon, you are done, assuming your flowgraph is comprehensive.
Not so with Cases – here due to the mix of structured and unstructured work, there is no convenient end/merge point, so you need to define objectives and you need a way to measure progress toward attainment of these objectives. It helps to have interim “milestones” (i.e. do this by this date) and these are goals.
Now, to illustrate a point, put a group of medical specialists in a room and try to get agreement as to which of a particular patient’s problems is the most important and you are likely to be in that room for a long time.
It follows that we generally need a non-subjective means of ranking goals/objectives for the purpose of reporting progress.
You can read all about this by reading “Adaptive Case Management Earned Value Matrix Model” at