This article is the second in a series of three articles focused on the Macro Design phase for IBM Workflow projects. Part 1 of this series introduced the Macro Design phase, what it is and when to include the phase in an IBM Automation project. This article focuses on how the Macro Design phase is executed, including the participating roles, the activities, and expected schedules. Part 3 of this series will describe the deliverables that are created during the Macro Design phase.

The target audience for this article series is both business-oriented roles, such as project executives, project managers, and business analysts, as well as technical roles, including solution architects, integration architects, and technical leads from the project delivery organization. In addition, subject matter experts from an enterprise’s business lines of service, who are typically involved in software development projects, may also benefit from reading this series.

If you are new to the IBM Automation Platform for Digital Business, visit the IBM site for a brief introduction: Gain efficiencies and agility with business process management. For IBM Workflow related methodology publications, please see the Related Materials appendix at the end of this article.

The outcome of a Macro Design project is that design and project management decisions are in place for the solution implementation to start immediately following the Macro Design. This article describes the activities performed to arrive at those design and project management decisions and the skills and techniques required to implement them.


Macro Design is executed by a combination of methodology and tool experts working with the subject matter experts (SMEs) representing the business and technology needs for the project. The core methodology and tool experts are full time members of the project, potentially staffed from a Business Improvement Center of Excellence (CoE) organization. These experts lead the Macro Design project from a technical perspective and are responsible for producing the final deliverables, with input from the project SMEs. Additional specialist resources may join the project for shorter durations, as required. Each resource on the team can play multiple roles. For example, a Solution Architect may be an expert in Integrations, so the architect can be responsible for this area specifically, as well as the overall solution. Table 1 describes the core roles responsible for conducting and delivering the Macro Design.

Table 1: Core Macro Design Team Roles.
*as required

The business sponsor is ultimately accountable for the overall project. The sponsor provides business leadership in the form of the business direction and decisions. The SMEs representing business and technology needs for the project are usually staffed from the Line(s) of Business (LoB) sponsoring the project. The SMEs need to dedicate approximately half of their time to the Macro Design project and are responsible for providing input to and validation of the final deliverables. Table 2 describes the additional roles that need to be involved for a successful Macro Design.

Table 2: Project Macro Design Team Roles.
*as required

The business and technical resources work to understand the current state and gather the requirements and design various components of the solution in parallel: Architecture, Process (including Tasks and Cases), Decisions, Data, Integrations, and Infrastructure. Although these workstreams are worked in parallel, they are not independent, but require regular touchpoint and interaction due to their interdependencies.


A successfully executed Macro Design, in which full value as a distinct project can be realized, should follow four key phases:

  • Requirements.
  • Design.
  • Validation.
  • Planning.

Figure 1: High-Level Process Transformation Maturity Model.

Each activity is equally important in the Macro Design; there are no optional phases. The proposed sequence should be followed, as each activity is strategically designed to build off the activities that precede it. A collaborative workshop approach is used for each activity, facilitated by IBM Blueworks Live.

Throughout Macro Design and the execution of each of the four activity phases, there are three key milestones which each end in a formal Playback:

  • As-Is Playback.
  • Draft Playback.
  • Final Playback.

Proper participation amongst required roles is important for each phase and milestone. Figure 2 outlines each role’s involvement within and across the Macro Design phases.

Figure 2: Role to Phase Mapping.

Automation project characteristics will determine which Domain Architect(s) (Workflow, Decision, Integration, and/or Cloud) are required. Additionally, the Application Developer, Application Administrator, and Data Architect participate on an as required basis throughout each phase.

As with other design sessions, or collaborative workshops, a key component to the likelihood of success is good preparation. Macro Design preparation, usually 1-2 days in duration and conducted prior to the start of the Macro Design project, includes the following activities:

  • Verify business sponsor has been identified.
  • Verify business case has been approved.
  • Reserve time with key resources for collaborative workshops based on schedule and staffing.
  • Review preceding materials, such as:
    • Discovery Workshop Findings.
    • Preliminary Architectural Diagrams.
    • Technical Artifact Inventory.
    • ROM or Budgetary Estimates.
    • Proposed Schedule and Staffing.
  • Review templates and artifacts crafted from previous projects.
  • Identify critical business components, gaps and issues, if available, for discussion during proceeding activities.
  • Identify critical technical components, gaps and risks, if available, for discussion during proceeding activities.
  • Prepare agenda for the Requirements phase.

Some business process automation projects build off previous projects and established standards, while others act as the pioneer to transformation. When previous materials exist, they should be leveraged during Macro Design preparation to ensure consistent principles and methods are followed. This will prevent the duplication of information, while ensuring Macro Design satisfies both depth and breadth analysis, minimizing gaps, risks, and unknowns. This is important to achieve the 65% to 80% accurate estimates. Should this Macro Design focus on a vanguard process, these items will be addressed in the proceeding four activities, and once captured, can be used as templates in the future.


The Requirements phase sets the foundation for Macro Design execution, while also formulating the solution architecture and design. Within the Requirements phase, usually 1-2 weeks in duration, the following activities take place:

  • Discover As-Is processes:
    • Happy path.
    • SIPOC (suppliers, inputs, process, outputs, and customers).
    • Systems.
    • Exception scenarios.
  • Document Strategic Goals and Objectives.
  • Define critical success factors.
  • Discover and quantify pain points.
  • Review process and system documentation.
  • Assess non-functional requirements (NFRs).
  • Review development approach and needs.
  • Prepare agenda for first week of Design phase.

The requirements phase focuses on the As-Is process. This is a crucial step for many reasons: to gain trusted understanding of business processes, to identify pain points, to define critical success factors, to gather requirements, and to set a foundation for how to improve. Skipping this step will compromise the value of the To-Be process and overall transformation. There will be no benchmark to validate against, making it challenging to evaluate value and success. Even if the As-Is process was previously discussed in a preceding activity, such as a Discovery Workshop, it is important to go through this exercise.

Reviewing and validating is different from redoing and duplicating. Do not be afraid of revisiting. In fact, it is strongly encouraged to go through the As-Is process multiple times during the collaborative workshop. End each day of the workshop at a natural breaking point, then start the next day with a review and informal playback. Throughout the course of each day, or between days, participants will remember and contribute more, so taking multiple passes through the process, each with a slightly different focus, is a recommended approach.

Figure 3: Process refinement by iteration.

Another important component to the requirements phase and capturing the As-Is process, is collecting NFRs. Too often NFRs are forgotten or delayed, impacting implementation, delivery, and the project timeline. The earlier NFRs are identified, the better, so the team can plan and design accordingly.

At the conclusion of the Requirements activity phase, the first milestone is achieved by delivering the As-Is Playback. This is the baseline Playback that focuses on the discovered As-Is Process.


Once requirements have been captured and the As-Is process discovered, the team can begin constructing the To-Be process and future state design for process transformation and automation. Within the Design phase, usually 1-4 weeks in duration, the following activities take place:

  • Design To-Be Process Maps in IBM Blueworks Live.
    • Happy path.
    • SIPOC.
    • Systems.
    • Exception scenarios.
  • Document User Stories in IBM Blueworks Live.
  • Capture User Interface (UI) requirements.
  • Capture integration points requirements.
  • Define data model.
  • Elaborate Architecture Decisions (ADs).
  • Address NFRs.
  • Analyze interfaces.
  • Analyze interactions with the System(s) of Record.
  • Gather reporting requirements.
  • Prepare agenda for first week of Validation phase.

Although the business leads this activity, including technical resources is also imperative so they too understand the design and To-Be process. It is essential that the workshops and sessions during design, like other activities, are business led and IT supported. The business requirements and needs to transform the business process should be discussed, elaborated, and documented. When a requirement or design choice comes up that IT finds challenging or difficult, it is okay to question the purpose and value of the requirement and collaboratively work together, but IT should not be setting the requirements and design during Macro Design based on technical complexity. Business requirements and identified user stories, especially those determined to be technically complex, will need to be prioritized by business and technically reviewed by IT.

Remember, not everything identified during Macro Design has to be included in the first release; a requirements and user story road map should be created for future improvements. The continuous communication and feedback, both during Macro Design and implementation is key in making these compromises and agreements on what is best and most valuable for the overall process and business.

The Project Manager and/or Business SMEs must be authorized and capable of making business decision during the design phase. Not every decision has to be made immediately in the collaborative sessions, as some may need to be evaluated offline, but a representative with decision making authority is key to capturing requirements and design. It will quickly become too difficult to progress forward with Macro Design and into implementation if decision makers are not present and active in designing and transforming business processes.

While it is critical to uncover as much as possible to better plan and prepare for delivery, do not over design or over engineer. There are some things that cannot be solutioned until development beings. Proofs of technology, or proofs of concepts can quickly validate the design, but extensive custom coding should not be included in Macro Design. Mitigate risk and uncertainty by capturing requirements, an architectural landscape to satisfy those requirements, and a design to provide a valuable solution, but maintain an agile approach to iteratively design, develop and deliver. Excessive designing and documenting during Macro Design has a low return on investment in which risks and uncertainties are not reduced given the resources and time invested. Achieve a level of design that can produce 65% to 80% accurate estimates and leverage iterative agile delivery to refine estimates and allow optimal velocity during implementation.

Lastly, follow best practices for User Story authoring, as described in section 10.1 of the IBM Redbook Process Discovery Best Practices Using IBM Blueworks Live.

At the conclusion of the Design phase, the second milestone is achieved by delivering the Draft Playback. This Playback focuses on the draft design of the To-Be process. It is an interim Playback where feedback on the design is expected and encouraged.


To keep all participants, especially business sponsors and stakeholders, involved in the effort, validating requirements and design is critical to facilitate valuable feedback and gain a common understanding. Within the Validation phase, usually 1-3 weeks in duration to refine the design, the following activities take place:

  • Validate and update detailed process & user stories.
  • Validate and update monitoring requirements.
  • Validate user interface (UI) requirements.
  • Validate integration points.
  • Refine data model.
  • Validate architecture decisions.
  • Validate delivery methodology.
  • Initiate planning and estimation.
  • Prioritize user stories and assign story points.
  • Define user story acceptance criteria.
  • Prepare agenda for Planning phase.

This iterative approach to validate requirements and designs gathered from the two previous phases is valuable because it confirms a shared understanding, uncovers new points to be discussed in proceeding activities, and allows the team to incorporate feedback that provides acknowledgement and agreement.

During this phase, it is also important to confirm the delivery methodology to be utilized during implementation, because the delivery approach directly impacts development capacity and velocity, as well as the purpose of the Planning phase of the Macro Design. If an agile, iterative delivery approach will be used, the duration of each iteration and the required activities within an iteration, such as iteration planning, Playback, Retrospective, daily scrum, weekly deployment and capacity analysis, will be identified to schedule, staff and plan accordingly. If a more rigid waterfall approach will be used during the implementation, then a more detailed project plan will need to be produced during the Planning phase of the Macro Design than would be required for an agile iterative approach. The Planning phase may even need to be extended, depending on the level of granularity required to produce the project plan for a waterfall implementation. Taking the delivery methodology into account will ensure a realistic project timeline is established and the implementation phase progresses as expected.

Figure 4: BPM / Workflow Delivery Methodology.

At the conclusion of the Validation activity phase, the third milestone is achieved by delivering the Final Playback. This Playback focuses on the validated and finalized design of the To-Be process and is the final Playback of the final deliverables.


The Planning phase is one that gets the entire team excited about the completion of a key project milestone and the start of another. Demonstrating and presenting the process discovery, requirements, and transformative design and solution, all crafted through collaboration, brings confidence for implementation success. Within the Planning phase, usually 1 week in duration, the following deliverables will be completed:

  • Process walkthrough in IBM Blueworks Live.
  • User Stories and UI requirements.
  • Architecture Report.
  • Data model.
  • Roadmap.
  • Product Backlog, iteration plan.
  • Project estimation and workstreams plan.
  • Assumptions.

At this point in Macro Design there should not be any surprises. Thorough communication and conversation around the As-Is and To-Be processes will have uncovered requirements and designs that are collectively understood. However, not all the project details, business nor technical, can be completely defined during Macro Design. As a result, it is important to present any assumptions. This will help validate the solution and plan while allowing opportunities for refinement to improve and optimize during implementation.

This phase and the completion of Macro Design does not end the collaboration between business and IT. It is very important that both are involved and engaged during implementation as well, with constant discussion and feedback. After the final activity, Macro Design deliverables will be distributed and reviewed by team members. Details around Macro Design deliverables are covered in Part 3 of the Macro Design article series.


A Macro Design project typically extends to multiple weeks. The average range spans from 4 to 8 weeks, although sometimes it takes up to 10 weeks for larger and more complex projects. See Figure 5 below for a representative Macro Design structure breakdown.

Figure 5: Macro Design Timeline for BPM process solution.

The customer’s requirement to produce more detailed user stories could easily extend the Macro Design duration to 10 weeks. For example, some customers require to document every technical task in a user story at a very granular level, so it can be handed over to a developer for coding. Depending on a number of user stories in scope, Macro Design could even exceed 10 weeks. Other factors that could extend Macro Design beyond its average 4-8 weeks could be complex process implementation and, definitely, integration with external systems. See more specific examples related to the last two factors in the Design section below.

The projected duration of Macro Design is determined during initial discovery sessions with the different stakeholders based on project scope. Of the four phases of macro Design: Requirements, Design, Validation, and Planning, the key phases that largely impact the overall duration are Requirements and Design. See Figure 5 above for reference. The Validation and Planning phases can potentially extend the timeline but usually they are not as deterministic as the first two phases.
Let’s take a closer look at these phases individually.


In business process management, requirements analysis starts with the As-Is process discovery. For medium and large-scale projects, there are a number of processes to discover and capture. More processes take more time to analyze the As-Is, particularly if there are interdependencies among the processes. Another factor extending the Requirements phase of the Macro Design, is the creation of User Stories in the context of these processes The number of epics and user stories are not necessarily directly constrained by the individual business processes but are usually roughly aligned with them.

Both of these factors, the number of business processes and the user story creation, have direct impact on the duration of the Requirements phase of the Macro Design.


The Design phase has quite a few components that contribute to its duration. The following are few examples of components that can increase the duration of the Design phase:

  • Process flows.
  • User interfaces.
  • System integrations.

Let’s take a closer look at each design component individually. Process flow design can be complicated by the introduction of advanced constructs and messaging patterns. For example, imagine a single process model definition that splits into a number of processes and has to coordinate completion of all these child-processes based on some business-driven conditions. If each of these child-processes has to write-read operational data in an external system of record, this could take more time and involve more IT architects, i.e. to consider the design of a solution beyond the IBM Workflow domain, before a satisfactory solution could be determined.

A large number and/or complex user interfaces that require dedicated discussions around design approach, can significantly increase the Design phase duration. This is in part due to the collection and analysis of the feedback from the end-users of the application. The feedback analysis typically takes multiple iterations before an acceptable user interface is agreed upon.

Another significant area of the Design phase is external system integration. More often than not, this is the part that consumes most of the Design effort. During Design each individual integration point, identified during the Requirement phase, is closely considered from a number of perspectives. For example, the following list of attributes is collected and documented for every service integration:

  • Directionality of the integration.
  • Integration point signature.
  • Method, transport and protocol used.
  • Data payload format.
  • Availability of the service specification.
  • Availability of the test data.
  • Availability of the test environment where this service is accessible for testing.

As a BPM solution provides extremely broad and comprehensive means for integration with the external systems, doing so takes more time and effort to create a macro design solution for all involved systems. Note that these discussions do not require full time business SMEs, as they are mostly IT driven with business support. Business SMEs will need to be involved to validate the data requirements, the locations of the integrations point within the process, and the purpose and value of the service.


The Validation phase is commensurate with the size of the Requirements and Design phases. It typically involves walking through and reviewing the outlined solution based on the provided requirements. It’s not unusual that some of the parts of the design will be revisited and updated, when following this iterative approach to design. Furthermore, architectural decisions, as living artifacts, get constantly revised and adjusted during the course of the Design and Validation phases.


The Planning is the phase of the Macro Design that tends to remain constant in duration. It does, however, correlate with the number of requirements and overall deliverables to be produced. . If the required deliverables deviate from the standard Macro Design, then this phase can take longer than the usual 1 week. For example, if waterfall methodology will be used during implementation, a detailed project plan will need to be built during Planning which can extend this phase to a few weeks. This is not the case for an Agile project where the plan and roadmap remain high level.

To summarize, the phases of Macro Design that have the most impact on its duration are Requirements and Design. The Validation phase relates to the length of the Requirements and Design phases, but the Planning phase is considered a relatively constant share of Macro Design. Usually, Business Improvement Analysis workshops, such as Discovery Workshops or Design Workshops, take place in the initial stages and produce Rough Order of Magnitude (ROM) estimates. These estimates become a basis and an essential input for assessing the complexity and size of the project, on which the duration of the respective Macro Design phase is established.


The core objective of this article has been to describe the activities within the Macro Design phase for medium to large IBM Workflow production implementation projects.

The Macro Design phase is staffed with a mixture of business and technical SMEs, and consists of four phases: Requirements, Design, Validation, and Planning, and typically lasts 4 to 8 weeks.

Macro Design phases include activities to understand the current state of the business and technical landscape, design the future state for the solution, and define an implementation roadmap to incrementally rollout the solution. The next article in this series, Part 3: Macro Design Deliverables, describes the artifacts that are created during these activities of the Macro Design.

As you start, or continue, your own journey with the IBM Digital Business Automation Suite, approaching your next production delivery project, please share your feedback and/or questions on how Macro Design may help to make your project successful by adding comments to this article.


This article was written by Genevieve van den Boer, Slava Zheltonogov, and Jacob Jepperson. The authors would like to thank Jean Pommier and Pierre Berlandier for their invaluable reviews and comments.

Related Materials

IBM Redbooks Publications:
Scaling BPM Adoption: From Project to Program with IBM Business Process Manager.
Business Process Management Design Guide: Using IBM Business Process Manager.
Process Discovery Best Practices Using IBM Blueworks Live.
Discovering the Decisions within Your Business Processes using IBM Blueworks Live.

IBM developerWorks Articles:
Part 1: Capturing integration complexity for BPM and SOA solutions.
Part 2: Reference guide to integration characteristic.

This article series:
Introduction to Macro Design, Part 1

Disciplined Agile Consortium:
The Disciplined Agile Framework, Introduction to Disciplined Agile Delivery (DAD).

Join The Discussion

Your email address will not be published. Required fields are marked *