Transformation Methodologies – Just WagileIT!

Background

Transformation methodologies have been with us for decades. Today, many system integrators' (SI’s) essential marketing item is their methodology and how using the SI and their methods will increase the probability of success.

In 2011, the Project Management Institute (PMI) and the Agile Certified Practitioner (ACP) recognized Agile as a methodology. 2011 the “Scaled Agile Framework for Enterprise” (SAFe) formally introduced scaling Agile for significant enterprise transformations.

Alternative transformation methodologies existed before Agile and SAFe. In the 1990s, the US Department of Defense (US DoD) published a monthly periodical on agile development techniques and tools. The periodical was a collection of agile methods and tools to accelerate new product development and enhancements to existing defense platforms. The agile methods published included Crystal, Scrum, Synch-n-Stabilize, and Judo Strategy, among others. These agile techniques and methods were best suited for smaller teams focused on providing enhanced features and functions upon existing platforms in production.

Before SAFe, a few transformation program directors and managers leveraged an informal methodology similar to the SAFe method for large enterprise transformations. The reference model for this informal methodology was based on systems engineering and construction techniques utilized across the industrial products, aerospace, and automotive industries. This informal methodology provided a means to present the transformation in a “Waterfall” method of executive boards while iteratively producing solutions and outcomes.

Thus, given the history of transformation methodologies and the available tools and techniques to enable them, why do most large transformations continue to miss critical deadlines and consume more resources and dollars than initially funded?

While the transformation methodology is essential, the discipline to define and adhere to the detailed, organized content and standards will determine its success or failure. So, the WagileIT methodology provides great guidance on the required contents and standards.

Wagile What? An Introduction

The WagileIT methodology was informally introduced in 2002 to plan and manage an extensive, fixed-fee milestone-based enterprise transformation. The three-year enterprise transformation scope included the following:

• Multiple value streams and business processes
• PLM, ERP, and MES commercial enterprise applications (and their integration)
• On and off-shore teams, which totaled more than 250+ personnel
• Over 12K employees impacted by the transformation

WagileIT requires the team to understand the basic structure of any enterprise solution, whether it is COTS or custom-grown. The following is a representation of a solution structure.

Most enterprise COTS and custom solutions must work from one or more parts of this structure. The foundational scope upon which all else will be built is how the enterprise is organizationally represented in a solution. Thus, the first foundational step to address is establishing what and how an organization will be represented.

Master data is defined as cross-business critical data objects shared across the enterprise and with various external stakeholders. The master data scope is the critical framework of any enterprise COTS or custom solution. Master data can be classified as transactional (customer, supplier, part number, etc.) or configuration (order types, goods movement types, etc.). Combining organizational structure elements (the foundation) and master data (the framework) is the basis for many key performance indicators (KPIs).

Any meaningful planning can be initiated with a solid foundation and enabling framework. Thus, the planning scope element addresses the required business planning processes by value stream (and across value streams, such as SIOP). This scope grouping addresses all the necessary planning processes.

Once the scope of the planning process is defined and established, then the scope of the executing and controlling process can be defined and verified. The executing and controlling scope can be very challenging without first planning it.

The final scope element in this representation is the closing and analytics process scope. All prior scopes should be addressed before defining the process scope in this scope grouping.

The overall structure of the WagileIT representative scope definition also provides the basis for planning how to execute the methodology.

How to WagileIT

Once the scope basics are identified and defined, we can discuss how this methodology is applied over time. Those familiar with large industrial products or solutions know that manufacturing often requires taking the manufacturing bill of materials (MBoM) and rotating that MBoM ninety degrees.

The result of the ninety-degree rotation often results in how the build and testing will occur. This principle is leveraged into the WagileIT methodology and represented as follows:

The space of the waves (or increments if you are familiar with SAFe) does not represent the time required. Consider each wave similar to a part or assembly item that must be built and tested before moving to the next higher-level assembly item. All processes are broken down by the following:

• Wave
• Value Stream
• Process minimal viable work products to be produced (or amended)
• Work product measurements (consistent across all value streams by work product), etc.

Work products can be user stories in Azure DevOps or issue types in JIRA (or similar applications). Process work product dependencies and schedules are managed in a project schedule. Consider the project schedule, the MRP engine of the transformation, and Azure DevOps or Jira, the manufacturing execution system (MES).  

After two decades of leveraging this methodology, the organization structure and master data are the shortest durational waves. The executing and controlling scope will tend to be the most prolonged total duration (up to 12 weeks). The duration overall and within each wave depends on the magnitude of scope, delivery team skills and discipline, and maturity of the solution being implemented (or deployed).

The first two waves of scope, organizational structure, and master data should be formalized and signed off by the transformation business sponsor and respective leaders. These approvals and signoffs set the baseline from which all else will be defined, built, and validated.

Each subsequent wave requires an end-to-end validation of all built at the end of their respective wave. For example, at the end of the “Executing and Controlling” wave, a validation scenario must include those processes from the organizational structure, master data, planning, and executing and controlling scope areas (see illustration below).

This validation should be done once with the internal team to ensure the solution works as expected and then with the business sponsor and users for each of the last three waves. This validation requires some prerequisites to be in place to execute WagileIT successfully.

Prerequisites for Successful WagileIT Execution

For WagileIT to successfully plan and execute, some essential but critical prerequisites must be in place. Those critical prerequisites include the following:

• At least one, but not more than three, complete value chain scenarios predominantly represent how the business generates and delivers value to its market.
• An enabled PMO that maintains and governs delivery standards, automation, and integration (Enabling A Successful Transformation PMO).
• Processes defined within this total value chain must be definitively where the inputs and outputs can be rationalized and validated.
• A master bill of material(s) (Master Data BoM) must be identified, defined, and mapped into the value chain scenarios.
• The landscape environments (sandbox, development, and quality, at minimum) must have as many interdependent application components available as possible to conduct full integration validation at the end of each wave.
• Standard MVP work products and work product measures need to be established across the respective value streams (Addressing Strategic Gaps In Transformation Planning)
• A disciplined communication and collaboration cadence are required; all transformation team members should be oriented to it.
• Transformation team members and business sponsors must understand the WagileIT methodology, prerequisite items, and the expected benefits.
• Some of these prerequisites may not be fully defined and broken down until the completion of the master data wave. Yet, the above requirements must be in place before starting the planning wave.

If these prerequisites are met, the transformation will reap multiple benefits.

Benefits and Risks of a WagileIT Methodology

The benefits of leveraging WagileIT, combined with planning and executing standards and a cadence of disciplined delivery communication and collaboration, are significant. These benefits include the following:

• The review, validation, and sign-off at the end of each wave significantly reduce delivery costs and schedule risk.
• Integration test planning occurs in parallel because the incremental buildout and validation serve as an input integration test template from which all integration test scenarios can be more fully defined.
• The business is exposed early and often to a working demonstration of the solution and witnesses the solution’s evolution.
• While the processes will vary by value stream in each wave, the methodology work products are defined, standardized, and consistently measured for delivery performance trends and analysis.

Along with benefits, some risks also exist with this methodology. Those risks include the following examples.

The users desire to change the foundational or master data scope in a later wave.

This can be mitigated upfront by having approval and signoff at the end of each wave. These approvals and signoffs provide a baseline for the cumulative build while the team rationalizes and assesses the impact of the proposed change.

Backlog growth can detrimentally impact delivery timing.

The backlog does occur and needs to be managed. As with the buildout of a complex product or solution, when backlog occurs, those backlog items become the first priority items to complete as the next wave initiates. This is similar to installation kits in building an aircraft or automobile. If all installation kits are not completed at their assigned workstation, and the line move rate is fixed, the unfinished installation kits are moved with the product and are the first to be completed at the subsequent station.

Solution delivery delays and cost overruns can occur due to working processes out of wave sequence.

A value stream team member may desire to work on their preferred processes rather than the defined scope of the respective wave. This can be mitigated through upfront education and the respective value stream leadership, ensuring the team understands the priorities before each wave is initiated.

Conclusion

WagileIT shares many similarities with agile, SAFe, and traditional waterfall methodologies. Yet WagileIT goes to a greater extent to define and delineate the scope and categorize it by wave to minimize the risk of rework. WagileIT also establishes consistent standards for work products to be produced and the measurement for those work products.

I have successfully leveraged WagileIT across many transformations over the last two decades. WagileIT has also been utilized in planning and executing upgrades and large enhancement packages but with a more abbreviated and accelerated schedule (three to six months max, depending upon the customizations).

Each time this methodology has been leveraged, delivery has occurred either on or before baseline delivery, costs were within budget, and the post-production solution sigma has been more than 5.85 sigma (trouble tickets are defects, transactional volume are opportunities).

The WagileIT methodology has much more content, which will be provided in subsequent articles. Thank you for reading this article, and please provide comments, questions, and critiques if you deem them appropriate. Please remember that none of us are as smart as all of us.