By Bob Etris
Implementing something new that requires changes to multiple underlying systems is no simple task. The field of portfolio management and the various best practices associated with it have matured over time to address this issue. Simultaneous changes to multiple systems that aim to yield a singular outcome and achieve a common set of objectives require doing more in parallel. That parallel activity, unless properly integrated and coordinated, tends to increase the risk to the overall project and ultimately makes it more challenging to accomplish the task at hand.
The link below provides a reference to a presentation recently delivered by my colleague, Jack Moore and I at the 59th Annual Air Traffic Control Association Conference. While the points made in the presentation are focused on implementing capabilities within the National Airspace System (NAS), the themes with respect to reducing risk in any portfolio-based approach to change ring true in other domains beyond aviation. Here are a few of the key takeaways:
Implementing simultaneous changes to multiple systems requires a greater level of planning than for changes to one system. While planning and allocating the requirements to the other affected projects or programs is a necessary prerequisite, implementing complex change requires a different approach to detail, design, software development, deployment, and ongoing sustainment. At each point along the way, a change in any one area has a likelihood of impact in more than one person, organization, or stakeholder. In the broadest sense, one of the best ways to mitigate this risk is through the careful design of appropriate governance processes to manage and prioritize issues as they arise while ensuring decision making authority includes the appropriate stakeholder communities.
Ongoing maintenance of a new function or capability that spreads across multiple systems presents a potential philosophical challenge with respect to the (potentially different) maintenance approaches of the underlying technologies. For instance, if a user finds a problem with the capability and calls the help desk, that help desk call needs to be triaged by multiple teams with multiple sets of expertise looking at both the root causes in the source systems as well as the integration points across those systems and how they interact. As an organization takes on more and more of these capabilities with multiple integration points, the design of the organizational IT support structure must be aligned to serve the changing needs of its mission.
Integration has a cost, and that cost must be taken into account in the lifecycle planning and execution of this sort of work. This includes not just the integration costs associated with the software development activity, but costs associated with integrated outreach to users, coordination of test activities across multiple platforms and long-term sustainable occasions for maintenance and enhancement activities to both the underlying systems and the capabilities that span them.
At Evans Incorporated, we believe our human centered approach to understanding the organizational and business systems that govern these types of changes best positions our customers to reduce their risk and ultimately save money otherwise spent on escalating scope and schedule challenges.