Process descriptions

As we have seen in the chapter on IM, there is a strong correspondence between the sequence of tasks in a process and the sequence of information actions: process management and IM overlap. Therefore, the first step towards effective IM in any process is understanding the process itself: what people do and how their actions, decisions, interactions and transactions relate to the production, dissemination and utilization of information. Starting IM by analysing the process also has advantages for the deployment of IM measures: most people and organizations are more process-oriented than information-oriented. As a result, they may have difficulty identifying and organizing information actions without a clear operational context. Using a process model as basis makes clearer why and how one should manage information.

The various ways of describing processes fall under two main kinds:

1. Textual descriptions, such as reports, often including tables and lists that summarize key points
2. Diagrammatic descriptions: visual displays of the process structure, either focusing on the overall picture or providing step-by-step descriptions of the process flow

The two kinds are complementary: textual descriptions can be detailed specifications, while diagrammatic ones afford overview. This fundamental difference makes textual descriptions better suited for the level of single tasks and diagrammatic ones the unmissable starting point for the whole process. Doing away with diagrammatic descriptions and relying solely on texts is inadvisable because of the resulting difficulty in constructing mental overviews. Recognizing dependencies between multiple tasks, redundancies, omissions and other process characteristics is quite demanding for any reader of a text. It can lead to unnecessary errors in interpretation, including through illusions of cause from presumed precedence or coincidence in time, especially in sequential processes (which abound in AECO). Diagrammatic descriptions help us overcome such cognitive limitations by serving as mnemonic aids for understanding and managing processes: they can be seen as checklists of tasks and of relations between tasks that unburden actors’ memories and prevent them from missing critical steps or available options at any step in a process.

This chapter builds on the potential of graphs to answer two fundamental questions:

1. How process diagrams should be made: the syntactic and semantic rules they should follow to capture the composition and structure of tasks in a process with the right abstraction and consistency
2. Which problems can be addressed in these diagrams, with emphasis on the unwanted products of Type 1 thinking, so that the social side of management becomes both more specific and free from cognitive illusions and fallacies

Flowcharts

Basic flowcharts suffice for describing practically any AECO process as a sequence of tasks towards a specific outcome. These diagrams are directed graphs (digaphs), in which objects are represented by nodes of various kinds, while relations are described by arcs (Figure 1). The direction of the arcs indicates the direction of flow in the process. Bidirectional arcs should be avoided because they usually fuse different relations, obscuring differences in time and purpose between denoted actions, e.g. between an evaluation and the feedback that follows. Separate representation of each such action is essential for understanding and managing process flow.

To make an usable flowchart of a process, one should adhere to a few basic rules:

• Uniqueness: each thing should be represented by a single node in the diagram. The uniqueness rule makes explicit the actors, stakeholders and tasks in a process, the scope of each, process flow and, through these, the overall complexity of a process. It also permits the use of graph-theoretic measures, such as the degree of a node, in analysing the process.
• Decision degrees: the in- and out-degrees of each decision node should be at least 2. This means that there are at least two things to be compared in order to take the decision, for example a design and a brief, and at least two decisions that could be taken, for example design improvement or approval.
• Specificity and comprehensiveness: a process flowchart is not an abstract depiction of vague intentions, like many conceptual diagrams. Each node and arc should be meaningful as an unambiguous actor, task or relation. No directly relevant task or relation should be left implicit or otherwise absent from the diagram. For example, it is not helpful to assume that a design is somehow evaluated anyway and neglect including the evaluation tasks in the diagram or omit the criteria of the evaluation.

Figure 2 is a simple example of a process in building design: the estimation of construction cost in early design, on the basis of gross floor area. The process involves three actors: a client, an architect and a cost specialist. These are responsible for the budget, the design, the cost estimation and the evaluation of the estimate, which leads to either feedback to the design (usually to lower the cost) or acceptance of the design as it is. The process described by the diagram is as follows:

1. The client decides on a budget for the building
2. The architect makes a design for that budget
3. The cost specialist estimates the costs of that design
4. The design is evaluated by comparing its costs to the budget
5. If the costs are within the budget, the design is approved; if not, the design must be improved and evaluated again (repeat from step 2)

The comparison between this list of steps and the process diagram is telling: there is nothing in the list that cannot be inferred from the diagram. Reading the diagram is faster than reading the list and the process structure is easier to recognize in the diagram than in the list, especially concerning relations between tasks. If the list was replaced by a less structured text, the differences would become even greater.

The example is purposely kept simple in order to illustrate the basic principles of process diagramming. A client obviously issues more instructions and requirements, e.g. a design brief, while the design must also take into account other goals and constraints, such as the applicable building codes and planning regulations, location features etc. Even in this simple form, however, the diagram accurately describes the fundamental structure of cost estimation, including the double role of the budget as a constraint in designing and as a criterion for design evaluation, as well as the generate-and-test approach to design (with analysis between generation and testing).

Due to the uniqueness rule, there is a single node for the design. Evaluation is followed not by a new design node but by feedback to the design. This makes clear that the decision is to improve the design rather than produce a completely new design, possibly by a new architect or with a new budget. This expresses the iterative character of design: the cost evaluation can be repeated a number of times, each resulting in design improvements, until finally the evaluation returns approval of the design. The example contains feedback only to the design but it could also feed back to the budget if the design evaluation suggested that higher investment, e.g. an energetic solution that raised construction costs but lowered operation costs, would return significant life-cycle benefits.

A process diagram without feedback loops is by definition suspect. Figure 3 is a negative example (a poor diagram), which also violates the uniqueness and decision degrees rules: it is as if many architects are involved, each producing a different design that is subjected to a different evaluation with unclear criteria and outcomes. Above all, however, it presents an iterative process as sequential, with an arbitrary, unsatisfactory conclusion that comes only because the diagram ran out of space. In comparison, Figure 2 leaves no fundamental matters unspecified, including by means of feedback to an earlier task following a transparent decision.

In short, the diagram in Figure 2 affords overview of the process in the same way that a metro map allows travellers to see every station and line in a city, the location of each station, its connections to others via different lines and the patterns that emerge in each line and any part of the metro network. The process diagram allows us to zoom in on any task, understand its immediate context, track how we come to that task and where we go from there, as well as identify general characteristics of the process, for example if it is sequential or iterative.

Testing process diagrams

A basic way of testing the structure and content of basic diagrams is from the perspective of each actor and stakeholder. Starting from the beginning of the process, we need to consider at each node if this actor or stakeholder is related to this task (i.e link what to who and consequently also how). If yes, then we need to establish if the connection is:

• Direct: it is a task that should be undertaken by this particular actor, e.g. the design by the architect
• Indirect: it connects to another task by this stakeholder, e.g. the architect needs the budget to guide the design costs

Once this is completed and the diagram accordingly corrected, the involvement of each actor and stakeholder can be tracked in the process (i.e. extend to when). To do this, we need to examine the subgraph that contains all directed walks that start from the node of the actor or stakeholder. Figure 4 is the subgraph of the cost specialist, in which there are two directed walks to design approval: one directly after evaluation and one following feedback to design. In this subgraph, we can identify the extent of the cost specialist’s involvement, examine if the sequence of the process steps is logical and, on the basis of anti-data, identify relations to other actors, stakeholders and tasks, e.g. who is making the design improvements following feedback and what are the criteria for the evaluation (i.e. that the evaluation node should connect to a budget). The results returned from this examination are obviously significant for the functioning of the particular actor or stakeholder but also useful for the manager: in many situations, missing nodes and especially arcs become apparent only in such subgraphs.

Following the examination of each perspective separately, we should investigate how they come together in a simulation the process flow. This is best done by a group, in which each member assumes the role of an actor or stakeholder. In board-game fashion, the simulation goes through the process step by step, stopping at every task to consider not only if the task is fully and clearly specified but also where each actor and stakeholder is at that step of the process. The former makes clear the interactions between actors and stakeholders, including through their products. The latter helps anticipate the nature and timing of upcoming interactions, e.g. that the budget should be available before the architect starts designing. Many conflicts in a process are due to bad timing and the consequent need to make haste in order to catch up with the process flow.

Overcoming cognitive limitations

The overview afforded by process diagrams is not merely practical for explaining the process, so that all actors know what to do and when, and managers can organize actions towards project goals. It is also instrumental for overcoming cognitive limitations that lead to mistakes and failures. Acknowledging that project participants may suffer from cognitive biases and illusions, and trying to help avoid them is a key managerial task. For example, explicit connections between tasks help avoid illusions of cause. If the connections are accurate and no tasks are missing, one cannot easily infer fictitious causes from accidental precedence or coincidence in time.

To achieve such protection, it is important to avoid thinking in conventional, vague structures, such as preliminary, concept, technical and detail design stages. In a process diagram, such stages should never become nodes. Instead, all stages should be parsed into specific tasks and patterns, like the evaluation pattern in Figure 2, which matches any stage and therefore supports condensation. Distrust of conventional structures is important for the successful deployment of Type 2 reflective processes. These are often acquired by education and training, and therefore reflect cultural and professional habits. As a result, they may actually discourage analytical thinking by imposing rules of thumb and other summary or pseudo-analytical decision structures, which are embedded in conventions we tend to follow unthinkingly.

It is also important that managers are aware of their own cognitive limitations and how these can affect a process. Process diagrams can protect actors individually and as a group from avoidable mistakes but the same applies to mistakes managers make in the setup and control of the process. The most common of these relate to illusions of confidence and skill that cause managers to allocate tasks or even delegate custodianship of whole parts of a process without sufficient control (black boxes). Making the relations between actors, stakeholders and tasks explicit is a solid foundation for avoiding such illusions.

Reflective thinking, cognitive simulation and learning potential

A general advantage of a process diagram like Figure 2 is that it stimulates Type 2 reflective thinking. In contrast to an inspirational conceptual diagram, a flowchart like this supports analytical anticipation of actions and outcomes in an explicit manner that reveals unsolved problems and casts doubt on automatic decisions based on habit or convention. Unlike the mind-numbing Figure 3, it invites us to actively follow progress in a process, discovering possible problems on the way. By tracking the dipaths that lead to a node of interest or depart from it, we can examine if anything is missing or uncertain, if the connections between tasks seem doubtful or vague, or if the diagram contains practices that have led to failures in other projects. For example, a client may rightly worry that feedback to the design could lead to endless iterations with minimal improvements every time and therefore to considerable delays.

The diagram also supports improving the process through Type 2 algorithmic thinking. By tracking and evaluating progress, developing variations and measuring the graph we engage in cognitive simulation that allows all actors and stakeholders to test their assumptions and verify their expectations in an interactive manner. At a basic yet critical level, a process diagram can be used to verify the process frame, that is, if all options and consequences of each decision, all goals and constraints are present. For example, the budget cannot be absent from Figure 2: how else can we evaluate the costs of the design?

With the right frame, we can then consider improvements either by tweaking the process design or by projecting what-if and other scenarios, so as to connect better to project constraints or the perspectives of various participants. This helps anticipate problems and so prevent planning and sunk-costs fallacies. In the example of Figure 2, how long can we keep on with the iterations in a generally acceptable but not perfect situation? By evaluating the improvement achieved with each iteration, we can see if the design is reaching a plateau and take the decision to abandon or approve it, even if the costs are still higher than the budget. Alternatively, we can impose a ceiling on costs (as in Figure 5), so that the difference between costs and budget is not so big that the iterations become pointless. This nudges the design towards staying close to the budget, for example by constraining the selection of construction types and finishes.

Allowing for problems that could not have been anticipated is more difficult and requires awareness of Type 1 thinking limitations in both process management and the contributions of each actor. The interaction between the two is critical: the process design should stimulate reflective thinking in all respects, allowing actors to reflect not only on their own tasks but also on the whole process. Precision in the description of tasks is an important prerequisite because it stimulates meaningful questions about how and why. For instance, it can stimulate actors to question whether the cost estimate and approval in Figure 2 should be binding for the whole design project: this estimate is rather rough and relies heavily on the new design being quite similar to other buildings from which reference costs are derived. Therefore, making more detailed and precise estimations, including by refining the reference class, should be considered as soon as the design information allows it and before the difference between later, more detailed estimates and this one become an issue of contention in the project.

Working with analytical process diagrams is also important for skill development. In many activities, such as sports or music, improvement depends on instant feedback that triggers calibration: a wrong pass or a false note immediately call for evaluation and adjustment. In areas like AECO, there is a long latency period between taking a decision and realizing its effects — so long and so obscured by intervening events (therefore also subject to illusions of cause) that the relation between cause and effect may completely elude us. In the absence of instant feedback, it is perhaps not surprising that we opt for optimism and confidence. Cognitive simulation with process diagrams compresses time, making it easier to discern probable consequences of specific decisions before they occur, reconsider these decisions and their backgrounds, and so understand and learn.

Framing

The functions of a process diagram (providing overview, stimulating reflective thinking, supporting cognitive simulation and generally helping avoid Type 1 mistakes) require an appropriately broad frame: one that includes all relevant aspects and constraints, as well as all probable options and outcomes. In such a frame, we can easily detect dependencies between tasks and consequently take properly informed decisions at any task and prevent the spread of local mistakes to the rest of the process. However, a broad, inclusive frame goes against the conventional wisdom that reducing the complexity of a phenomenon makes it easier to understand and handle. This is something frequently done in conceptual diagrams, to the detriment of clarity. Process diagrams do not necessarily reduce the complexity of a process. Instead, they make it explicit and manageable, preventing the isolation of subproblems in narrow frames.

With respect to framing, a process diagram should go beyond stated objectives and include all things that connect directly to each task in the process, whether they occur in the process or not. In a design process, for example, the diagram should include the applicable planning regulations and possibly the local authorities behind them. The reason is that the regulations constrain many decisions on the form of the design and the local authorities may have to grant an exemption from these regulations. If an exemption is probable, the process diagram should also include feedback to the regulations. Things with an indirect relation to the process, for example the legal framework of planning regulations and the central authorities that determine it are highly unlikely to play a role in a design process (e.g. receive direct feedback from any process task). These should not be included in the process diagram.

In the digraph of the process diagram, extraneous nodes of questionable relevance can be detected by their degree. Long subgraphs starting from a source node and having an in- and out-degree sequence of ones should be considered for exclusion because they probably describe tasks that are irrelevant to the process (Figure 5). As a rule, such peripheral subgraphs, starting from a source node, should have a length of 2 or less: one actor or stakeholder node and one task node, the latter connecting to a task that certainly belongs to the process, as with the client/brief subgraph in Figure 2. If the source is a constraint, e.g. planning regulations, and the planning authorities are not involved, then the length can be 1.

A related use of graph measures is to make certain that the core of the process, i.e. all essential tasks are in the center of the graph, with actors, stakeholders, preparatory and external tasks in the periphery. If the center contains non-essential or peripheral nodes, the digraph probably contains extraneous nodes.

There are two complementary ways you can measure the center and periphery of a process diagram. The first is to do it in the underlying undirected graph, i.e. the graph that is obtained if every arc is replaced by an edge (Table 1). As any process diagram is a weakly connected digraph, this returns an impression of the overall structure of the process. In this example, the center comprises the design and evaluation nodes. The client and cost specialist nodes form the periphery. The closeness measures agree with the interpretation of the center but also suggest that the architect and design approval nodes are not as central as the budget and cost estimation nodes.

The second way is to measure distances in the digraph itself (Table 2). Note that as distances are measured in dipaths, there are many nodes that do not connect to each other and that the table is not symmetric with respect to the diagonal: the distance from node X to node Y is not the same as the distance from node Y to node X. The measures in our example suggest that the core of the process comprises the budget, cost estimation and evaluation nodes, with only the architect in the periphery. In terms of closeness, the evaluation node is the most central, followed by the cost estimation, while the client and the cost specialist are closer to the architect. In other words, the digraph measures give a slightly different view, more specific to the cost estimation process. Nevertheless, such differences are minute. What matters is that both tables confirm that there is nothing fundamentally wrong with the process in Figure 2.

Linear subgraphs, like the ones in Figure 5, with a degree sequence consisting largely of ones, are suspect for two additional reasons. Firstly, they may be the result of over-analytical thinking that unnecessarily splits tasks in steps that should be combined. Secondly, the absence of feedback arcs and other cross-connections suggests a schematic interpretation of the real process that does not include all options and constraints, i.e. narrow framing. To prevent decision taking in narrow frames, it is advisable to avoid sequential procedures, consisting of tasks each involving only one or two actors or stakeholders and concerning decisions on a single issue or aspect. Instead, decisions should be combined and made by larger groups. In a design evaluation, for example, one should not first evaluate the design for compliance to planning regulations, then to the building code, then to the brief and finally to the budget. Instead, all checks should be combined in a single evaluation that also includes the relations between the three criteria (Figure 6): a discrepancy with respect to the brief could be due to inescapable planning constraints, while additional costs can incur as a result of design decisions that achieve more than what the brief asks for. A combined evaluation therefore supports precise and effective feedback to the cause of a problem, such as a request for exemption from existing planning regulations because of the added value of an energetically innovative solution that adds to the building height.

Group processes

A frequent objection to combining decisions and evaluations is the resulting complexity of the tasks (recognizable by the high in-degree of the nodes). This objection is founded on the presumed efficiency of simple tasks with narrow frames and ignores not only the dangers of narrow framing but also the low effectivity and inefficiency of sequential processes, especially if complex problems are artificially parsed into long sequences. It also follows the dangerous tendency in group decision making to put consensus above true solutions. In meetings, for example, it is customary to start debating a problem immediately and try reach a conclusion upon which all participants agree as soon as possible. This allows the most vocal participants to dictate the level and direction of the discussion. However, as we have seen, these persons may be less knowledgeable than presumed and suffer from illusions of confidence. They might therefore lead the discussion astray, while more hesitant participants hide behind them and follow their direction, creating a false feeling of rational alignment. It is recommended that, instead of initiating a meeting with an immediate debate towards general consensus, each participant should first prepare and present a separate analysis of the problem and suggestions for its solution. Informing each other in this manner is a more constructive and inclusive basis for a discussion that compares or combines different options, taking more aspects into account and considering them from more perspectives.

This approach to group decision making reflects the differences between Type 1 and Type 2 processes: for personal action, Type 1 thinking may suffice but for joint action and interpersonal communication, especially with respect to complex, partially shared goals (as in most AECO processes), Type 2 reflective processes are required. The load-bearing structure of a design can be decided in a flash of inspiration but explaining it to the other members of a design team who have to adjust to it, as well as estimating its effects (e.g. direct and indirect costs) is clearly more analytical and time consuming. It is therefore important that the process design ensures that actors arrive at combined decisions adequately prepared, with complete plans, proposals, analyses and evaluations, which are made available to all in time, before any deliberation and decision. This makes all options explicit, creating a broad frame and basing consensus on the comparison and combination of options rather than the opinions and personalities of vocal participants.

In a process diagram, this means that actors and stakeholders do not give direct input to a decision node, as the client does in the faulty example of Figure 3. That would imply a personal, possibly variable opinion, e.g. that clients change their mind about what they want without prior communication to other project participants. Instead, actors and stakeholders should connect to decisions through the products of their tasks, as the client does through the budget in Figure 2. A decision should take place by comparing the different products, e.g. a design to its brief and budget, and its outputs should include feedback to these products: if clients change their minds, this should be expressed clearly as adaptation of briefs, budgets etc. In graph terms, this means that the distance of actors and stakeholders from decision nodes should be at least 2.

In the same vein, task nodes do not output into actor or stakeholder nodes. An arc leading from e.g. a design to a client, as in the misleading diagram of Figure 3, does not mean that the design is given to the client but that a client is selected on the basis of the design — in fact, a new client, different to the one who initiated the process at the top of the diagram. A correct diagram would indicate that the design is submitted to an evaluation of its compliance to the brief, similarly to the comparison to the budget in Figure 2. The client is not directly involved in this compliance evaluation. One should not confuse the tasks in process diagrams with the social interactions that take place around the tasks. The presence of clients in meetings on brief compliance does not mean that the brief is ignored, only that the compliance evaluation is communicated directly and transparently to the clients.

The emphasis on tasks and their products in process diagrams is important for solving problems in AECO. These problems are often considered ill-defined and therefore hard to solve because there is no clear agreement on the problem, its constraints and goals. This makes difficult to agree on solutions and take joint decisions. By making tasks and products explicit, any lack of agreement becomes clear to all and nudges them towards less fuzzy problem descriptions and procedures. There is, for example, no reason why a budget should not be specific and transparent, calculated on the basis of clear parameters that can be modified in response to the design or changing social, technological or economic conditions.

Illusions of confidence and skill

Process management is particularly sensitive to illusions of confidence concerning self-assured participants or presumed experts. A clear expression of these illusions are black boxes in a process: chunks that are delegated to a particular actor without clear understanding of what takes place there and uncertain relations to the rest of the process. Such chunks are often claimed by specific disciplines, which makes the selection of project participants for those disciplines quite sensitive. Choosing them on the basis of track record is a positive development, only marred by the lack of objective and reliable performance measurements, which render any selection even more sensitive to illusions of confidence and skill. It is quite hard to distinguish what went well in previous projects thanks to a particular actor versus other actors or contextual factors. In a successful project, practically everyone claims credit for what went well. It is even more difficult to establish what went wrong due to a specific actor, since very few are brave enough to admit responsibility. In the end, all one can tell is that some actors were involved in a project, that the project had a certain performance and that some aspects were better than others. Such vagueness does not free us from any illusion.

To safeguard a process we should therefore avoid delegating large clusters of tasks to actors or stakeholders, turning them into black boxes that are inevitably beyond control. Instead, a process description should parse activities in as specific tasks as possible. For example, rather than abstractly asking for a cost estimate, we should specify how the cost estimate should be made: the prerequisites to making an estimate (such as a design containing the necessary information), the method used for the estimation, the timing of the estimate relative to the rest of the process (making sure that the prerequisites can be met, as well as that the estimate is directly used) and how the estimate should be evaluated, including follow-up actions such as feedback to the design. It goes without saying that bundling the design, the cost estimation and the evaluation into a single node is unacceptable. Equally dangerous is entrusting the subgraph containing all these tasks to a single stakeholder.

A structured, analytical process is neither trivial nor insulting, even to the greatest of experts, especially if the parsing of the black boxes is based on their approach and facilitates their actions and interactions with the rest of the process in a transparent and operational framework. As for process managers, it is merely a matter of good housekeeping and discipline that amounts to feedforward (anticipating what might occur and establishing procedures for prevention, early detection and immediate action), as opposed to feedback (waiting until a problem emerges, deliberating about its significance and finding ways to resolve it). Feedback as a means of control seems inevitable in any process but feedforward greatly reduces the need for feedback and, above all, the pressures associated with it.

Narratives and coherence

A realistic diagram makes the process inclusive, empowering each participant to track progress from their own perspective and identify interactions with others. Process management benefits from inclusiveness, too, because it becomes protected from the dangers of one-sided narratives and the frictions and imbalances they can cause. Instead of having a single narrative, from the perspective of a dominant participant and possibly accepted due to a halo effect, the various actors and stakeholders can project their own narratives on the process design and so escape inside views and planning fallacies. In this way, coherence is not apparent or imposed but real and constructed by all participants together, resulting in scenarios that are realistic (i.e. scenarios that may include conflicts and lacunae but also make them clear to all) and combat probability neglect: multiple perspectives help give each risk the right consideration, so that big risks are not ignored and small risks are not given too much weight (as is often the case with inside views).

This also puts performance before compliance: rather than trying to stay within the narrative, the process is driven towards the highest goals attainable. For example, the budget in Figure 2 is based on assumptions that may remain unchallenged if all that matters is that the design conforms to the budget. If, on the other hand, these assumptions are negotiable and adaptable to suggestions by project participants and outcomes, then the process can lead to a better relation between costs and performance.

To avoid straight-jacketing a process into a narrative, it is again advisable to avoid sequential process designs. Most narratives, certainly in AECO, tend to have a linear structure that imposes one narrow frame after the other on the interpretation of a problem, cutting it down into subproblems in a way that fits the coherence of the narrative but not necessarily the needs of the project. Combined tasks and parallel tracks can improve reliability, as well as effectivity, by allowing each participant adequate scope for their activities and priorities.

Graph measures

As already mentioned, graph measures can be used to quantify indicators, checks and controls, making them easier to implement in a process diagram:

• Decisions nodes should have in- and out-degrees equal or higher than 2
• Linear, peripheral subgraphs with degree sequences of ones should have a length of 2
• Important tasks should be in the center
• Preparatory and external tasks should be in the periphery
• Actor and stakeholder nodes should have a distance of 2 from decision nodes

In addition to these:

• The degree of a node is a good indication of local complexity.
  • A high in-degree suggests complexity in information processing and decision making at the particular task, as well as dependence on multiple actors or previous tasks. If a high in-degree indicates a collection point, e.g. different specialists coming together to compile a brief, you should organize the resulting group processes with care without splitting the node into a sequence of tasks that gives the illusion of simplicity. On the other hand, if a node denotes an abstraction or agglomeration of too many tasks (e.g. a complete stage like concept design), its high degree should prompt a more analytical and explicit description of these tasks.
  • The out-degree indicates scope: how broad the effects of a task are or how widely a stakeholder is involved in the process. For example, it is expected that the products of a key task like briefing are used in many places in a process. But even if the significance of the task is low, a high out-degree means that many others may depend on its timely execution.
• Bridges indicate transitions from one part of the process to another (e.g. transition between stages), as well as connections that are sensitive to process delays or interruptions: if the transaction described by the arc does not take place, the whole process halts. A process diagram with many bridges usually describes a sequential or phased process. As processes with combined tasks and parallel tracks are preferable, a process diagram should contain as few bridges as possible. Those that remain should be strategically chosen: in the same way that a bridge in an access graph may disrupt pedestrian circulation but also presents opportunities for control, a bridge in a process diagram, even if unavoidable, should be coupled to actions that benefit the process and its management, e.g. synchronization of different aspects.