Sizing process complexity

A lot of people think the complexity of a process is about the number of stages and steps it has but it’s not.

I have often seen BAs do an initial analysis of a business process by producing a diagram like this:

This is fine, as long as you have already established the scope of the process (click here for my tutorial on that on YouTube) and you are planning to elaborate the process beyond this simplistic diagram. Unfortunately, I have been on projects where the BA thought that was enough. A poor way to understand the complexity is simply to count up the number of stages and steps. However, a process is more than a count of its steps. The real complexity from a software implementation point of view lies primarily in the following:

  • The decision points throughout the process, leading to alternative or parallel paths.
    • Here, the complexity may be in the logic of the decision, rather than the process itself.
  • Points in the process that depend on activity and outcomes in one or more processes.
    • Again, the complexity may be in a decision that asks “Is X True?”, where the answer depends on conditions in several processes.
  • Alignment of one process instance with multiple instances of another process.
    • An example would be aligning one instance of a process to fill a job vacancy with multiple instances of a process to manage applications for that vacancy (as Bruce Silver describes in his book “BPMN Method and Style“).
    • This is often a trap for inexperienced process modellers who try to model everything as a single process.
  • The points where any software you are going to build will need to interface with other software systems.

Any other steps are going to be about gathering data either to make decisions during the process you are modelling, to send data to other processes or display data to the user.

I won’t go into interfaces because they are for the technical solutions architect to explore (although the BA may be involved in identifying those interface points). In any case, if your process model is technology-agnostic, then interfaces will not be relevant yet.

The significance of decision points is often overlooked, however, largely due to a lack of awareness of the power of decision modelling. Most BAs I’ve met still think in terms of business rules, instead of decision logic. Moreover, they often start thinking about business rules too late. As soon as you have defined the scope of the business process, you should ask the business what key decisions need to be made within each process stage. At this point, the order of them is not important. It’s unlikely the business will be able to remember every step that needs to be performed in the process but it is quite likely they will remember the important decisions that need to be made.

You need to understand two things about a business decision at this stage in your analysis:

  • Roughly how many outcomes it can have
  • Roughly how many data items are needed as inputs

This information is enough to be able to ‘t-shirt size’ those decisions. I don’t have a formula for calculating the complexity of a business decision based on those two pieces of information but I’m sure you can see that a decision that can produce two possible outputs based on three inputs will be a lot simpler to analyse, model, test and implement that one that can produce five possible outputs based on 300 separate input data.

The technical solutions architect will size any interface points and you can produce something like this:

In this example, the zeroes represent steps that just gather or present data, while the ambers and blues represent decision points and interface points.

When asking the business to identify the decisions they have to make, help them identify hidden decisions, i.e., ones that they are so used to making that they don’t give them much thought. Examples could be: duplicate checks, whether to send an email, how to determine what data to put in that email, data validation logic, etc. In a loan application process, don’t assume that the only decision being made is whether to approve the loan.

Taking a decision-focused view of the business process will help you understand the true sophistication of the process.

As for multi-instance alignment, such as the example of the process for filling a vacancy versus the process for managing and application for that vacancy, you have to identify each process and estimate its complexity separately.

Kind regards.

Declan Chellar

Related posts:

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>