In this post, I am sharing the following collection of basic principles as a guideline for designing a hierarchical process tree diagram (HPTD):
1. Designing an HPTD requires top-down approach. That is, a higher level of the HPTD contains less information than a lower level of the HPTD.
2. The root or 0-level of an HPTD represents the scope of the HPTD.
3. Process decomposition is considered completed if every leaf of an HPTD is a primitive process. The primitive process is a process that have zero-to-many inputs, but one-and-only-one output
Note: In some cases, it’s recommended to conclude process decomposition before reaching the primitive processes of the HPTD (see Point 4).
4. Best Practice Suggestion: In case of a domain with a large volume of processes, it is recommended to continue with process decomposition till reaching a reasonably acceptable level of the HPTD.
What is and how to establish this reasonably acceptable level of the HPTD?
The reasonably acceptable level of the HPTD is a level providing a set of information/details that enables a full understanding of the domain: mutual relationships between the instances of the domain and relationships between the domain and its surrounding.
In other words, it’s suggested that process decomposition needs to be carried out until the full understanding of the domain is reached, regardless of whether the lowest level of the HPTD contains primitive processes or not.
Or, simply saying, the full understanding of the domain can be obtained without having the completed process decomposition (see Point 3)
Establishing the reasonably acceptable level of the HPTD depends on many influencing factors such as:
Available time and resources
Complexity and volume of the domain
Current phase of the project life cycle etc.
Sometimes, instead of ‘full understanding of the domain’, we may end up with ‘reasonable understanding of the domain’ due to – for example – limited time or resources. In that case, the gap between ‘reasonable understanding’ and ‘full understanding’ would need to be bridged by applying other approaches rather than proceeding with process decomposition.
5. Best Practice Suggestion: A process should have no less than 3 and no more than 8 of its sub-processes. However, the recommended maximum number of the sub-processes is not eight, but six.
Note: If a number of the underlying sub-processes isn’t between 3 and 6(8), it is an indication that the process needs to be reviewed – it could be that something has been overlooked.
6. Every process should have a name that uniquely identifies the process within a given domain
Note: If you are creating an HPTD for the as-is with two or more repetitive processes, you could name these processes by simply adding a suffix like: RepetitiveProcess1, RepetitiveProcess2 …etc.
7. An HPTD must not have processes structuring an infinite recursion
Note: Although this rule seems obvious, the question is: If some ‘as-is’ processes do structure an infinite recursion, how could the rule be implemented in creating an ‘as-is’ HPTD? My suggestion would be to map and decompose the ‘as-is’ processes as ‘to-be’ processes within your ‘as-is’ HPTD – for the major purpose of mapping the as-is is to deliver the to-be, in any case.