We have been discussing factors that are critical to success in delivery. In my first blog in this series, “Project without a Deadline does not complete”; we looked at the importance of starting a project with a deadline in mind. The second blog, “Making Deadlines Effective” described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let’s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility.

Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. “Launch of a new product”, “Increasing market share of a product by certain percentage”, “Creation of a new capability”, “Reducing unemployment rate”, “Building a new railway line” etc. are some examples of programs.

Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.

Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.

Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced.

While it is possible to have a Program Board and a ROAM Board physically on the wall, it Is better to create them digitally using an agile tool. When the teams are distributed geographically, digital boards are a must, to ensure that all the teams are looking at the same picture and transparency is maintained.

 To summarize, risks and dependencies across projects of a program are threats to the programs. Surfacing them early is required to create an ability to address them effectively. Surfacing and tracking them transparently, enhance the chances of success in a program.