Building A Factory Model for Solution Deployment

Introduction

Organizations either planning or in the progress of their digital transformations are seeking methods that can assist in accelerating the transformation and reducing the time to organizational and stakeholder benefits. Before initiating and executing this transformation, these organizations should ensure they have the following in place:

• A standardized business process taxonomy, delineated by value stream will be enabled across the enterprise.
• An established methodology that can enable and facilitate deployment acceleration (Just WagileIT).
• Established scope definition delineating standardized work products and measures (Addressing Strategic Gaps).
• A basis of estimate (BoE) for estimating and planning the deliverable work products (Addressing Strategic Gaps).
• A requirements rationalization criterion that is well defined and communicated (Requirements Rationalization).
• Transformation PMO is set up for success (Enabling A Successful Transformation PMO).

The above items can serve as critical inputs in organizing and planning for a ‘factory model’ that will accelerate the transformation and time to benefits. However, we need to define a ‘factory model’ to set a baseline understanding.

What is a Factory Model?

In my experience, a factory model can be represented in one of two methods. The first method is where the factory floor is fixed with manufacturing equipment and tooling (workstations), and the product/solution evolves through those workstations at a set pace (or move rate). Automotive, green aircraft, etc., are representatives of this factory model.

The second method is where the product/solution is fixed or stationary in assembly bays (work areas), and the manufacturing teams rotate at a set pace. Industrial equipment, such as shop floor robotics, subsea wellhead final assembly, etc., represents this factory model.

In either factory model scenario, there are commonalities such as batch processing or the receiving of smaller components that serve across the workstations and teams, and the product/solution is thoroughly tested before the product/solution moves to the next workstation or team rotation.

In deploying enterprise-wide solutions across multiple and diverse business units, the team-rotating model can be a template to develop and hone an optimal solution deployment. This article will assume that all deployment sites have similar planning and operations to highlight the rotating teams.

Deployment Scope and Team Organization

The deployment team organization for multiple site deployments is best setup in the following manner:

The teams are broken into three key teams. The acronyms in this illustration are the following:

• BPO = Business Process Owner (both Global and Local)
• DA = Data Architect
• MDO = Master Data Owner
• SA = Solution Architect
• VS = Value stream

These teams are defined by their respective scope, which is the following:

• Initiate and Assess Team: The initial collaboration, engagement, review, and grooming of the solution scope to be deployed at the targeted sites. The outcome of this team’s engagement includes a finalized scope definition for deployment, identification of crucial master data legacy systems and owners, and an initial baseline plan for the deployment.
• Master Data Early Start Team: The early start of master data transformation from the identified legacy systems. The outcome of this team’s engagement includes at least two mock conversions with a minimum target of 75% and 85% post-load validation by the targeted site(s) data owners.
• Template Deployment Team: The deployment of the template solution based on the outputs from the “Initiate and Assess Team” regarding a final scope definition and baseline plans. The outcome this team produces is an on-schedule go-live of the template solution.

The program manager, integration solution architect, and OCM lead provide continuity across all three teams and the site(s) leadership. The solution center or excellence (CoE) supports and assists in dispositioning, planning, and delivering any new processes/solutions that may arise (but are not critical to a go-live).

The Delivery Executive/Business Sponsor assists with enforcing the requirements rationalization, and the enterprise PMO ensures that the teams are leveraging the standards and that performance reporting is data-driven with supporting facts.

With this organization of scope and teams, we can now illustrate how a factory model can be enabled.

Applying the Factory Model to the Organization

We can illustrate this rotation below with the basic understanding and example of the deployment teams and a factory model where the teams rotate on building and delivering an enterprise product/solution.

The basis of the program manager, integration solution architect, and OCM lead movement is represented in the following illustration.

As stated earlier, the program manager, integrated solution architect, and OCM lead provide continuity from one deployment project into the next phase project.

When there is an organizational commitment to the PMO standards and deployment delivery methods, the deployments resemble the learning curve one will see on a production line with a new product/solution.

The above illustration represents the teams moving down the learning curve through standardized processes, increasing team synergy, and applying continuous improvements as each deployment is executed. This ‘factory’ model can work well where the methodology, deliverables, work products, and work product measures are standardized, and the teams and team members remain consistent.

Factory Model Risks

The factory model for multiple solution deployments can be very effective and efficient for accelerating deployments while reducing the cost and time per deployment. However, some risks must be identified, qualified, and quantified for mitigation. Those risks include the following:

• Team Attrition: Team attrition and turnover can interrupt or disrupt the momentum a team is building as they perform their tasks per the given scope of work. High attrition and turnover can set the team back in their efficiency gains and disrupt the synergy gains across and within the teams.
• Inconsistent or Lack of Standards Enforcement: The lack of standards enforcement by the PMO will detrimentally impact the teams, projects, and program from making any efficiency improvements, cost improvements, or time-to-benefit reductions.
• No Communication and Collaboration Cadence Discipline: The lack of a disciplined communication and collaboration cadence can quickly move teams, team members, and projects into disarray and confusion.
• No Near-Time Progress Visualizations: The lack of individual and collective teams’ progress visualizations can detrimentally impact team performance. From daily standups to weekly and monthly delivery progress reporting, progress visualizations are critical to building and maintaining team synergy and performance.

Conclusion

Transformation deliveries and deployments can vastly improve by leveraging a factory model. Yet a factory model demands specialized teams, deployment standards, standards automation, integration, constant monitoring, and analysis for continuous improvement.

While numerous cost-effective platforms and tools can enable a factory model, the organizational commitment to standards and discipline of cadence are the biggest challenges to successfully implementing a factory model.