Process-Driven Delivery & Dependency Management

In this post, you will learn how we performed dependency management for a team using a dependency management tool. This information can serve as orientation for your own projects.

1. Mission

As part of an IT program, we led a team responsible for dependency management. Dependency management includes:

• The identification of the scope and time dependencies and maintenance of the corresponding documentation
• Recognition of supply bottlenecks and their immediate elimination
• Measurement of quality assurance coverage and elimination of test gaps

Based on our experience, we describe the approach and key success factors on a very detailed level as a basis for similar challenges in complex IT projects.

Dependency management is a task that should be an integral part of the product development process. It requires a coherent methodology during the development process. It is relieved when the entire product development process follows these premises:

• The planned change or transformation must first be worked out at the business process level, e.g. following the eTOM framework: User Flows
• The vehicles for elaborating and documenting the IT change should be derived from the targeted user stories
• Delivery vehicles should contain a well-defined set of user stories and refer to a delivery version: Change requests
• The integration test cases should relate to the user stories (requirement level) and to the target user flows (process level)
• The incidents and defects should relate to the test cases

Based on the given traceability, a health check of user flows over multiple delivery-release cycles can be determined and reported. The report can be used for Go/No Go decisions for commercial launch. The User Flow Cockpit represents the dependencies between all important factors: Process, Scope, Delivery, Test and Defects.

In an enterprise-wide view, each delivery release must begin with a planned change to user workflows, triggered by multiple projects and harmonized by process owners on the business side. In SAFe terminology, key business processes can be mapped to value streams.

To complete the delivery and dependency view, a view of central services in the form of a repository is also required (the solution dimension in the SAFe framework). Versioning of the interfaces used by the services can provide high flexibility in the delivery-release process up to continuous delivery.

2. Tool Chain

ARIS: Business Process Modeling

CONFLUENCE: Descriptive elaboration and documentation of user stories

JIRA:

• Tracking and control of user stories
• Tracking and control of change requests
• Effort estimation based on requirements and solution documents
• IT Capacity Planning
• Gating workflow
• IT budget planning
• IT fault management

JIRA + X-Ray Plug-In:

• Staging integration tests
• Production integration test
• Business Acceptance Testing

The following data model shows the path of traceability between all factor

3. Our added value: The dependency tool

The standard tools are specialized in their field. An E2E view from the business process to the IT defect is not supported by standard functions, so we implemented a central dependency tool that allows:

• Reading all relevant information from Jira, Confluence using the REST API
• Reading all relevant information from ARIS via a file-based nightly export
• Automatically creating ARIS business process relationships in Jira
• Deriving the correct delivery information and automatically updating scope artifacts in Jira
• Automatic generation of requirements documents in Confluence and as PDF
• Generation of a complete business process cockpit view (health check along multiple releases)
• Generation of a complete delivery and budget cockpit view

4. Outlook

The scaling and orchestration of processes, epics, user stories and solutions could be configured according to a simplified SAFe setup. It is interesting to conceptually analyze the SAFe approach and elaborate the tool chain in this case.