The following sections provide ranges for the level of effort required given characteristic levels of complexity. When applying these ranges, steer to the higher end of the range when dealing with high levels of uncertainty.

BPD development work includes the creation of BPD artifacts in Process Designer and all of the configuration of the swim lanes, milestones, events, and activities in each BPD. This work does not include the development work to implement the activities or events with human services, decision services, or other service development in Process Designer. The range in development effort (measured in man-days) required for BPDs of low, medium, and high complexity is illustrated in Table.

When estimating the overall complexity of a BPD, you need some level of detail as to the underlying complexity. Table 4-5 characterizes BPD complexity as a number of steps, decisions, events, and participant groups. The number of steps includes process milestones, subprocesses, and tasks. Decisions and events include any decision gateway or split on the process diagram.

Events include start/end events, message events, timer events, and exception events. It helps to assess the relationship between events, gateways, and steps in the process model to get an idea of the number of valid pathways through the process. Is there a clear happy path and few exception paths? Or are there several dozen paths and loops in the process diagram? The latter case might have a high degree of uncertainty or much process complexity and should be reflected in your estimate.

Coaches are the user interface windows that allow a human user to participate in a process. Coaches show process data (simple and complex variables) to users and accept input from the user. Users can enter data fields into coaches or act by clicking buttons or other web form controls. There are a number of factors that influence the complexity of a coach, including the relative number of data elements and number of actions a user can take on a coach (Table 4-6). Form field validation on the coach also influences the level of effort required to finish implementing a coach.

It often happens that data persistence and creation of a business data system of record (BSOR) is overlooked during early project estimates. Whether a BSOR is needed might not be known until more details are known. This topic is a good one to discuss during process discovery and should be accounted for in a budgetary estimate. Here are some questions that can help during the early phases of a project:

For many processes, there already is a system (or multiple systems) that are the “source of truth” for business data. Examples of business data might include customer records, invoices, and purchase orders. In our sample scenario, employee records are maintained in an “HR Database” that serves as the BSOR. For some processes, business data has no formal (or governed) system of record. The business data might exist in email, Excel files, or a shared drive. Asking a few questions early can help expose what might be a significant impact to the budgetary estimate.

• For each business entity identified in process discovery, where is that information stored today?
• If there is a BSOR, do other systems integrate with the BSOR today? If yes, how?
• Has there been mention of needing a “custom database” for business data?
• If we need to create a BSOR, do other systems need access to this data? The order of magnitude per BSOR is shown in Table.

Implementing a BPM solution typically requires integration with other systems within the enterprise (including LDAP, ERP, or other operational data stores). BPM provides a framework and tools that make these integrations as painless as possible.

In general, we plan 1 day per integration point and an additional 5 - 15 days per system.