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 (see the end of this post for a link to a tutorial on that) 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 two things:

  • The decision points throughout the 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 or to send 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 reveal the true sophistication of the process.

Kind regards.

Declan Chellar

Related posts:

Visit Us
Follow by Email

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>




This site uses Akismet to reduce spam. Learn how your comment data is processed.