Creating a Value Delivery Machine Part 2 of 3: Managing Large Scale Programs

Creating a Value Delivery Machine [Part 2 of 3]

We now have our arms around our strategically aligned solution in the ‘Solutioning for Value’ article. We understand its projected value and the broad strokes of what we want to deliver. Now it is time to realize the solution in the organization. Our next step in building our value delivery machine is to design and deliver the solution. We need to establish the delivery program.

Just a reminder, the execution phases discussed in this and the next article include all aspects of the solution — organization and people, practices and process, and systems architecture. Because the operations and people aspect requires extensive treatment and a unique set of methodologies, we will cover it in the ‘Guiding Organizations through Change’ article. Keep in mind that regardless of which aspect we are discussing, the efforts occur simultaneously in each phase.

Finally, to continuously deliver the highest value to the enterprise, we are engaged in an ongoing learning feedback loop. We need to be tuned into that feedback and ready to adjust to emerging learnings. As we progress through the phases we will continue to identify previously unseen failure points, performance challenges, and new opportunities that we might pursue. Additionally, our operating ecosystem will change, potentially adjusting our objectives. The more complex the program and the longer the duration of the program, the more new stuff we will have to navigate. We need to remain on top of all of the learnings and change and we are heads down doing the noble work of execution.

Program Phases

Programs, regardless of size and complexity, have an execution lifecycle which is broken into phases. The phases include Discovery, in which we complete our due diligence, planning in which we prepare the effort, development in which we build and test the solution, and launch-to-land in which we deliver the solution and complete its adoption.

Completing the Discovery Phase

As we developed the proposed strategically aligned solution, described in my ‘Solutioning for Value Article’, and completed early analysis which has yielded the problem definition, projected the value and have gathered nascent requirements, putting us in the heart of discovery. With this work done we have placed ourselves deeply in the heart of the discovery phase. The discovery phase is the planning pre-work phase in which we rough out and align on the solution before we go into deep planning. However there is additional due diligence that we need to complete before we start planning. The rest of the discovery phase is engaged in due diligence to ensure we have a solid enough proposed solution that we do not waste our planning effort on something that will not work.

Gathering Requirements

This is the phase in which we engage internal and external efforts, pull data sets to fortify our assumptions, and align leadership, experts and selected heavy users to wring out the initial rough design. Discovery can be accomplished in one of two ways — Bottoms up or top down.

Bottom Up Approach

Bottoms up due diligence is the rigorous approach of data and information gathering and then building out the answer for the solution from expert insight from that body of information. It takes an astounding level of effort and a lot of time to put this together. I once worked on a program in which the entire first year was spent in the discovery phase.

Benefits: This deep analysis based due diligence will result in a well reasoned solution set that has a reasonable level of confidence of working.

Challenges & Risks: The greatest challenge is the time and effort spent. Even after doing all this work things will be missed. Taking this approach makes sense for mission critical activities. However, we need to make sure that we avoid paralysis through analysis. We will never be able to achieve perfect intelligence or prove out all assumptions. We need to have a cut off and exit ramp from this effort.

Top Down — Hypothesis Based Approach

One of the newer techniques that has emerged in the last several years is the hypothesis based approach in which an experienced or expert individual defines what they believe should be the solution and the assumptions for what must be true for that solution to be successful. Then through an iterative process, test the assumptions through fact-finding until arriving at a solution for which the assumptions hold. Like pilots, the hypothesis based approach does not deliver and launch a solution. Rather it reduces the discovery process by circumventing the bottom-up requirements development effort in discovery by starting with an assumed answer and working backwards.

Benefits: The approach is designed to substantially reduce the discovery phase time and effort.

Challenges & Risks: The big risk inherent in this approach is that if a poor solution is chosen or assumptions developed either iterations are extended substantially or the solution design may miss critical requirements. The time saved in discovery will be lost in resolving solution issues.

Assess Potential Solutions & Potential Platforms [if appropriate]

As a reminder, we are assessing three key aspects of the solution. Organization & People [which we will assess in depth in the following ‘Guiding Organizations through Change’ article, enterprise practices and processes, and supporting technology systems architecture. For all three aspects, discovery due diligence is about making sure that we have a clear enough picture of what we are dealing with that we can plan for building and deploying the solution.

Enterprise Practices and Processes

Working with functional experts and heavy users, we have documented practices, processes and performance insights. If these things are already documented then it is simply a validation review. If they are undocumented or we are building new capabilities, we may have to develop workflows and practice requirements with guiding principles, documenting transactions and output requirements for each step. It is likely that the outcome that we are driving toward will demand a higher level of performance. So the validation and documentation should take into account performance improvement requirements. The bottom line is that we are pursuing our practice and process due diligence to clarify the operating gap between our strategic objective and our operational capability.

Unique and/or unfamiliar capabilities may require external consulting experts. For example, when I led an effort to store and manage digital images for a marketing organization, we hired a consulting group to help us sort out the necessary metadata taxonomy. At the time, image metadata management was a fairly esoteric discipline. With their taxonomy in place we were able to pull and structure the metadata from the digital images to make them easy to retrieve and manipulate.

The Operating Gap Opened by a Strategic Shift

Technology Systems Architecture

In the business world we rarely make large operational changes without requiring systems support. Data volumes, human touchpoints, and process complexity simply demands it. Tooling is something that everyone tolerates or hates, but organizations need. Deploying or updating platforms, modules, applications, and integrations will occupy the lion’s share of the development and deployment effort. As of this writing, the platform market is nearly $54B. However, that number is dwarfed by the systems integrator market which is now greater than $380B. Systems integrators are the folks that do the work of translating our business needs into platform performance, and includes players such as Deloitte, Cognizant, Capgemini, and Tata. The work is so challenging and risky that, for the life of the program you may want vendor and systems integrator representation on your steering committee. As indicated in the ‘Solutioning for Value’ article, tooling is such a broad and varied arena we cannot dive meaningfully into the specifics of each type. However there is a key design consideration that is true for all systems deployments.

The Technical Gap Between Operational Demands and Current System Capability

Just as our practice and process due diligence is tasked with clarifying the operating gap between our strategic objective and our operational capability, systems architecture due diligence seeks to define the gap between the needed operational capability and the system’s technical capability. The entire point of the program is to close both gaps. Closing that technical gap is costly and continues to be a high cost to maintain. So if you can run well without technical intervention, you should. That said, every company that I have worked in or with has a substantial systems footprint down to a solopreneur owned and operated dance studio. It is hard to get around the technology.

On the well founded assumption that systems capability will be part of our program, we are presented, even before we begin, with a major trade off choice. This trade off choice will impact how we approach our due diligence. The choice is do we align the process to the technology or the technology to the process? This is literally a multi million dollar question. Let me explain.

Platforms cover a set of processes and capabilities. These processes and capabilities will NOT perfectly fit the operational capability. They may not offer some of the processes or parts of processes that we need. They will likely offer many processes and capabilities that we do not need. The platform or module footprint will not match our operational capability footprint. The vendor’s standard capability is like a mismatched puzzle piece. Either we will have to adjust ourselves to the platform offerings or customize those offerings to meet our process needs.

Additionally, platform ‘best practices’ are a result of compiled popular practices and the platform design capability and limitations. Platform process steps may be different than our process steps with different input demands, internal tasks, and output structure. Adopting platform processes may lead to radical changes in our operations.

Ideally, we all want a custom solution. Like Burger King, we want it our way. Unfortunately, a fully custom technical solution is (a) incredibly expensive and time consuming to build and maintain, and (b) incredibly expensive to update as technology and operational needs evolve. This makes a fully customized solution too costly a weight to bear for most organizations.

On the other end of the spectrum is migrating your processes to those offered on the platform. However, that path is fraught in different ways. It is likely that our process and capability needs vary at least in some areas from the platform in ways necessary to run our operations. If those variances are mission critical or at least mission hobbling we need to close that gap. To do so, we have a few go-to options.

• Configuration — Provided programmable options that set up the platform operate more in line with operational needs.
• Add ons — Software extensions or enhancements that add new features or functionality to an existing program or application. It is designed to enhance the base software’s capabilities and provide additional tools or options for the user.
• Plug ins — Software that adds new functions to a host program without altering the host program itself. Widely used in digital audio, video, and Web browsing.
• Wrappers — Data structure or software that ‘wraps around’ other data or software, so that the contained elements can exist in the newer system.
• Integrating a additional module — A reusable extension to a main program dedicated to a specific function
• And of course, narrow customization — actually changing the code of the purchased platform or module. Vendors do allow for some limited customization as long as it does not touch the core code. If/when we need to customize we need to lobby the vendor to include that customization in future general updates so that they become part of the standard offering, limiting maintenance and upgrade costs moving forward.

Note that all of these options come at an additional investment and will require ongoing maintenance. Regardless of how we close the technology gap we will be making costly trade off decisions that we will be living with day-to-day, and addressing in future upgrades.

Determine Expertise Gaps

Finally, discovery is the phase in which we identify any expertise gaps in developing the solution and operating, maintaining and administering the solution. We either need to hire them or develop them internally.

Planning Phase

Now that we have gathered all of the critical data and information, made preliminary decisions about development approach, and have engaged the key players that will develop the solution we now need to plan out the development and launch effort. For the planning discussion we will not discuss project development tactics such as gantt charts or PERT evaluations. My operating assumption is that if you are reading this missive you already understand them. Rather, for complex, enterprise programs it is more useful here to discuss how the program is positioned for success answering the questions:

• What should we roll out?
• What should come first?
• When should we do it to avoid operational disruptions?
• To whom do we roll out the capability?
• How do we reduce the risk of failure?

Validating the Solution

In the discovery phase we assembled a proposed solution. The proposed solution is roughed together with available information and data insights based on input from experts, heavy users and selected vendors. We have invested a fair amount of time reviewing all aspects and aligning leadership. That said, we have not explored the details of the solution to see where it breaks. Validating the solution requires lining it up end-to-end and, at least conceptually, having our experts and heavy users walk through the solution with ‘what if’ analysis resulting in a vetted, updated and fully documented solution.

Selecting the roll out Strategy

We have now invested a lot in WHAT we are delivering. Now we need to focus on HOW we deliver it so we deploy it to best effect. Those solutions regardless of how they are delivered will disrupt business and product development operations if not curated. We will discuss curation extensively in the ‘Guiding Organizations through Change’ article. Here we will focus on choosing a rollout strategy that both supports the solution being delivered, reduces deployment risks, and navigates potential disruption points. Here are some of the most popular strategies for solution delivery and trade-offs that you will have to consider.

State Change [Big Bang] Delivery

In a state change, sometimes called big bang, delivery, the entire solution is delivered to everyone involved all at once. The entire organization is moved wholesale from the legacy solution to the new solution. This means that at launch the leadership team must understand the solution and its performance expectations, the users are prepared to operate within the new solution framework, and all affected functions are ready for operation within the new solution framework. Achieving this level of launch-day-one preparedness is no small effort even if the general direction and processes are relatively familiar, [evolution vs. revolution]. If the solution is unfamiliar, [changing the business model], the effort is even greater.

Benefits: Delivering a state change is often the fastest, cheapest way to design and build the solution. Everything is designed and built at once and delivered as a whole solution. State change delivery avoids multiple builds, extended preparation, and the long-term overhead required for other methods.

Challenges & Risk: While execution of state change solutions is a straightforward one-and-done path, it is rife with challenges and risks.

• Extended discovery — State change solution delivery has to be right from the jump. Because everyone and everything has to work from day one the discovery has to be rigorous and extensive so the design is correct.
• Design precision — The design must be comprehensive and perfected. It must be tested for all possible contingencies.
• Comprehensive training and guidance — All users must be trained to the level of comfort they had with the legacy method.
• Fully realized support framework — Support structures and teams must be prepared to address all emerging issues.
• Readiness assurance — Functional organizations must ensure that any functional/local gaps between the solution capability and functional/local needs are addressed.
• Roll back — If, for any reason, the solution fails to perform it must be rolled back otherwise the organization will experience a major business disruption.

Due to these challenges, state change deployments are difficult to get right. The greater the solution deviates from legacy operations the more likely unexpected issues will arise.

Example: In 1961, Yuri Gagarin completed the first manned space mission accomplished something that had never been previously done. The program that resulted in the successful mission had to get everything right from the rocket, fuel delivery, life support, return support, to cosmonaut training and readiness. Literally everything had to be perfectly right at launch. Had anything not been right, the failure would have been catastrophic.

Phased Delivery

The method, often used for major organizational changes and for application platform delivery, is the phased approach. In the launch approach the solution is delivered in waves of change. Each phase introduces a new aspect of the solution that is in itself a wholesale yet limited in scope capability.

Benefits: Phasing, when it can be used, is a way to break up a state change and eat the elephant in big gulps rather than all at once. Solutions are typically phased so that the most straightforward aspects of the whole solution are delivered first to achieve early successes, build whole solution confidence, and capture early learnings for the riskier phases.

Challenges & Risks: The phased approach requires a series of design and launch efforts extending the timeline for effort substantially. While the risks described in the state change approach are somewhat mitigated by the narrowed launch scope and previous launch learning, they all are still realized, albeit to a lesser degree in the phased approach. Additionally, this effort extends the governance and administrative overhead burden

Example: An example of the phased approach is deploying a multi-capability ERP platform starting with expense and accounting modules. It follows the typical approach that enterprise platform delivery programs usually use. Determine the enterprise level processes to be upgraded. Determine the practices and processes needed, organizational structure and expertise required, and the tooling solution in which to configure the process.

Local Start with Footprint Expansion

The finished solution is operationally deployed narrowly to a geographic location, a function or a team as the new way of doing business while capturing performance information and identifying necessary improvements. As the solution is validated, best practices emerge, and confidence built, the solution adoption is spread to other parts of the organization.

Benefits: Footprint expansion provides an opportunity to wring out a capability before bringing the full organization population into the fold.

Challenges & Risks: This type of deployment sets up dual system operations for an extended period. Typically it makes data and performance reconciliation between the two deployments difficult to impossible. Additionally, it will likely confound trend and historical reporting.

Scheduling for Operational Realities

Regardless of which deployment strategy we choose, we need to be cognizant of two factors when setting our schedule — Creating risks to doing business and overwhelming the organization in the process of delivery.

Creating Risks to Doing Business — From a scheduling perspective, critical operational events should be avoided. Delivery that impacts financial reporting should avoid quarterly and annual financial quiet periods. Delivery that impacts engineering and product management organizations should avoid a major product launch period. Delivery scheduling needs to take into account critical business events so as to not disrupt the business.

Overwhelming the Organization — Human capacity has limits when it comes to juggling day-to-day work at the same time as our teammates navigate a new way of doing things. Delivery should be scheduled considering and avoiding high demand periods such as annually planning, annual employee reviews, etc. Additionally, if the organization is navigating multiple solution deliveries, those deliveries should be orchestrated so that the impacted folks have an opportunity to digest the change without stumbling..

Selecting the Build Methodology

Once we figured out our roll out strategy we now need to select a build methodology. While there are plenty of methodologies to choose from. That said, by and large, there are two general types of build methodologies used to deliver complex programs. They can be used on their own or used together on different aspects of the program.

Waterfall Methodology

The waterfall model breaks down development activities into a linear sequence of activities. This structure fits nicely within the phases we are discussing, breaking development activities further into tasks appropriate to development effort.

Benefits — Waterfall methodology is attractive in that in a single view we see a summary of all work to be accomplished and provides a clear sense of defined outcome. We can use the waterfall visual to quickly align on schedule, inter-task dependencies, and task assignments.

Challenges — The most obvious challenge of the waterfall method is that, while it appears ‘certain’, unforeseen problems WILL emerge requiring the schedule to adjust. Additionally, we are tempted, using this approach, to detail ALL tasks creating a plan that is ponderous to manage. I once took over a PMO that had a team of five folks dedicated to updating project plans. That level of plan management effort provides little to no value. For large programs, managing a plan at the big chunks level is sufficient and allows the big chunk leads to manage their particular chunk is a method that is appropriate for that piece of work. A final caution about this methodology is that while the end point appears’ certain, as discussed in solutioning, programs these large and complex will have solution adjustments along the way.

Agile [Scrum] Methodology

Agile methodology favors individuals and interactions over process and tools, working solutions over extended builds and documentation. It is widely used in software development but can be used for any type of solution delivery. Planning identifies solution requirements and identifies discrete pieces to be developed to meet the solution needs. Further, a minimum viable product [MVP] is identified as a first goal. This MVP delivers a minimalist solution to be used and provide future build feedback.

Benefits — On the plus side, you get something to use fast and have a strong say in future builds so that it ultimately reflects your operational needs.

Challenges — Builds are rapid with a new piece dropped into place every few weeks. Using a solution built this way is like living in a house under construction. It is inconvenient and your day is filled with workarounds. Additionally, the ultimate delivery schedule and solution structure is unclear because, by design, you are learning as you go. Leadership, especially leadership without a strong software background, have a hard time aligning to a plan that develops as it goes. Delivery of large programs using this methodology alone is a hard sell.

Planning Assumptions, Risks, & Dependencies

We discussed capturing assumptions, risks, and dependencies in the solutioning article so we won’t repeat the descriptions here. In the planning phase we will be validating the previously captured assumptions, risks and dependencies, as well as adding new ones. We will want to regularly review these items as we proceed.

Establishing Governance

Healthy governance and oversight is key to program delivery success. it entails establishing oversight roles, controls and escalation practices, and a structure for communication, implementation, and monitoring. Governance provides benefits for all involved. For leadership it provides confidence in the program, the investments they are making, and the plans they are making for life after the solution is delivered.

For program executors, it provides a way to quickly dispatch emerging problems before they impact the program. While I am not rigorously treating this topic here, I think that it is important to clarify a few key aspects of governance.

Steering Team — The steering team membership includes leadership that is invested in and will benefit from the program delivery. They are a decision making body that, in making program decisions, will take into account efforts and impacts outside of the program. They bring much needed context to the discussions that we might lose track of in the course of developing the solution.

Program Management Office [PMO] — Most programs, whether they call it by this name, have a PMO to manage cadence, curate steering team reporting, and manage the various activities of the program. Typically it is made up of the program lead, the workstream leads, and possibly a handful of PMO assignees. This structure may provide one to all of the following services:

• Manage the program portfolio and recommend adjustments as necessary.
• Manage program monitoring review cadence and manage the reporting structure, quality, and schedule.
• Track and update the program plan and schedule keeping all stakeholders aligned.
• Track and manage program resources including budget and resource allocation.
• Establish and manage a change management strategy / plan and a stakeholder communications cadence.
• If resourced as such, maintains a stable of project managers that are assigned to lead workstream aspects.

Monitoring — Enterprise programs establish a regular cadence of reviews in which focused discussions assessing program health and deal with emerging issues. Whether written or presented, one of two stories are told:

• Everything is great and here’s the evidence.
• Houston, we have a problem. This is the problem, proposed options and the recommended course of action.

Escalation framework — An escalation framework provides a path for urgently raising and resolving issues. They are custom to every program. However, they typically have a common escalation tiering.

• Workstream leads resolve issues that can be resolved by the workstream team.
• Program lead resolves Issues that can be resolved within the program leadership.
• Program sponsors [executive leaders] resolve issues for which they control resources and impacts, or can collaboratively resolve through their peers.
• Steering Team Chair, often the CEO, CFO, or CIO, resolves intractable issues that cannot be resolved elsewise.

Controls — Program controls are the basic rules of the road. What can be done and cannot be done. They may simply be a short set of do’s and don’ts or an extended set of detailed requirements. Some may be obvious, like avoiding the sorts of operational conflicts we discussed above or as simple as no capability can be delivered without testing. They might be collaborative such as sales process deliveries must have marketing executive sign off. Whatever the critical delivery requirements, operating standards, policy adherence demands, they should be included in controls.

Resourcing — Beyond the resources provided by the PMO. Functional experts and heavy users may be temporarily allocated to the program only to return to their function when their part of the effort is completed. If there are many projects within the program’s structure, project leads may be partially or fully allocated from the functions as well. Resource allocation is a heavy lift.

Procuring the Program Resources

The final activity to accomplish is to adequately resource the team to have the capacity to successfully deliver. Resources may include budget funding for equipment, consulting, tooling vendor contracts, and other activities. Of course the most critical resourcing effort is to populate the program teams with members that effectively support the effort. While we may have a program management office in place to manage allocation, the bulk of the organization’s investment will come from the functions.

Developing Phase

The developing phase is where the rubber hits the road. We dive into building our solution. When reality meets our plan and reality wins. Throughout the development phase we will continue, if not increase our learning, find misconceptions in our assumptions, experience attrition, navigate environmental changes, and navigate emerging problems.

“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength.” — Helmuth von Moltke, Moltke the Elder.

You have probably heard a simpler version of this quote that goes something like “No plan survives first contact with the enemy.” In this case, the enemy includes the unknown, misguided assumptions, program attrition, process and technology issues, risks, dependencies, business environment changes, and so on.

As we go through the paces of development, all that carefully laid program infrastructure that we established during the planning phase goes into action tracking performance to commitments, escalating to appropriate disposition, portfolio adjustments for big shifts along with its valuation, until we are ultimately ready for launch.

Launch-to-Land Phase

Let’s first lay out what we mean by launch-to-land. The design team is focused on pushing the solution out the door in working fashion. Launch is their focus. However, when we step back, launch is not the destination. Rather, a new chapter opens for which the conclusion is a ready organization and a fully adopted solution. ‘Landing’ defines the happy conclusion of this phase and indicates that the solution has normalized. Landing indicates that the organization is ready to receive the solution without stumbling and that all stakeholders have adopted the solution as the new normal. Much of the effort in this phase falls in the change management arena and is covered in the next, ‘Guiding Organizations through Change’ article. However, there are a few program related efforts that we will cover here, the first of which is reducing launch risks.

Hard launch, Soft Launch, & Piloting

During planning we established the roll out strategy and build methodologies we used to establish the solution and have been steadily working toward the roll out throughout development. We know that no matter what rollout strategy we choose, launch is risky. Before we jump into risk reduction let’s first lay out the launch types.

Hard Launch

Hard launch is the classic launch of full capability into production and all the fanfare. The switch is flipped and capability is fully available for broad usage. We refer to this as general availability [GA]. Hard launch is the most risky approach because the general user base finds clever ways to break the solution that your team, testers, and experts failed to consider. If those breakages are significant enough they could shut down the solution. We, of course, would prefer to find and fix those issues before GA. There are a few ways of doing that.

Soft Launch

Soft launch means that you are making the solution capabilities available without advertising. There are a number of ways with spiffy monikers like ‘dark launch’ used to do this. Regardless of name, the purpose of soft launch is to invite trusted internal and external users to jump into the fully formed solution and attempt to break it. Typically, soft launches are planned with a specific timeline to GA giving time to find issues, correct them, and retest the solution.

Piloting

A pilot is a narrow launch of a new solution, often with very limited investment, to a set of selected experts and solution champions. It differs from soft launch in that it is launched into production with narrow access or built into a testing ‘sandbox’ and used there. This narrow set of users safely test the solution before it is broadly launched to general availability.

Benefits: Pilots are used as a precaution to ensure solution viability and make any needed solution adjustments before integrating it as an operational capability. Beyond solution viability it provides a learning opportunity for solution performance and an opportunity to update training, guidance and the support framework from those learnings. Finally, it creates a set of organizational experts and administrators within the functions. Pilots are a great way to reduce launch risk.

Challenges & Risks: Pilots can, once again, extend the duration of the program and supporting overhead. Additionally, the pilot itself sets up additional overhead in that it requires either:

• Parallel efforts running operational data through both the pilot and the legacy processes. or
• Running part of the operations through the pilot in essence running operations through two different processes, the legacy and new ones.

The former doubles the workload for at least some players. The latter bifurcates operations into two different processes for a period. Both approaches are challenging in their own ways.

User Support

No matter how clean the solution is, and the readiness executed, folks will have problems with the solution. To limit user frustration and resolve identified issues we must put in place some sort of framework within which those issues can be parsed and resolved.

Support Services

Office Hours — Regularly schedule availability with a solution expert. Office hours provide openly available time slots into which users can schedule themselves to get help with, “How do I…” questions.

Issue Ticketing — Most companies have an in house capability to submit issues via an automated ticketing process. The submitted tickets are reviewed and parsed to the right problem solver with an assigned priority. These systems are great for coordinating and documenting. But solutioning can often take awhile especially if the ticket is not the highest priority.

Tiered Support — Coincident to the ticketing system, tiered support allows the tickets to be triaged in terms of urgency, type, complexity, and known vs. unknown issues. Tiered support typically has at least three tiers including:

• Front line support that deals with straightforward known issues that have documented resolution approaches.
• Advanced support progresses more complex issues that require troubleshooting to understand and resolve.
• Expert support deals with new, truly systemic issues that require a capability fix.

Roll Back Plan

Finally, if all else fails, we need to have a roll back plan. The roll back plan literally rolls back the failed solution to the legacy capability. We only use a roll back plan if the solution is experiencing catastrophic failure.

Establish Landing KPIs & Metrics

Program key performance indicators [KPIs] are typically capability oriented measurable achievement including milestone dates, scope sizing, sometimes usage measures, etc.. An example of a KPI might be:

• Complete pilot testing of the xyz capability with finance and supply chain heavy users by xx/xx/2024.

Operational metrics, on the other hand, measure expected performance for the solution. These metrics measure things like volume, velocity, user numbers, reliability, latency, quality, etc. They may both speak to performance expectations for the solution and program goals like X number of active users by xx/xx/2024.

Maintaining the punch list

As we approach launch and in the immediate aftermath we will collect a random list of items that need to be completed to ensure full solution capability. That list is often called a punch list. It is simply a way of making sure all critical efforts are tracked and locked down.

Takeaways

Program management is broken into phases — discovery, planning, developing, and launch-to-land. Each of the phases contain a distinct set of activities designed to fully realize a solution that meets the conditions of satisfaction and program goals, while limiting and focusing both development effort, and program risk. Each phase focused on all three aspects of the solution — practice and process, systems architecture, and organization and people. [Organization and people efforts are covered in the next article, ‘Guiding Organizations through Change.’]

Discovery Phase

In the discovery phase, we assemble the proposed solution, achieve leadership alignment, and complete due diligence so we are fully armed for planning the solution development and delivery.

Planning Phase

In the planning phase we select a roll out strategy, build methodologies, resource the effort and generate the detailed plan for delivering the solution and landing the success. Additionally we establish the program infrastructure with governance, escalations and controls to ensure the program is well managed and issues addressed urgently.

Developing Phase

The developing phase is where the rubber hits the road and we build out the solution while preparing the organization for the new capability. The program infrastructure is activated and working to resolve any emerging roadblocks.

Launch-to-Land

Launch-to-Land is the phase in which we deliver the solution and complete the effort to fully meet landing requirements. The goal of this phase is to launch the solution into an organization that is ready to receive it and drive toward adoption targets. We need to design the launch sequence to minimize solution performance risk and support users as we experience issues.

Find more articles from Sarah at: www.operations-architect.com.