Level 3 - Task Flow Diagrams

After defining business operations with Activity Flow Diagrams, the third, and final, level of detail in Creating the Process Definition Diagrams depicts Task Flow Diagrams. In effect, this third level, or Level 3 Diagram, depicts how the operations defined in Level 2 map into, or align to, the application or technology supporting the Process.

Of course, functional use is dependent upon selection of an application. In other words, the execution of a Task will differ depending upon whether the organization uses SAP, D365 or Oracle EBS, as examples. As a result, there is no point in attempting to derive Level 3 Diagrams until a supporting application or technology is chosen.

However, once the supporting Product or Service is known, it will guide many of the Steps to follow in order to execute individual Tasks. In many cases, a User's Guide, or similar Vendor-provided materials, describe how to execute available functionality to accomplish a specific Task. In fact, there may be multiple paths or alternatives available.

Conversely, there may be no delivered path at all. In this case, use Level 3 Diagrams to identify gaps between desired operations and delivered functionality. As a result, these diagrams may also indicate places where Reports, Customizations, Extensions, or other Objects may be appropriate resolutions to bridge such gaps.

Task Flow Diagrams - Level 3 (L3)

Basically, Level 3 Diagrams define additional detail for most Tasks within a parent Level 2 - Activity Flow Diagram. For each Task, a Task Flow Diagram defines, Step-by-Step, how desired business operations are to work in conjunction with the application or technology chosen to support the Process. Level 3 Diagrams provide even more Swim Lane detail, depicting Roles within Business Segments responsible for each Step. This level offers excellent opportunities to capture requirements, as participants work through available functionality.

Most importantly, this level defines the alignment of Steps within each Task to the related functionality available with the supporting COTS / SaaS application(s). In effect, this alignment provides the earliest preview of how the future-state Solution will look. Moreover, it also provides the most detailed definition of affected Objects, such as desired Integrations and Reports. As a result, Level 3 Diagrams lay the ground work to conclude Solution Strategy & Architecture, as well as to guide pending Solution Delivery.

On This Page

Add a header to begin generating the table of contents

Diagram Overview

Description

Firstly, a Task Flow Diagram (Level 3) depicts the alignment of a parent Task with delivered, available, or desired Solution functionality. Within a BPD, most Tasks on a Level 2 Diagram have a corresponding Level 3 Diagram that depicts Steps which occur within a single Task. In effect, each diagram maps an operation Task into the corresponding application or technology automating it. They also drive an appropriate level of requirements.

L3 diagrams show relevant manual & system actions, as well as Roles which execute them. Most importantly, L3s also provide the primary definition, or basis, for subsequent Solution Delivery. Building upon the technology agnostic Activity Flow Diagrams (Level 2) previously created, the intent of Task Flow Diagrams (Level 3) is to reflect specific design of the future-state solution.

Typically, L3s are based upon the functionality sequences available in, or dictated by, a Product or related technology. Ideally, that's 'how should it work out-of-the-box'? However, due to business reasons, they may also indicate some degree of extension or customization desired in the supporting technology. An important factor of Task Flow Diagrams is that they also introduce Product or technology terminology like menu selections, page titles, data structures, and component names. Ultimately, they should reflect business operating sequences that incorporate Product functionality.

L3s break down relevant L2 Tasks to a level of detail needed for subsequent system implementation. The detail should be such that individual Steps align to package functions where applicable - think menu selections, such as 'Customers > Accounts > New'. Steps should be high enough that they do not (re)create Operating Procedures, yet low enough to enable detailed requirements gathering and later Solution Delivery activities.

Not all Tasks identified on the L2 diagrams need a corresponding L3 diagram. The guidelines for determining when a Task diagram is required appear in 'Development & Use' below.

L3s use a Swim Lane format to identify the Roles performing each Step and to identify additional Entity integrations. Since each parent Task is constrained to a single owning Entity, the related Steps are confined to Role(s) within it. Recall from the L2 Diagram description that if multiple Entities perform the same Task, the Task for each is depicted separately in the L2 diagram. At L3, multiple swim-lanes may exist to depict interactions or multiple Roles within the given Org. This L2 Org + L3 Role combo provides inputs needed for later Release Planning, Change Management, and Training purposes.

L3s again show more detailed interactions between the Steps and Entities, and between the Steps themselves. Whereas L2 diagrams may indicate interactions between Entity Types, at Level 3 every interaction needs to be captured as an individual object. These interactions also provide more information than the L2 diagrams by identifying metrics and other attributes for each interaction.

Finally, L3s also highlight decision points that affect the determination of subsequent Steps, along with the criteria envisioned for each decision.

Purpose / Objectives

The Task Flow Diagrams (Level 3) serve a number of purposes:

Align L1 & L2 diagrams to existing, delivered or planned Solution capabilities and unique business requirements.
Drive requirements for all Solution Delivery dimensions:
– People & Organization;
– Process;
– Technology; and
– Information.
Graphically depict all the Steps within a given Task, along with their sequencing or relation to one another.
Define the flow(s) of information provided to, or received from, each Step, and between the Steps and other Tasks, Activities or Processes.
Identify the Role or Entity (Org) responsible for execution by placing each Step into an appropriate Swim Lane.
Identify the information that is exchanged between each Entity and the Step(s) with which it interacts.
Identify Integrations / Interfaces or data standardization opportunities.
Identify the specific files, reports, feeds, etc. that provide data to, or that generate data during, a depicted Step.
Identify decision points that determine whether, which, or in what sequence, Steps are executed.
Identify decision points that affect a change in organizational responsibility (i.e., organizational handoffs)
Provide a level of detail sufficient to deliver new Process, People & Organization and/or Info & Technology solutions.
Establish the baseline against which Fit/Gap Analysis, Object Identification (RICE), and Feature / Story refinement can be conducted as part of Analysis & Design activities.
Establish the framework to organize Process Dimension detailing to be continued during Build phase(s) (e.g., Operating Procedures and Policy & Procedure development).
Provide a scope and foundation for:
– Application Architecture;
– Security Architecture; and
– Technical Architecture
Provide a mechanism for communicating to, and facilitating discussions with, Business and/or IT SMEs.

Development Guidelines

Each Step depicted is given a Step ID in the format of ‘PP.AA.TT.SS’ to uniquely identify it.
Steps depicted are given a Name that reflects the Product, or application term for the action (where applicable). For example, reference specific menus, page names or access paths.
A L3 diagram is not required for each L2 Task. Only those Tasks to be addressed within the scope of subsequent Delivery work need an L3 depiction. Furthermore, for those Tasks in scope, only those that meet the 'Decomposition Criteria' (defined below) need L3 diagrams developed.
An L3 should depict all Steps related to the given Task, regardless of whether the Step is within scope or not. Steps deemed out of scope are identified by a Step ID of ‘PP.AA.TT.NA’. Additionally, these should be grayed out, but remain on the Task Flow Diagram (Level 3).
All material business decisions that occur during the Task are to be represented on the Task Flow Diagram (Level 3). These indicate potential business rules or application logic.
Interactions with other Processes, Activities or Tasks should be depicted on the Task Flow Diagram (Level 3) as an interaction between the Step shown and the external Process. Include a Note to identify a known, external Activity or Task within the depicted process.

Sample Diagram - Level 3 (L3)

For additional, more current information review the template diagram and included instructions available in the BPD: Templates section.

NOTE: Templates will soon be available for self-service. In the meantime, Contact Us with your request and we will provide a template via email.

Diagram Contents

A Task Flow Diagram captures and conveys the following items. In general, Field refers to a column with the corresponding Process Detailing Matrix, while Object refers to items appearing in the Process Diagrams. In short, these are two labels referring to the same items.

Subject	Field / Object	Notes / Guidance
Page Setup	Task Name	The Header identifies the Task being described. This should match the Name of parent L2 Task icon.
	Task ID	Also shown in the diagram Header. Again, should match the 'PP.AA.TT. value should match the ID of the parent L2 Task icon.
Actions	Actions	Action icons depict each Step at Level 3 that is in scope of the parent Task. Afterwards, actions define the New Solution Functions and scope of Business Processes to Deploy in the Solution's Application Approach.
	Step IDs	Each Step icon has a unique identifier. 'SS' represents the Step portion of each ‘PP.AA.TT.SS’ Step ID.
	Step Names	Each Step icon has a descriptive name. At Level 3, use Product or Service terms where applicable to foster alignment with corresponding application functions. Otherwise, use active terms for Step Names. For instance, 'Update Customer Address' rather than 'Customer Address Updated'.
	Task Start / End	May be one or more of: a) Events (Trigger / Terminator); b) a colored Related Process; and/or c) upstream / downstream Tasks defined within the same Process.
	Events	Event icons describe other Events that initiate (Trigger) or end (Terminator) a Step. They may also highlight notable milestones throughout a Task.
	Related Processes	Identify Related Processes with which the given Task interacts, precedes, or succeeds. If a specific Activity within the Related Process is known, then use a Note (see below) to allow for easier cross-reference.
Entities	Swim Lane(s)	Swim Lanes depict the Role(s) and Entities (Entity Types or Systems) responsible for executing depicted actions (Steps). Many L3 diagrams have just one Swim Lane. Others have several, including Roles in the Entity which owns the parent Task, or other Entities which only execute Steps depicted. Roles should reflect titles used within each Entity. Depict Entities which interact with Steps, but do not execute any Steps depicted, as Entity icons rather than Swim Lanes. Afterwards, use the defined Roles when planning Change Management and Training. Additionally, these Roles likely map to User Groups which appear in the Solution's Security Approach.
	Related Entities	Any Entity which appears in the Level 2 Diagram, and which owns or executes Steps depicted in the diagram should now appear as Swim Lanes (see above). Conversely, any Related Entities which interact with Steps, but which do not execute Steps depicted, still appear as Entity icons. This indicates that while such Entities interact with the Process, their actions are a black box from the owning Business Function's perspective. Use a single Entity icon to depict a single Entity of a given type, such as a specific 'Supplier'. Alternatively, use a multiple Entity icon to depict an Entity Type when multiple Entities of a given type apply, such as 'Suppliers'.
	Entity Interactions	Look to any connector crossing Swim Lanes, as well as any connector between an Entity icon and a Step, as Entity Interactions. For each Entity Interaction identified, determine whether an Integration, or interface, is applicable. Where applicable, ensure a Data In/Out icon (see below) appears along the relevant connector.
Interactions	Precedence or Dependence	Use Connector arrows to indicate the sequence of flow.
	Data In/Out	Data In/Out icons identify files, reports, messages, or other discrete data sets which a Step receives (In) or produces (Out). Where practical, depict individual Files, Reports, etc. as Data In/Out icons. Where not practical, depict more general Data In/Out Types and provide a Note or List to itemize the individual items within the type. Give each Data In/Out icon a descriptive label to identify individual data sets. For consistency and clarity, ensure the same label appears each time the same Object appears, whether on the same page, across all pages within the Process Definition, and across all pages in all Process Definitions for each Solution. Afterwards, each Data In/Out icon should map to an Integration that appears in the Solution's Integration Approach, or a Report that appears in the Reporting Approach.
	Objects	Object icons identify major repositories, key operational data, or other notable content and/or components in the supporting technology which a Step interacts with. Depict individual content or components as Object icons. Give each Object icon a unique name to identify individual content or component subjects. For consistency and clarity, ensure the same label appears each time the same Object appears, whether on the same page, across all pages within the Process Definition, and across all pages in all Process Definitions for each Solution. Afterwards, each Object icon should map to a Major Data Object that appears in the Solution's Application Approach. Additionally, some may identify operational or transactional data to bring forward from legacy systems, as defined by the Data Migration Approach.
	Business Rules	Decision icons represent both decisions which affect the flow of actions, as well as specific Business Rules.
	Notes & References	Use Notes to add color commentary, additional information, or references to other source materials on the diagram. For instance, Notes can provide consumers with a link or guidance to relevant Vendor documentation, such as User Guides. Similarly, they can direct readers to regulations or policies.

Diagram Development & Use

In most cases, a Business Analyst and corresponding Solution Analyst facilitate the creation or update of a Process Definition, including Task Flow Diagrams. However, they must do so in collaboration with the relevant Business / Process Owner and appropriate Subject Matter Experts. Ideally, other Team members participate and support Definition development.

To create the initial version, begin with the same file containing the Level 1 Process Flow Diagram and Level 2 Activity Flow Diagrams, which includes standardized page layouts and icons to use. Thereafter, add a diagram page for each new Task to define. Otherwise, to update a Definition for a subsequent Phase, use the most recent version from a preceding Phase. Thereafter, follow the steps below to create, or update Level 3 - Task Flow Diagrams.

Regardless of which Phase the artifact is for, completion of the current version occurs either prior to or during Phase Inception. As a result, it defines alignment of business operations to technology, personnel responsible for executing Steps, and individual Objects to enable or automate Tasks. Afterwards, Solution Strategy & Architecture use this information to conclude Solution Definition. Thereafter, this content becomes source material for several Solution Delivery activities.

Overview

Initially, the Level 1 and Level 2 diagrams helped organize participants. For instance, the Level 1 diagram defined the scope of each Process, and placed each Process in the context of other, Related Processes. Subsequently, the Level 2 diagrams described business operations and organizational responsibilities. At this point, it's time to align what a business wants to accomplish with the application(s) that will enable it to do so.

In this respect, a Task Flow Diagram is an effective tool with which to map planned business operations into supporting technology. Accordingly, a Level 3 Diagram for most Tasks will depict how an organization chooses to use their selected application. In doing so, they will facilitate further discussions, drive additional decisions, and align operational objectives with application functionality.

Unlike the higher-level diagrams, Level 3 Diagrams have constraints. For instance, if a Product's instructions say "Do A, then B, before C", participants are not free to change this to, for example "Do B, then C, then A". A good rule of thumb is "Never fight the Product architecture". If a Product is supposed to work a particular way, try to follow that path.

Timeline

Roughly speaking, expect production of each Level 3 Diagram to take 1/4 - 2 days, on average. That's not to say completion of each diagram takes up to two days. Rather, overall, a Process with 40 Tasks is likely to take 10 and 80 days to define its Level 3 Diagrams. Level 3 involves many decisions. Accordingly, strong and empowered Process Owners help minimize the time required. Familiarity with the technology also helps reduce the amount of time needed.

Of course, Steps for some Tasks come together quickly. In some cases, the chosen application prescribes them without any alternatives. Conversely, Steps for other Tasks may require more time. This may be due to functionality options and the need to produce some demos or Proofs of Concept (POCs) to show options for application use. Alternatively, potential functionality gaps or the number and type of applicable Business Rules may also require more time to map out a Task.

Moreover, creating these diagrams does not occur in order. For the most part, initial work begins on several diagrams at one time. Thereafter, workshops and interviews collect more information and questions to resolve in defining each Task. After each workshop, Teams compile info gathered and obtain decisions which they then use to produce the next version of each diagram. Furthermore, changes to one diagram often drive related changes to others. This cycle repeats until all Level 3 Diagrams are ready for review.

Those involved in BPD development are a subset of Solution Delivery participants. Accordingly, it is best to produce these diagrams prior to Solution Inception. During and after Inception, it is important that everyone have access to the completed diagrams, as they are instrumental in creating or updating the Solution Backlog as well as supporting subsequent Analysis & Design.

Solution Definition

Level 3 Diagrams are not required prior to Solution Selection. In fact, participants cannot create Task Flow Diagrams until after the core application is known.

As additional workshops are held with Business, IT, and perhaps Vendor stakeholders, use Task Flow Diagrams (Level 3) to facilitate discussions, evaluate alternatives, and drive decisions. These workshops should occur during the Elaborate stage of Portfolio Management. If a Portfolio Management process is not in use, then these workshops should occur immediately following the selection of any related application or technology.

Proper creation of Level 3 diagrams requires a Team. That is, a Business Analyst alone cannot produce the required results. At this point, the Solution Analyst may facilitate many of the workshops, with support from their corresponding Business Analyst and Test Analyst team members. Moreover, the Solution Analyst should rely upon application demonstrations and other means to both introduce participants to the available functionality, and to familiarize everyone with proper terminology and concepts.

Indeed, an important aspect of Level 3 diagrams is to facilitate stakeholder understanding of the future Solution. Accordingly, make Vendor materials such as User's Manuals, Architectural Diagrams, and other "propaganda" available to all participants. These items may come from both the software Vendor, as well as Implementation Partners who specialize in the software. As this point, encourage everyone to begin using Product-specific terms where appropriate. Doing so improves communication and helps avoid misunderstandings or miscommunications.

After Software Selection

For each Level 2 Task, use the following guidelines to determine if it requires further decomposition once the supporting Product is known.

Which Tasks Require a Level 3 Diagram?

Not all Tasks appearing on a Level 2 Diagram require further detail. Although, most do. To explain, develop a Task Flow Diagram (Level 3) for each Task shown in a Level 2 Diagram when one or more of the following criteria exist. Similarly, participants must also decompose any Step (on the same Level 3 diagram) if one or more of the following criteria exist. To clarify, do not create any type of 'Level 4' diagram to decompose a Step. Rather, split it into multiple Steps on this 3rd level.

Implementation Options

Criteria: The Task is within the scope of planned work.
Criteria: There are options, or alternatives, to implement the action item within the supporting Product Solution.

Reason: To specify which option, or alternative, to implement. If participants cannot reach a decision, then use a demo, or Proof of Concept (POC) (e.g., a Spike), to facilitate discussions and drive decisions.

Automated and Manual Actions

Criteria: There are both manual and automated aspects to the Task.

Reason: To reach a level of detail where each Level 3 Step is either manual or automated, not a combination of both. To clarify, working with a Product, or use of an application, is not a 'manual' action. Conversely, doing something without using an enabling technology is.

Additional Business Decisions

Criteria: The Task requires business decisions or other criteria within it.

Reason: To identify existing Business Rules, or the need for future Business Rules and/or application logic.

Multiple Roles

Criteria: The Task requires more than one Role to execute it

Reason: To reach a 1 – 1 Role / Step alignment that allows for Build, Test & Deployment planning (e.g., security considerations; target rollouts; user types, Change Management, training, etc.).

Entity or System Integration

Criteria: The Task involves Entity Integrations, or System Integrations, as either inputs or outputs.

Reason: To provide the necessary level of detail for identifying and estimating Objects to build.

Multiple Integrations

Criteria: More than one Integration / Interface exists for a given Entity- or System-Integration.

Reason: To provide the necessary level of detail for identifying and estimating the specific Objects to build.

Additional Data Details

Criteria: Output is described by Data Types rather than individual files, reports, feeds, etc.

Reason: To provide the necessary level of detail for identifying and estimating the Objects to be built.

Step 1 - Pages & Setup

To begin, the first step in producing Task Flow Diagrams is to provide locations for each diagram. For each Task appearing on a Level 2 Diagram, and which meets one or more of the criteria above, set up a new page within the BPD file.

To be clear, there is one page for each Task requiring a Level 3 Diagram. In effect, what appears on the page is a zoom-in of the parent Task. After creating each page, follow the remaining steps below.

Add a page / tab in the BPD Diagrams file for each Level 2 Task meeting any criteria above.
Place these pages / tabs immediately after the pages depicting the Activity Flow Diagrams.
Label each page / tab to indicate the level and Task ID the diagram depicts. For example, 'L3:PP.AA.TT', where PP is the two-character Process ID, AA is the two-digit Activity ID, and TT is the unique, two-digit sequence number from the parent Level 2 Diagram.
Update the Page Header to show 'Level 3 | [Task ID] [Task Name] Task Flow'.
Order Level 3 Pages by their Task ID. For instance, L3:AP.02.01, should appear after L3:AP.01.01 and L2:AP.01.02.

Ensuring that relevant Tasks are broken down on their own, dedicated page helps everyone understand where to place and locate relevant information. Indeed, the ITM Business Process Definition's one-page-per action structure offers a number of benefits. In short, it enables stakeholders to capture and convey relevant information in both summary and detailed form. Moving up or down in levels of detail helps everyone understand important aspects of each Process. Moreover, it allows for the right information to be conveyed at the right level, to the right audience.

For more information, refer to BPD Pro-Tips.

Step 2 - Actions

Secondly, the next step in producing Level 3 Diagrams is to depict all relevant actions. That is, determine the Steps needed to complete the Task.

Diagram Level Actions - Steps

The first actions to depict are those which further define of the parent Task. These actions, called Steps at Level 3, occur within the scope of each specific, parent Task. In the same way Activities define the scope of a Process at Level 1, and Tasks define the scope of each Activity at Level 2, here Steps define the scope of each Task at Level 3.

Moreover, the Steps define the technology which supports business operations in each Task. Accordingly, add an action icon for each Step. Give each Step a brief, descriptive, active name and, eventually, a unique ID. At this level, use Application or technology terms as defined and used by the software Vendor for Step names.

At this point, leave the ID until after the review of sequencing below. Identify actions by either validating predefined Steps or adding new Steps specific to each Task. To clarify, predefined Steps can often be found in places like existing User Guides, other Vendor materials, or in previously described Operating Procedures.

Related Actions

After adding Steps within an Task's scope, now add other, Related Actions to appear on a Task Flow Diagram. Related Actions include any immediately upstream and/or downstream Task and/or Process. Related Actions come in two flavors. Firstly, there are Related Actions that are also defined within the same Process Definition. Secondly, there are Related Actions defined in another, related Process Definition.

For Related Actions defined within the same Process Definition, use actions one level up for these off-page references. For example, since Steps are the level these diagrams depict, upstream / downstream actions defined within the same Process Definition should depict a Task. That is, at Level 3, Related Actions should not depict Steps which occur within other Tasks, but rather only the related Task itself.

Alternatively, use a Process icon to depict any Related Action defined in a different Process Definition. To clarify, it is always permissible to depict a Related Process at any level. Moreover, it is good practice to add a Note specifying which action (Activity, Task, etc.) to reference in the Related Process. Furthermore, color upstream Related Actions green, indicating a start on the page. Color downstream Related Actions red.

Related Actions provide context and continuity for Steps appearing on the page. To emphasize, depict only the immediately prior or next Related Action(s). In other words, avoid any further actions because the current diagram should not attempt to define anything beyond its parent Task's scope. Rather, these Related Action icons direct consumers to a corresponding definition where they may find additional detail.

Reference Notes

The reason Related Actions use levels above the detail depicted, Steps at this level, is to reinforce that these are off-page references. Furthermore, doing so discourages including detail on the current page which belongs elsewhere in a Definition. For anyone wanting more information, they should view the definition of the Related Action.

Note that Related Actions are bi-directional. That is, if a diagram indicates upstream or downstream transition to another action, that other action should also include a corresponding reference to the action depicted here.

Events

The final actions to consider are Events which begin or end actions. As with Related Actions above, Events occur before or after a Step. However, unlike Related Actions, BDP Diagrams generally do not attempt to depict anything beyond each Event. Although, it is common to depict an Entity or Data Object if they initiate or complete an Event. In effect, what occurs beyond these icons is a black box.

To explain, any Event which causes a Step to execute is known as a Trigger. In this case, something beyond the scope of the BPD occurs. As a result, some group in the organization acts by executing the Step which immediately follows the Trigger. For example, 'Customer Submits Request' might be a trigger which initiates an 'Receive Customer Request' Step.

Conversely, an Event which occurs following a Step is known as a Terminator. In this case, no further action occurs along the current path of the Process' scope. For instance, after executing Steps to address the Customer's Request, if the final Step is to 'Save Updated Request', perhaps the Process may then terminate with an 'End Request' Event.

To summarize, the primary difference between Events and Related Actions is whether there is further Process Definition to reference. When there is more definition, use a Related Action icon to direct the consumer to the proper off-page Definition location. When there is no further definition, use an Event icon to tell the consumer there is no further BPD information beyond the Event.

Step 3 - Entities

Thirdly, the next step in producing Level 3 Diagrams is to depict all relevant Entities. Accordingly, identify any Roles or Entities that interact with each Step.

To start, expect any Entity which interacts with the parent Task on Level 2 to interact with one or more Steps at Level 3. Furthermore, in looking at the more detailed Level 3 perspective, participants may often consider additional Entities initially overlooked at Level 2.

Gather data about individual Entities. If listing an Entity Type, such as 'Banks', then add a Note listing applicable Banks. Alternatively, use the Note to reference where such a list of applicable Banks is defined. Such information becomes relevant when defining scope and Features.

In general, there are two basic categories for Entities / Entity Types. Firstly, Entities which execute one or more Steps appear as a Swim Lane. Secondly, those which merely interact with the Process, but do not execute any depicted Step are Related Entities.

Swim Lanes

On Level 3 Diagrams, Swim Lanes identify the Role(s) responsible for executing individual Steps.

Action Owning Roles

At this point, the first Role(s) to consider are those which exist within the owning Entity, and which have responsibility to execute one or more Steps. Use Swim Lanes to represent the Roles which have such responsibility. Label each Swim Lane with the Name of the Role responsible for the execution of a Step. Then, place the Step(s) which the Role executes within the appropriate Swim Lane.

Generally, this is the second level at which the Business Segment that owns the Process has a Swim Lane. The parent Level 2 Diagram identified the Entity having responsibility for executing the parent Task. Accordingly, from the owning Organizational Unit responsible for the Task, obtain the Role(s) that will carry out the Steps within the Task. Ensure their Role Name(s) match Swim Lane(s) in each L3 diagram.

Aside from Roles within the owning Business Segment, Roles from other segments and/or Related Entities may also appear as Swim Lanes on this diagram. For instance, any Entity responsible for executing one or more Steps in the given Task should have its own Swim Lane. Accordingly, the Swim Lane label should match the name of the Entity / Entity Type, or a Role which that Entity specifies. Thereafter, each Step which the Entity / Entity Type executes should appear within this Swim Lane.

Action Executing Roles

At this point, many Entity Types should now appear as individual Entities, potentially with their own Swim Lane. Alternatively, constituency or organizational Entities may now identify individual Roles as their own Swim Lane. For instance, an Entity Type of "Help Desk" may segment into "Agent", "Admin" and "Manager" roles. The reason to segment Roles is to facilitate later training and roll out. Segment Roles in cases when introduction of the future-state Process may occur Role by Role, or when the Step(s) each Role executes somehow differ. Otherwise, if Step execution is the same regardless of individual Roles, it is better to simply continue using the Entity, rather than Roles within it.

Of course, do not create Swim Lanes for any Entity/Type not appearing on the Level 2 Diagram. Similarly, do not create Swim Lanes for Entity/Types that do not execute any Steps in the given Task. Additionally, do not create Swim Lanes for Roles whose actions occur external to the Process being defined. For instance, if a customer provides a photo to a Step, but does not execute any depicted Step themselves, they should appear as an Entity icon, not a Swim Lane. In other words, if what happens within the Entity is a black box from the BPD's perspective, do not give it a Swim Lane. Finally, do not depict any System supporting the Process as a Swim Lane. Rather, Swim Lanes only depict Roles or groups to which they belong.

Swim Lane Relevance

An important aspect of Swim Lanes is that they are relevant only to the action(s) appearing within them. To explain, all other icons on the diagram may be placed anywhere on the page, without regard for the Swim Lane in which it appears.

In other words, the appearance of a Step within a Swim Lane indicates that the Role named in the Swim Lane's label is responsible for executing each Step depicted. However, the appearance of a Data Object or Entity in the Swim Lane is not similarly associated with the Role or parent organization. Rather, any non-action icons are merely taking up page real estate that happens to be within any of Swim Lanes on the page.

Related Entities

The second Entity or Entity Types to consider are those which interact with the Process by exchanging information. Exchanges involve any Entity providing or receiving information (or both). To continue with the Customer example above, the photo they provide is one example of an information exchange. Moreover, because the Customer's actions prior to providing the photo are not in Process scope, the 'Customer' is a Related Entity.

Information exchanges typically involve files, messages, reports, or personal interactions. Look to Data Objects in Step 4 below for more information on files, messages, and reports. Personal interactions simply refer to a User who enters or views information via computer, kiosk, or another device.

Of course, any Entity or Entity Type is a potential provider or recipient of such information. In other words, any Organization, Constituency and/or System is a potential Related Entity. If the Entity / Entity Type is singular. such as a Bank, then use a Single Entity icon. Conversely, if there are (or could be) multiple Entities / Type, such as several Banks, then use a Multiple Entity icon.

Step 4 - Interactions

Fourthly, add line(s) to connect objects on the page representing interactions. When appropriate, add Data Objects and/or Business Rules to clarify interactions.

Action Sequence / Flow

Use connectors, or line(s), to depict the sequence of objects on the page. The initial connectors to add indicate the permissible sequencing, or flow, of Steps. Convention is to use an arrow to connect two icons, with the arrow's head indicating the direction of the flow.

All pages should begin from either:

an upstream, preceding action
(an off-page reference).
an Entity, Data In/Out, or Object icon; and/or
some other type of Trigger Event.

Similarly, all pages should conclude to either:

a downstream, subsequent action
(another off-page reference).
an Entity, Data In/Out, or Object icon; and/or
some other type of Termination Event.

Between each page's start(s) and end(s) is the series of Steps which may occur within the parent Task. Of course, the order of depicted Steps affects the number and length of lines to use. Ideally, order Steps to make the diagram easily readable for consumers.

Give connectors a meaningful label or use Notes to provide a brief description of the information each interaction conveys. Again, the intent is to encourage discussions about each interaction, and to capture the flow of information, sequence of responsibilities, and any dependencies that exist. Afterwards, to then communicate relevant information to consumers.

Data Objects

In most cases, interactions imply hands-on application work or system actions which occur within the Process. As a result, there is nothing additional to note within the BPD. Alternatively, some interactions may imply the exchange of a file, message, or report. In these cases, use a Data In/Out icon to depict each discrete data set. Similarly, if key info is stored in, or retrieved from, some repository, then use an Object icon to depict the data store.

At this point, Level 3 Diagrams should depict Data rather than Data Types. For instance, Data In/Out icons to depict 'Balance Sheet', 'Income Statement' and 'Cash Flow Statement' are the appropriate level of detail. Depicting a 'Financial Statements' Data In/Out Type icon does not provide the ideal level of detail. Conversely, there are only Objects, no Object Types. A rule of thumb is to not over crowd or clutter a diagram. If space permits, show the individual elements. Otherwise, use one icon plus a Note to list the details the icon represents.

Basically, use the Single Data In/Out icon when a single data set occurs each cycle. Alternatively, use the Multiple Data In/Out icon when multiple data sets occur each cycle. For instance, use a Single Data icon to depict receipt of a monthly Bank Statement. Conversely, use the Multiple Data icon to depict receipt of Employee timesheets each week. That is, a multiple icon indicates numerous instances of a specific data set. Use the same approach for Object icons.

Unique Object Identifiers

Give each Data In/Out and Object icon a short but descriptive name. Try to use the same terms as the corresponding technology. That is, if the application calls it a "Customer Master File", then do not use "Customers" as the label. Part of the purpose here is to introduce the proper terminology to stakeholders. If this affects objects in the parent Level 2 Diagram, then so be it. Make the updates.

At this point, the form and format of data sets and stores is irrelevant. Rather, it is merely their identification which is relevant. As a result, there is only one type of Data In/Out icon to represent all data set types. Similarly, one Object icon for all potential stores, whether those are files, tables, or other medium. Of course, ensure the same object has the same name on every page on which it appears.

Business Rules

Workshop discussions and interaction evaluations identify, or validate, decision points along with high-level decision criteria. For instance, some decisions affect which Step(s) occurs next. Alternatively, some determine whether the Process continues or terminates. Regardless, depict relevant decisions on Level 3 Diagrams using Decision icons.

Give each icon a name unique to the page. Ideally, phrase the name in the form of a short, basic question, which frames the decision. Afterwards, label each exit path with one potential answer to the preceding question. Afterwards, if referencing these decisions in other ITM artifacts, use the Page ID (in this case the Task ID) along with the question posed.

Depicting Outcomes

Decisions always have at least two possible outcomes; some have many more. For instance, many decisions have simple 'Yes' / 'No' outcomes. In other cases, an "Approval to Proceed?" decision may have outputs of 'Yes', 'No, minor re-work needed' and 'No, major re-work needed'. If there are more than three potential outcomes, then a decision requires a series of outcomes.

Since three (3) is the exit limit from a single Decision icon, there are two basic ways to depict more complex outcomes. Firstly, cascade several related decisions. Basically, this is like a series of If / Then statements, where output of one decision leads to input of the next. Secondly, depict an exit offering multiple paths to different downstream objects. In effect, this is like a Case statement.

For example, a decision which selects from a list of alternatives may depict each option as its own decision, with outcomes either indicating 'Yes' to that option, or 'No' and on to the next option (If / Then form). Similarly, use a series of decisions to narrow down alternatives until only three or fewer outcomes may occur from each decision.

Alternatively, a decision which selects from a menu with six (6) possible choices may depict all choices exiting from the same point of the Decision icon. In this case, six connectors each have a label representing one menu item selection as the outcome, before connecting to the next appropriate task (Case statement form).

Portfolio Management Check Point

To this point, the objective of Task Flow Diagrams is to identify and align the chosen applications or technologies that will support desired business operations. In short, the diagrams should define, Task by Task, who will do what and when. As a result, the initial Task Flow Diagrams (Level 2) created during Elaborate become the first iteration of Solution Design.

Workshops and reviews involving Business, IT, and perhaps Vendor representatives, produce an effective design of the future state. To be sure, the intent is not to produce the most detailed design, nor to identify all requirements. Rather, it is to provide a solid framework from which participants can break down and prioritize implementation work into actionable Features and Stories.

After using the diagrams to identify Business Features, subsequent Feature Planning and Story Analysis will reference these diagrams to guide the most detailed designs. Indeed, practically all content from these diagrams will migrate into the functional and technical specifications which Features and Stories represent. Furthermore, they will contribute to the initial set of Acceptance Criteria, or requirements, which accompany each Feature and Story.

Seek Communications Clarity

Basically, diagrams should depict the potential flow(s) of work. The action flow validates the dependencies, or sequencing, of all Steps as well as decisions in the diagram. Accordingly, the outcome of decisions introduces various alternatives for sequences to branch off in any number of directions. In some cases, the flow of a Task will be serial, meaning there is only one action to occur next. Alternatively, the flow may occur in parallel, meaning two or more actions may follow a prior one.

In working through the additional detail of Level 3 Diagrams, it is not uncommon for the addition of Steps, Entities, Data Objects, and decisions to make the diagram too convoluted, or complex. If that is the case, then consider splitting the parent Task into two or more smaller Tasks. If this occurs, clone the overly complex page to create a page for each new Task. Then, remove some content from each, leaving the remaining content to define the Task. For more info, look to guidance on validating diagrams.

Thereafter, the validated L3 Diagrams, along with any relevant COTS / SaaS / Vendor processing information, User Guides, instructions, or other materials, provide the context and guidance for the development of Features and Stories. Of course, Task Flow Diagrams (Level 3) may require further updates based on changes which occur after initial Solution Definition. If this happens, then update the diagrams during preparation for any subsequent Solution Phase.

Inputs to Other Artifacts

Upon completion of draft Task Flow Diagrams begin compiling the corresponding Process Detailing Matrix. In most cases, this indicates the end of the top-down decomposition portion of Process Design. That is, the final act in driving from Level 1 down through Level 3. Once the Detailing Matrix is complete, review its contents to ensure the diagrams accurately represent the Process details, and vice versa.

At this point, it is time to start verifying diagram contents and working towards sign-off of BPDs for the pending Solution Phase. Accordingly, before presenting the final diagrams for review and sign-off, work through Validating Process Definitions. Indeed, validation guides the bottom-up validation portion which completes Process Definition. In most cases, subsequent diagram edits, and validations, may continue until finalized during Phase Inception. Concurrently, ensure the Requirements Matrix is complete, accurate, and correctly aligns to references within both the Process Diagrams and Process Detailing Matrix.

Upon completing these activities, the organization should now have sufficient detail to successfully produce Solution Strategy & Architecture materials as well as other Solution Definition artifact including a Business Case and Fit / Gap Analysis (see next). Furthermore, the BPD materials provide an excellent start for subsequent Solution Delivery activities.

Fit / Gap

Where the Product supports each Task and Step to the satisfaction of the organization, that is said to be a "fit". Where the Product does not support a Task or Step to the organization's satisfaction, that is called a "gap". In other words, there is something missing between what the Product can do, and what the organization wants it to do. Any gap requires some form of mitigation to close it, and the corresponding costs should factor into the Solution's overall resource estimates. In general, there are three ways to address gaps.

Manage Expectations

Firstly, the easiest way to close a gap is to change the organization's expectations to match the functional capabilities of the Product. Simply removing the "want" that is not met, removes the gap. For instance, just because a legacy system used to do this or that, does not necessarily mean that a new system must do the same. Get to the business reasons why something must exist. Upon closer scrutiny, it is often the case that a "must have" is not a requirement at all. Properly managing expectations is the quickest, easiest, and most cost-effective means to close gaps.

Customizations or Extensions

Secondly, if an organization must have some functionality that is unavailable, it may choose to modify the delivered Product and/or the defined Process. For instance, a 'Customization' involves changing an object which the Vendor provides. For example, modifying a script, report or program. Alternatively, an 'Extension' involves creating a new object(s) which the Vendor does not provide. Both options involve analysis & design, development, testing, and ongoing maintenance. Each incurs costs and takes time. Accordingly, careful evaluation should assess whether the costs of any given Customization or Extension outweigh the benefits. If they do, then it is better to not make such a change.

Phase Inception

Producing Task Flow Diagrams cannot begin until the organization selects the application, or Product, they plan to use in support of their Business Process. Thereafter, Teams can develop Level 3 Diagrams to align business operations to application functionality. In many cases, the alignment of application functionality (Level 3) to business operations (Level 2) drives additional updates to the Level 2 - Activity Flow Diagrams.

Initial production of Level 3 Diagrams occurs prior to Phase Inception, which marks the transition from Solution Definition on to Solution Delivery. Although, the diagrams entering Inception may be drafts. If signed-off versions are complete, then that's even better. Regardless, one of the first actions to take during Phase Inception if to finalize all diagrams for the pending Phase, and to then review each in scope for the Phase with Solution Delivery participants.

L3 Diagrams become the source for updating the parent L2 Diagram. The intent of such updates is to ensure alignment and consistency between levels. Moreover, each diagram becomes an artifact upon which to base pending Phase scope. To explain, BPDs support Epic objectives. Similarly, they are a source for Business Features in the Solution Backlog to achieve the stated objectives. Furthermore, they provide a foundation upon which to produce the Solution's Conceptual Solution Design.

Step 1 - Actions

Firstly, validate the major Steps within scope of both Process and Phase scope. At this time, edit or remove any as warranted. Leave Steps in-scope for the next Phase as is. Conversely, shade any Steps not in-scope, grey. This conveys to all that work on non-shaded Steps is authorized for the current Phase, while further work on the greyed-out Steps is not. If a previously greyed-out Step is now in-scope, then remove the shading, to indicate work on the Step may now occur.

This is also the time to ensure each Step has a unique ID and that sequencing of Steps on each page roughly flow in order. Of course, over time changes may accrue which add or remove Steps, affecting the sequential order. In general, after Steps on a diagram pass through Inception, making any changes to their Step IDs becomes a potentially heavy lift. Basically, it depends upon how many artifacts reference the IDs, as any changes to a Step ID warrants similar changes to any artifact(s) which reference it.

In general, implementations should never add new Steps during Solution Delivery. Instead, any addition should occur during a subsequent Solution Definition cycle. However, if it must happen, then coordinate with the Solution Manager and/or Project Manager, along with the Process Owner, Epic Owner, and other key stakeholders to resolve potential scope, SOW, or resources issues.

Step 2 - Entities

Secondly, finalize the Entities and/or Entity Types to ensure they accurately reflect Step interactions. Revisit each interaction to confirm the information, decisions, changes in ownership, and other potentially relevant attributes. Afterwards, ensure alignment with Entities depicted on the parent Level 2 Diagram.

As with Steps, shade an Entity / Type grey if it is out-of-scope for the pending Phase. This conveys to all that further discussion of items which relate to such Entities is not appropriate during the Solution Delivery phase. Those discussions may occur prior to some future Phase when the Entity(ies) become in-scope.

Making such decisions at this point saves significant amounts of time and effort. Indeed, in many initiatives, some individuals seek to delay progress (whether knowingly or not), by insisting upon discussions and analysis wholly unrelated to the objectives at hand. For others, it is an attempt to bring into scope what was previously deemed out-of-scope.

Similarly, note and shade grey the reference in the corresponding Requirements Matrix. If a previously greyed-out Entity / Type will now be in-scope, then remove the shading to indicate further work related to such Entities may now occur.

Step 3 - Interactions

Thirdly, finalize the relationships among Steps, Entity / Types, and other items on the page. In many cases, sequencing is not linear. However, if one Step is dependent upon another, the independent action must have implementation priority. In other words, action sequencing determines implementation priority.

Additionally, if depicting them at this level, then finalize any Data Objects that feed into specific Steps. Similarly, finalize any Data Objects each Step produces. Keep in mind, at this level Data Objects, such as files and reports are sought, rather than the more generic Data Types. Although, it is fine to use a Data Type along with a Note specifying the individual objects it represents. Also review any Business Decisions which the diagram depicts.

In all cases, ensure alignment and consistency with Level 2 Diagrams. For instance, a Data Object appearing at Level 3 should have a corresponding Object or Data Type on Level 2. If the parent diagram becomes too crowded, it is fine to lose some detail at Level 2, if the Level 3 Diagrams contain the proper information. Although, Business Decisions may appear at a single level, without any corresponding depiction on other levels.

Step 4 - Notes & References

Finally, look for opportunities to add clarity to the diagram. Use Notes to label connectors between icons, offering a brief description of info exchanged. Similarly, use Notes to convey related information relevant to interactions, decisions, or icons.

Recognize that the icons shown depict standardized values - Names, IDs, etc. Use these values as reference keys for various Solution tools, deliverables, and other artifacts. Accordingly, avoid modifying Step names or Step IDs after Solution Delivery begins. Changes can be made. However, corresponding changes throughout the Process Definition, as well as all related artifacts must also occur. Follow a Change Control process to ensure all relevant changes are made.

Step 5 - Conclude Solution Definition

After finalizing all diagrams, ensure alignment with related Solution Strategy & Architecture materials. Just because something appears in the diagram does not mean it will be built. Recall, a BPD describes the future-state of the Process. Of course, reaching any future-state need not occur in a single increment.

In fact, most organizations achieve future-state over several long-term increments. Accordingly, the next Phase of work may seek to implement only portions of the eventual, future-state. Enough to be useful, but not so much as to become overwhelming. Indeed, there are several reasons why the depiction of a Level 3 Diagram may differ from what an initiative plans to deliver next.

For instance, some Steps may already exist in their desired state. Alternatively, something upon which a Task or Step depends may not be ready. Or perhaps it's simply not a priority at this time. Regardless of what is in-scope for the next Phase, the Task Flow Diagrams (Level 3) should represent the desired future-state for each Task, not some interim, next-state.

Solution Delivery

After their use in Solution Definition, Task Flow Diagrams continue to be a source of reference throughout Solution Delivery.

Iterative Planning

In any Iterative Planning cycle, each Process aligns to a single Solution Epic. For each Epic in-scope for the current Solution Phase, the Level 3 Diagrams offer the most detailed definition from which to determine which action(s), or Steps, the pending implementation is to focus upon.

Consistent with an iterative approach, it is rarely the objective to implement an entire Process during a single Phase. Rather, it is best to focus upon enabling some portion(s) now, with the intent of returning to add incremental improvements after receiving user feedback on previously enabled functionality.

Depending upon the scope and scale of individual Tasks, the Level 3 Diagrams may be the appropriate level at which to define Business Features. If so, then a single Step, or set of Step, should have a unique Feature. However, it is important to complete each Feature prior to concluding the Solution Phase.

Note that does not mean all potential functionality for a Step must be complete prior to Phase end. In many respects, that would defeat the philosophy of MVP. However, if an acceptable Step cannot be delivered within a single Phase, then something is wrong with the corresponding Feature definition. Completing Features matters; completing all potential work related to a given action need not matter.

Iterative Implementation

After defining the appropriate action(s) at which to segment each Epic into Features, subsequent Iterative Implementation for the pending Phase begins. The first Implementation Task to undertake is Feature Planning. The primary step within this task involves Analysis & Design of each in-scope Feature. Basically, this involves determining the 'Business Value' each Feature should enable. In other words, each Business Feature describes some increment of 'what does the Business want'.

Features must align to either a Step, a set of Steps appearing on a single BPD diagram, or to some larger, parent action such as a Task or an Activity. For the most part, single Steps are often too small for defining individual Features. Although, it is possible, and permissible, for a single Step to be an appropriate level of 'Business Value' scope. Moreover, there are also other means by which to segment such work.

For example, it is possible, in fact recommended, to enable Steps for just a single Business Segment. Afterwards, Teams may use subsequent Features to enable other Business Segments. While revisiting an earlier implementation, they may also incorporate feedback received from early adopters. This offers opportunities to both extend functionality to new segments of the business, while also incorporating improvements identified by those already using existing functionality.

Business Value Increments

To begin determining increments of 'Business Value', look to the BPD for all actions within a Feature's scope. Indeed, it is important to keep individual Feature scope as clean and clear as possible. In most cases, this means setting scope at points which connect various icons. That is, use the connectors which appear on the diagram to identify where scope of one Feature ends, and scope of another Feature begins.

To explain, that does not imply that each diagram connector, or interaction line, is a scope boundary. Rather, only that scope definition of some Business Value increment should pass only through connectors, and not through actions, Entities or Data Objects. For example, if looking at any single BPD page, one should be able to draw a line which encompasses the action(s) within a Feature's scope. That line may encompass one or more actions. Specifically, it should only encompass sequential actions, or a set of actions whose series is not interrupted by some other Feature. Moreover, the line should pass only through connectors which link the in-scope action(s) to other actions, Entities or Data Objects.

Feature Scope & BPD Diagrams

To clarify, this connector delineation of Feature scope applies to a single BPD diagram. There is no circumstance where one Feature's scope should include some actions from one diagram and some actions from another. Rather, it must include one or more actions at the current level.

To put it another way, an action is either in-scope, or not. That is, an entire action at a given level - in this case, a Step at Level 3 - defines Feature scope. Of course, a set of actions may also define a Feature's scope. Conversely, if all actions on a page are in-scope, then it is better to use the parent action on the higher-level diagram to define a Feature's scope.

For example, when determining a Feature's scope using Level 3, it may appear as if such scope bisects the Level 2 Task. No worries: this is fine. Any Feature's scope needs only appear on any single BPD page. It is implied that any lower-level definition of the action(s) falls within such scope. To reiterate, a Feature's scope definition has no implication for any higher-level action(s).

Minimum Viable Product

When setting each Feature's scope it is important that stakeholders understand the concept of Minimum Viable Product (MVP) as it pertains to packaged software. Overall, the scope of work defined for any single Solution Phase represents a Minimum Marketable Product (MMP) or Minimum Loveable Product (MLP). Conversely, each defined Feature's scope represents an increment of Minimum Viable Product (MVP). In other words, many individual MVP increments accrue towards a broader, overall MLP.

Accordingly, this is why it is important to select one or more actions directly related to one another. If one were to try defining a Feature using several actions, or portions thereof, scattered across a BPD Diagram yet not in series or sequence to each other, then one is not defining something that is MVP. Certainly, they may define some increment of functionality. However, it is highly unlikely that such an increment would lead to an increment of a viable product.

Iterative Testing

The final aspect of Solution Delivery which Process Flow Diagrams support is Iterative Testing. Indeed, diagrams convey a substantial amount of information which a Test Analyst, QA member, or other participant designing tests, can use to both plan and develop the Test Scripts, Test Cases, and Test Scenarios that will validate each Business Value increment.

Next up is a short review of how to validate BPD diagram contents.