In the context of the latest IT program I have lead a team, which was responsible for the dependency management:
- to identify the scope and timeline dependencies and maintain related documentation
- to identify delivery gaps and address them immediately
- to measure the quality assurance coverage level and address testing gaps
Based on our experience we made I would like to describe in this post the approach and the key success factors on a high detail level as a blueprint for similar challenges in complex IT projects.
The dependency management is a task, which should be an integral part of the product development process. A post consideration is coherent with high efforts and short reaction time. The dependency management presumes a coherent methodic during the development process. It gets relieved, if the whole product development process follows these premises:
- The planned change or transformation has to be elaborated first on business process level e.g. following the eTOM framework: user flows in our project context
- The scope vehicles to elaborate and document the IT change should be derived from target user flows: user stories
- The delivery vehicles should include a well defined set of user stories and refer to one delivery release: change requests
- The integration test cases (Beside unit and component tests) should refer to the user stories (requirement level) and to the target user flows (process level)
- The incidents and defects should refer to the test cases
Based on the given traceability a health check of user flows along several delivery release cycles can be determined and reported. The report can be used for Go / No Go decisions to launch commercially the end user product. The “user flow cockpit” represents the dependency between all key artefacts: process, scope, delivery, test and defects.
In a company wide view every delivery release has to start with a planned change of user flows triggered by several projects and harmonised by the process owners on business side. After the commercial launch the repository of user flows is baselined and reflects the “As-Is” state. In the SAFe terminology the key business processes could fit to the value streams.
To complete the delivery and dependency view a consideration of central services in a repository form (e.g. payment services) is also necessary (the solution dimension in the SAFe framework). A business process transformation can lead to a change of set of services. The versioning of the interfaces used by the services can provide a high flexibility in the delivery release process, up to continuous delivery.