Author Archives: stenver
The Plan Dimension
Defining the Transformation
The Plan Dimension defines the input to development projects.
Starting top-down in the Platform Dimension, the business will have to select the business options that may occur due to the disruption in the industry. The transformation may not be limited to the business itself, but will also impact the entire value chain. This results in an overhaul of the entire delivery system, which is executed through the 3 perspectives in the Plan Dimension. If certain parts of the organization need to become decommissioned, this is also a part of this dimension.
The themes in the Plan Dimension reflect the activity classes in the transformation plan, while the perspectives are groups of activities. Just like the class of the themes in the Platform Dimension is Asset, the class of the themes in the Plan Dimension is Activity.
The dimension takes its starting point in the accelerating pace of change. The business needs to constantly adapt to new market conditions and competition. Defining projects with long durations will not work. The prerequisites for an extended project will have changed by the time the project finally ends.
As a part of analysis, the transformation team builds a backlog of initiatives that contribute to exploiting the identified opportunities. The backlog is reassessed and re-prioritized in each sprint and the initiatives for the coming 4 months are planned.
The Perspectives of the Plan Dimension
The Plan Dimension also consists of 3 Perspectives:
The Target Perspective manages the overall direction of the transformation. It balances the scope, innovation and risk. At the same time it addresses the business architecture that will accommodate the business model and service hierarchy.
The Design Perspective provides the right resources and competencies for the change and ensures that the new capabilities are transitioned into use and integrated into the new services in the business platform.
The Enable Perspective describes how the next business generations themes are developed and how the organisation is transitioned. The tangible output is the changes initiatives, which can be transformed into work packages by the change projects.
Along with the three perspectives in the Plan Dimension, there are also 12 themes. Each is explored in detail in the following sections, but here is a brief summary:
This perspective settles the configuration of the Platform Themes and the road map for implementing the disrupted business. Identifying the right direction is crucial for the sustainability and growth of the organization. The Target Perspective helps to identify the right path for the organization to follow to achieve its objectives.
The Scope Theme is a direct result of the analysis of 4Drivers for the industry. The business’s mission enters the Platform Dimension through the Scope Theme. The scope of the business transformation is then detailed by specifying the changes to be applied to the assets in the Platform Dimension.
|To scope is to determine the gap between the to-be and as-is settings and controls of the assets in the business platform.|
The Scope Theme explains future business scenarios and the assumptions regarding future business environment, as well as the dynamics associated with the opportunities in terms of the Platform Dimension.
The output of the Scope activity is the settings of the Themes (assets) and Controls of the Platform Dimension.
To realize the options, the business will have to innovate. The Innovate Theme will define the amount of innovation to be used in the change plan. In the digital economy, innovation mainly comes from new technology. In this way, new options occur as result of the development of new technology.
|To Innovate is to make changes in something established by introducing new methods, ideas, or services.|
The business should constantly look for how to innovative use of technology and how disruption drivers could change the value chain. To innovate better, try to find divergent thinkers!
The Value Chain structure is the foundation for the Business Architecture. The Business Architecture is constructed from business modules. In the Target Perspective, the business modules that need to be designed for implementing the business platform. Some of the business modules may already exist, and some new ones will have to be developed. The business design also represents the top level of the Service Hierarchy.
The modules consist of services. The modules are the highest level of the service hierarchy. The modules are not only the services to be delivered to the customers, but also the services the business it-self need to use for producing the output.
|To Modilize is to group the production of services distinctively|
It will be through the Modilize Theme the business will optimise scalability, flexibility, cost efficiency an optimum time to market.
The Mitigation Theme describes the actions needed to minimize the risks related to realizing the options evaluated in the Options Theme.
Pretotyping, market validation
Små eksperimenter ffør store investeringer
Prototyping, product validation
The Mitigation Theme includes 3 levels of challenges that were mentioned in the introduction chapters:
- Disruption in the industry
- Challenges to the business
- Resistance to change
These challenges are generic challenges and should be supplemented by the more specific challenges that the business encounters.
|To Mitigate is to reduce the impact of failure.|
As with all innovations, timing is the key challenge. Many innovative ideas have been developed, but then failed when brought to market. Soon after, someone else succeeded with the same idea. In this way, the Innovation Theme is very closely related to the Mitigation Theme; there must be a Plan B if Plan A fails (this is also referred to as scenario planning).
The objective of the Design Perspective is to enable the execution of the change. It is a breakdown of activities that need to be executed into certain groups. These are managed at tactical level in the organization.
Figure 30: The Design Perspective
Prioritize Theme (1B)
The purpose is to identify the Minimal Viable Services provided by the Scope Theme and to outline the sprints in a roadmap for their implementation.
While the changes for the first sprint are being developed, planning for the subsequent sprints should be initiated. There may be more than one scenario to be evaluated. Scenario Planning is important, as it gives a holistic perspective of what lies ahead and what needs to be done when certain situations arise. It makes it possible for businesses to plan and allocate their resources in accordance with the planned future sprints. This will give the business sufficient time to develop or hire in resources and competences efficiently and in a feasible manner.
|To Prioritise is to decide which services should be available to the customers when.|
The roadmap is explained by the Winning Map. The Winning Map shows the settings of the Themes in the Platform Dimensions 4 Views (Mission, Algorithm, Technology and Human), and in which sprint. The x-axis represents time and investments while the y-axis quantifies the benefits (represented by the Controls for the Platform Dimension).
Specify Theme (2B)
The Specify Theme takes its starting point in the detailed descriptions of the Services and the rest of the Algorithm View. The focus should be on the Minimal Viable Services, which are in scope for the actual sprint.
Based on the definition processes for producing the services and the integration into the Customer Journey and the governance processes, the settings of the other themes in the Platform Dimension is determined.
|To Specify is to describe as-is, to-be – and gap between the two for the assets and controls in the Platform Dimension|
Integrate Theme (3B)
The purpose of the Integrate Theme is to make the services needed for producing the output work together. The services in the value chain can either be produced by the business it-self or it can be purchased from the outside.
|To Integrate is to make modules and services interact with each other.|
The integrate themes apply to for example:
- Business modules
- Supply Chain and Business Partners (including Legal set-up)
The Integrate Theme includes the activities to ensure that all interfaces in the Business Architecture fit together.
Verify Theme (4B)
The objective of the Verify Theme is to minimize risk and ensure the direction of the transformation. This verification can take the form of focus group studies in the market or prototypes or mock-ups that can be tested by the customers. In general, it covers all the activities that can verify that the scope of the transition can be realized. Also focus groups or expert evaluations could be activities in this theme.
|To Verify is to investigate whether the planned services are usable and if they fulfil the customers need.|
Using DevOps does not eliminate the need for using faster, cheaper and more applicable ways to verify service’s fit to the customer’s needs.
The purpose of the Enable Perspective is to develop and implement the new services in the organization. The Enable Perspective is fully dependent of the availability of the resources for executing the activities. The Enable Perspective provides the work package descriptions for the subsequent change projects (which can be executed by the standard project management methods.
Figure 32: The Enable Perspective
Transition Theme (1C)
The objective of the Transition Theme is to facilitate the transition from one sprint of the business to another. The transition will clear the path and minimize organizational drag, and ensure that the old organization can be plugged into the new business. The key feature is to ensure the full realization of all the benefits throughout the complete business environment. The Transition Theme will support and empower the delivery organization in delivering the capabilities.
|To transition is to implement the changes in business platform I.e. shifting the assets from as-is to to-be.|
Prior to implementing the new sprint of the business, the old business may have to be adjusted to accommodate the change. Business processes may need an upgraded organizational structure and may need adjusted, old business modules may have to be decommissioned, and new modules may have to be founded.
An important part of the Transition Theme is to maintain the technology transition plan. This plan must follow the organizational transition and launch of new business modules carefully.
Pack Theme (2C)
The Pack Theme defines the work packages for the subsequent development projects. This theme relates to all the activities that are directly related to changing the specific assets in the business platform.
|To Pack is to write work package descriptions.|
The work packages will have two classes:
- How to changes the themes in the Platform Dimension to fulfil the Controls.
- How the govern the transformation process. The standard project management methodologies will have excellent tools for the governance.
It is noteworthy that also the activities in the Plan Dimension also can be managed by work packages.
Contract Theme (3C)
The Contract Theme provides the business transformation with all resources needed to execute the change and it creates a firm agreement with subcontractors. Subcontractors can be outside as well as inside the organisation. The contractual deliverables are described by content of the work packages.
|To Contract is to create firm agreement with supplies to the transition inside and outside the organisation.|
For example, the contracting could cover:
- Business modules and partnerships
- Physical facilities
- Office space
- IT systems and technology
Test Theme (4C)
The purpose of the Test Theme is to ensure that the deliverables of the work packages as contracted. Best practice is to write the test specification together with the work package description.
|To Test is to verify that the work packages are delivered as agreed.|
The best place to look for testing methods is in the IT area. Here, we will find test forms like:
- User Acceptance test
- Dress Rehearsals
- Operational test
- End-to-end test
It is crucial to find the right level of testing. Too much testing will prolong the time to market, but faulty Services may also ruin the brand value. Finding the right balance is key.
Views in the Plan Dimension
Just as in the Platform Dimension, there are commonalities between the themes in the three perspectives of the Plan Dimension. The views give a coherent understanding of different abstraction levels of the same classes of tasks.
In the Plan Dimension, there will be four views.
Figure 33: Views on the Plan Dimension
The Transformation View contains the activities: Scope, Prioritise and Transition.
In the digital economy, success is all about timing. The world is unpredictable and volatile. The products and services that failed yesterday may succeed today or tomorrow – and vice versa. A faster transformation process will enable the business to react faster to changes in market conditions – but at the end of the day, it is about having the right timing – not too early and not too late.
The Transformation View contains the Planning Themes (activities) needed to define the transformation that the business must go through to fulfil its mission. It defines the overall scope, which is prioritized into the Sprints and the activities needed to transition into the new Business Platform. Therefore, the Transformation view is the cornerstone in the planning. It is about constantly to adjust the scope to market threats and opportunities, identify the Minimal Viable Service and transition the organisation to harvest the benefits of being able to adopt to the markets trends.
The Change View contains the activities: Innovate, specify and Pack.
The Change View contains the practical activities need for bringing the ideas (innovation) into reality. It designs the business and provides the components for the future business and IT platforms by describing the work packages needed to change business and technology.
The Structure View contains the activities: Modulize, Integrate and Contract.
The Structure View establishes the architecture of the transformation. It defines the business modules that provides the new structure for the business, how the modules should be integrated and how the modules should be sourced from partners, subcontractors or internally in the business.
The Risk View contains the activities: Mitigate, Verify and Test
The purpose of the Risk View is to keep the changes on track and to reduce the impact of failure. From the point in time when a business opportunity is identified, until the asset is finally changed, a lot can happen in the external business environment, as well as inside the business itself.
The most severe risks originate at the strategic level. Assumptions of market behaviour or new innovations may not be applicable. Either way, it is important to build risk mitigation actions into the transformation plan from the very start.
There is a tendency to create very large projects when dealing with complex problems. When changes are too big, it becomes very difficult to identify the essentials and no one participating in the change will ever have a chance to get an overview of the dependencies between the deliverables. So, the better structure, the lower risk!
Controls for the Plan Dimension
The Controls for the Plan Dimension are Investments, Benefits and Time to Market.
Figure 34: Controls for the Plan Dimension
Investment consist of the cost of developing and implementing the new/changed assets.
The benefits can be tangible or intangible. Tangible benefits are the increase in value of a physical asset, which finally can be measured as the financial performance. Intangible assets can be market position, brand value and the ability to adapt to exploit market conditions.
It is commonly accepted that the measure for the quality delivered by the transformation is the timely realization of the business case, i.e., within the predefined costs and benefits.
Approaches to the Plan Dimension
The approaches to the Plan Dimension are highly inspired by decision-making theory. The approach to planning must always be a conscious senior management decision. It is about balancing planning of the transformation to the amount of available information and the consequence of failure.
Experience from decades of project work is that management can spend several months on the decision to initiate certain projects – and when started, the projects are then squeezed by short deadlines and insufficient resource allocation. In many instances symptoms are solved by a quickly fix; rather than addressing the root cause of a recurring and potential critical problem.
Figure 35: Approaches to the Plan Dimension
The Rational Approach
The 4Dimensions™ Transformation Framework creates a rational approach to change. My experience is that business is far too driven by short-sighted controls, and management bonuses are calculated based on quarterly controls. Frequent organizational changes and “bold” decisions will never let the originator of a radical change reap the benefits of long-term planning.
The rational approach must adapt to unprecedented conditions. The mindset is to think big and deliver small. Start by defining the end goal and start the evolution in that direction. Create the smallest possible steps. In each step, it must be verified that the sprint goes in the right direction and that the subsequent sprint is still is applicable. This makes the definition of Target Perspective an ongoing process, rather than a yearly process. Under the Rational Approach, the Prioritize Theme will constantly monitor the feasibility of the inventory of changes. The practical application of the Rational Approach can be seen in several technology companies today – especially in companies where the architecture (business and IT architecture) is critical in generating a competitive edge.
The Administrative Approach
The Administrative Approach is based on the resources at hand and by the already defined Minimal Viable Service. You must work with the limitations and insufficiencies present in the organization. The staff will not be the best suited; there may be a lack of training; allocation rate may be insufficient; and the focus may be on solving the problem, rather than identifying the root cause.
Most change disasters originate in the Administrative Approach. Here, major changes commonly start with only a vague idea of the total scope. Minimal Viable Services are not properly analysed and described. And, accordingly, the staff working with the approach is not aligned towards a common goal. In general, the Transformation Organization is working under the assumption that the deliverables are in control and the projects are working efficiently (which – in general – not is the case and which later will result in budget and duration over run and reduced scope). The traceability to the overall strategic business mission may also be poor. Accordingly, the return on investment will be suboptimal.
A typical indication that the change is working with the Administrative Approach is when the change is identified as an IT project. Here, the organization is working under the assumption that the IT system is the problem. However, the IT system does not construct itself. The development is originally based on the requirement of the business organization to have certain IT systems to support the business. Therefore, changing the IT systems without revisiting the business processes that the IT systems are supposed to support will not really provide any change to the business’ competitive strengths. It is imperative to conduct a Root Cause Analysis to identify the actual deficiencies, rather than blaming the IT for the failure.
The Agile Approach
The Agile Approach is used when the objective is not clearly defined or when the process of creating the solution is unknown. The Agile Approach is a learning process that starts with a prototype, which is refined and improved over multiple sprints. After each sprint, the results are evaluated, and it is decided whether to reiterate, declare that the outcome is satisfactory or decide that the approach has failed. The Agile Approach has been more common in recent years with the growing use of the Internet. User interaction with the Internet has shown to be very unpredictable, so the Agile Approach (i.e. trial-and-error approach) has proven to be very applicable.
The Agile Approach can be very time-consuming and requires many resources. Post-project evaluations always show that result could have been reached much faster and cheaper and at a higher quality, if the method and the objectives had been known from the start.
However, in complex environments the agile approach runs into problems. Agile components are normally managed by a Product Owner. As the Product Owner will have to control all 12 Themes in the Platform Dimension as well as many of the 12 themes in Plan Dimension this will require an extremely competent Product Owner. These are very hard to find! The product owner normally has a stronghold in one of the platform themes and limited knowledge of the other. Having a complex Minimal Viable Service with impact in many platform themes, complicated integration into business and IT platform and complicated transition and education of users and customers the Agile Approach is no longer applicable.
The Quick-Fix Approach
The most common approach is the quick-fix approach, where changes are started with no or very little relation to a Minimal Viable Service. It will just be to fix an eminent problem in business platform.
The quick-fix approach is excellent if you keep the changes small. The prerequisite is that the change has a limited and clear goal. In this way, it is a limited investment, the staff will be easy to align, and learning when the changes are implemented immediately.
Using different Plan approaches
Just as we saw it with the approaches to the Platform Dimension, the approaches on the top and right requires a more strategic mindset. The approaches in the bottom and to the left will use a more practical and operational mindset.
Figure 36: The use of Plan Approaches
Furthermore, there will be considerations to the consequence of failure and the complexity of the transformation. Straight forward changes, will tend to use quick fixes and agile approaches, whereas complex and high-risk changes need more thorough analysis.
Figure 37: Relationship between Plan and Platform Approaches