What Are The 6 Steps To Business Transformation?
In this post we’re going to talk about the 6-steps to implementing your business transformation, the objective of each step and why that step is required, common mistakes with each step, and tips to overcome them.
But before we discuss the 6 steps, let’s first discuss business transformation.
We’ve had a lengthy discussion on business transformation in a previous article.
When or why an Organisation goes through a Business Transformation is to implement their new Target Operating Model, commonly also referred to a TOM, or just as TOM.
The word, or acronym TOM has become synonymous with business transformation. It also has a negative connotation. Just on hearing the word Target Operating Model or acronym TOM, instills immediate fear in many businesses.
They’ve learned through the grapevine and other means that developing, designing and implementing a TOM was difficult (well that is about to change)!
The TOM is relatively misunderstood, as is the name Business Architect, and Business Architecture.
What a TOM is, is an Organisations future operating model, how the business is setup and structured – that is, how its people, processes and technology is setup and structured across the Organisation to effectively and effectively execute its business strategy, to achieve its Vision.
The problem with implementing an Organisations TOM, is 70% of business transformations that implement the Organisations TOM end in failure, which results in wasted time, money and missed opportunities.
There are 4 common problems, which we discussed in a previous podcast.
In terms of approaches and methods that Organisations use with their business transformations, and TOM, there’s a lot missing from existing approaches.
There is not a holistic joined-up approach.
There’s also (un)intentional confusion created by the different parties involved from consultants with their agendas to the different stakeholders protecting their empires…
This is why we created the HOBA® – House of Business Architecture – Business Transformation framework, and the 6-Steps Design Process that implements HOBA, and in doing so, implement the Organisations Business Transformation.
The 6 Steps To Business Transformation
HOBA® is implemented via the Target State Architecture Design Process (or Design Process for short).
The Design Process is a six (6) step process, and aligns neatly (and intentionally) to each of the Reference Models that make up the House of Business Architecture® (HOBA®).
- Reference Models – address the strategic aspects and ‘Why, Who, When, Where, Why and How?‘ questions asked of the Business and Business Architecture, and are broken down into Building Blocks;
- Building Blocks – break down and address a specific aspect of the Reference Model they belong too, and are a collection of blueprints that drill down and describe a specific perspective of that ‘Why, Who, When, Where, Why and How?’ aspect; and
- Blueprints – provide an increasing focused and detailed view of the building block they belong to, capturing and documenting the operational aspects of the Business and Business Architecture.
Business Transformation Journey
Now, to provide you the context, what happens when they implement their TOMs, they go through a Business Transformation Journey.
With HOBA®, Organisations go through a fairly well defined journey through their Business
Transformation, through each of the 6-steps of the Design Process:
- Step 1 – Focus, used to define what the ‘end looks like’ (i.e. Vision) that the Organisation (and Business Architecture) is aiming for;
- Step 2 – Control, used to define the boundaries which decisions must be taken, and by whom, and how scope, work and risks are managed;
- Step 3 – Analyse, used to define the ‘As-Is’ operating model, pain points and improvement opportunities;
- Step 4 – Evaluate, used to define and quantify the Business Benefits the Organisation plans to realise from the Business Transformation and prioritise the enablers (business and technology changes) needed to get there;
- Step 5 – Design, used to define the ‘To-Be’ Target Operating Model (TOM), addressing the pain points and improvement opportunities and the prioritised enablers, and
- Step 6 – Implement, used to develop the plans and roadmaps to implement the physical TOM that aligns to the design and manage traceability that all the stakeholder concerns and requirements are addressed.
Here are the steps you need to develop and implement your TOM and transform your business:
Step 1: Focus
Focus is the first step in the Organisation’s transformation journey.
Focus is also the first step in the HOBA® Design Process to develop the ‘design’ of the Target Operating Model (TOM), as well as manage the implementation of the ‘physical’ TOM.
Focus is also the first step in the HOBA® Design Process to develop the 'design' of the Target Operating Model (TOM), as well as manage the implementation of the 'physical' TOM.
The activities (building blocks and blueprints) that are completed in Step 1 is to complete the HOBA® Business Motivation reference model.
Why Focus?
Step 1 – Focus, is naturally about focus. Focusing the direction and vision for the Organisation as well as the scope of work for the programme and Business Architecture.
Focusing the Organisation and transformation on the end goal, is Stephen Covey’s book1 is the second habit, ‘begin with the end in mind’. The ‘end’ for the Organisation and transformation is the Vision for both the Organisation and the Business Architecture.
Focus establishes a clear and single focal point of ‘what success looks like’ for both the Organisation, the Business Architecture. Without a clear focus, any transformation is destined to fail.
Without a clear focus, any transformation is destined to fail.
The Business Motivation Reference Model is critical to the success of the business transformation and the Business Architecture work as it agrees the outcome and direction for the programme, and as importantly it sets the outcome and direction of work for the Business Architecture.
The Business Motivation Model is made up of building blocks and blueprints that defines the Vision, Strategy, Objectives, Measures, common and define the common terms used on the programme so everyone is heading towards the same goal, and the talking the same language.
Common Mistakes
The biggest mistake with the Focus (i.e. defining the Organisations Business Motivation Model), is either this step isn’t done, or it isn’t done in its entirety.
The main reason why the Business Motivation Model (and related Building Blocks and Blueprints) namely setting the Vision, Strategy to get there, Objectives and Measures, is not done often due to some form of hesitation, reluctance, or even dismissiveness that this activity is even required.
Often the reluctance is a lack of understanding of its value (similar to the current misunderstanding of the value of the Vision, and indeed of Business Architecture)
One of the main reasons why business transformations fail is they don’t deliver the intended outcomes, either in full or part, on time or not at all. In most cases this is because the Business Motivation was not properly defined, which means not defining the Vision (the ‘Why?’), not decomposing it down into its Strategy (the ‘How it will achieve the Vision’), Objectives (the ‘What does good look like?’) and Measures (the ‘When is Organisation planning on achieving this?’), that the Programme did not have an agreed view of what success looked like for the Programme, how to get there, and how to measure progress towards it.
Tips To Improve You Focus
When faced with resistance getting the Business Motivation Model (and related artefacts) developed and signed off, remember, its most likely a fear of the unknown, of not knowing the value of defining the Business Motivation Model. The answer to that problem is to educate your stakeholders on the benefits. But first you must resist the temptation to ‘crack on’ and set yourself up for success now, by defining what success looks like, and how to measure it.
When starting to engage with your stakeholders to craft (or agree) the Business Motivation Model, always start with a strawman (based off a model example or previous project) and informed by existing documentation (i.e. the business case that initiated the project is a good start), as opposed to starting with a blank sheet of paper which is fraught with problems, as it almost always seems to open up unnecessary ‘can of worms’ (or old wounds).
Make sure you make your Measures SMART (Specific, Measurable, Achievable, Realistic and Time-bound) and if you want to save money and time, do it ASAP!
This brings us to the next step, Step 2 Control.
Step 2: Control
Control is the second (2nd) step in the Organisations transformation journey.
Control is also the second (2nd) step in the HOBA® Design Process to develop the ‘design’ of the Target Operating Model (TOM), as well as manage the implementation of the ‘physical’ TOM and Business Architecture.
The activities (building blocks and blueprints) that are completed in Step-2 is to complete and define the HOBA® Governance reference model.
Why Control?
Step 2 – Control, is naturally about control. Control of the processes, decision making, scope and risks for the programme and Business Architecture.
Control is provided via the Governance Reference Model, which is about setting and agreeing the governance framework, design principles and roles and responsibilities of those on the programme to make decisions and manage risks regarding the design and implementation of the Business Architecture, and ultimately the Target Operating Model (TOM).
The Governance Model answers primarily the ‘WHO?’ question and aspect of the Why, Who, What, Where, How and When questions asked of the Business, and the Business Architecture – Who are the stakeholders involved? (as well as ‘What is their role, and process(es) to manage the work, control the scope and manage the risks?’).
Establishes the process and roles for making decisions on the programme, managing changes and most importantly but often over looked, correctly managing risks (not just capturing them (a very important model as it sets a solid foundation to build the TOM from, which is also why it is a primary ‘foundation’ of HOBA®);
Common Control Mistakes
The common mistake with developing and agreeing the Governance reference model (and related building blocks and blueprints), is that is once it is set up, it isn’t actually followed.
The Governance framework has the tendency to fall down when it gets caught up in the trap of becoming a ‘hollow ritual’ i.e. its talked about, the outcomes are recorded then printed and hung on a wall, but never really followed.
When it comes to managing risks, namely the RAID (Risks, Assumptions, Issues and Dependencies), what usually happens in practice, although there are four (4) elements to RAIDs, only Risks are actually tracked and managed (the others seen as either not important, or captured but managed elsewhere).
When the need to capture RAIDs arrives, the time it was captured is the only time it was ‘actively managed’.
Tips to Improve Your Control
In order to be effective Business Architects (and Business Transformator®’s for that matter), we have to take our Stakeholders on a journey.
This journey is the journey of discovery in (and of) the both HOBA® and the Governance framework and the process of how to design and implement the changes, as well as the journey of the change itself.
You need to keep Stakeholders aware there needs to be adequate controls and measures in place to track and monitor process (and progress), which allow Stakeholders to feel comfortable and confident in the Programme, that it will deliver on its expectations, deliver value and changes to the Business that enable the Business to effectively and efficiently execute its Business Strategy.
HOBA® is based on Agile Scrum, that have daily Scrums (15-minute stand-up meetings, first thing every morning), where each team members reports (1) ‘what they did (yesterday), (2) what they plan to do (today), and (3) what could impede them doing (2) today?’, where risks become part of (3) so that the risks are visible and actually managed.
This brings us to the next step, Step 3 Analyse.
Step 3: Analyse
Step 3 – Analyse is the third (3rd) step in the Organisations transformation journey.
Analyse is also the third (3rd) step in the HOBA® Design Process to develop the ‘design’ of the TOM, as well as manage the implementation of the ‘physical’ TOM and Business Architecture.
The activities (building blocks and blueprints) that are completed in Step-3 is to complete and define the Current Operating Model.
Why Analyse?
Step 3 – Analyse, is about analysis. Analysis of the current or ‘As-Is’ state of the Organisation and Business Architecture, as it is today. Analysis is provided via the Current Operating Model Reference Model.
Common Analyse Mistakes
What you will find on programmes is when just the idea of assessing the Current Operating Model is raised it is often met with a lot of resistance from the programme and/or the Business representatives.
The reason for the resistance from the Business is generally due to a perceived ‘unnecessary need’ to complete or define the Current Operating Model to any degree of completeness (or correctness), which is often due to the perceived time and (lack of) resource availability and commitment needed to complete the task.
The common excuse for not wanting to carry out or establishing a shared understanding of the Current ‘As-Is’ Operating Model, is often… “We know what the Organisation looks like already, we know what the problem is, we’ve been living with it for years…”.
What you will find however, after asking ten (10) different individuals about their experiences and views of the issues, concerns and opportunities they face on a day to day basis, is you will receive ten (10) completely different answers (not two being the same).
Defining the Current Operating Model not only provides a baseline to measure progress (which addresses the ‘you can’t improve what you don’t measure’ problem discussed earlier), but importantly also forces those on the programme to come together and form a consensus and agreement on the state (and nature) of the actual problem(s) they are attempting to solve.
Failing to define the Current Operating Model will make it very hard, if not impossible to get agreement from the stakeholders of what the ‘past’ looks like, especially when a programme has moved 6-months along and they struggle to recall not only what the business looked like, but also how well (or not) it was performing.
As a Business Architect, developing the design of the TOM that excludes an assessment of the Organisations Current Operating Model would be opening oneself up to scrutiny, or at worse, jumping into ‘solution mode’ and proposing changes to the Organisation where there hasn’t been a clear or robust challenge of what is actually currently going on (i.e. designing based off treating the symptoms of the problems, not the cause of the problems) within and across the Organisation today.
Tips to Improve Your Analyse
HOBA® overcomes the shortcomings of how Business Architecture is currently perceived and used i.e. only assuming responsibility for the design (only) of the TOM’, and not overseeing the implementation of the physical TOM, by the explicit and intentional inclusion of the areas
that have been previously ignored:
- An assessment of the Current Operating Model (to identify and validate the issues, concerns and needs of the Organisation to be incorporated into the design of the TOM).
- Agreeing or confirming the Organisations or Business Architecture’s vision (which all requirements and the design of the TOM will align and trace back to).
- Agreeing the governance structure or processes (which will manage all decisions on and across the programme).
- Identifying, validating or prioritising the Business Benefits that are intended to be realised by the Organisation (which all changes to the business and Business Architecture are to support).
This brings us to the next step, Step 4 Evaluate.
Step 4: Evaluate
Evaluate is the fourth (4th) step in the Organisations transformation journey.
Evaluate is also the 4th step in the HOBA® Design Process to develop the design of the Target Operating Model (TOM), as well as manage the implementation of the physical TOM and Business Architecture.
The activities (building blocks and blueprints) that are completed in Step-4 is to complete the HOBA® Benefits reference model.
Why Evaluate?
Step 4 – Evaluate, is about evaluating both the Business Benefits the Organisation is intending to realise from the transformation programme.
It is where the evaluation of the Business Capabilities (namely the ‘people, process and technology’ aspects of Business Capabilities) that the Organisation is considering investing in takes place.
The evaluation here considers whether the proposed business and technology changes (enablers) are actually the right ‘enablers’ that will enable the Business to realise the planned Business Benefits, in the order and priority the Organisation wants and needs to realise them.
The Benefits Model is where the enablers are identified and justified which is where investments is made to either buy, build or borrow the enablers.
By defining the Benefits the organisation intends to realise, and the enablers that enable the Organisation to realise them, it stops the programme (and Organisation) going into solution mode and developing (or prioritising) solutions that don’t directly impact the realisation of the Business Benefits or are not aligned to the overall Vision.
Common Evaluate Mistakes
The most common mistake with Benefits and specifically Business Benefits is that identifying and quantifying is either done too late in the transformation programme, or not at all.
What often happens is that a ‘central’ Benefits Manager will run around to individual programmes after they have either started developing a solution, brought one off the shelf or are winding up the programme and ask ‘what Benefits are you hoping to realise (knowing they were never formally or otherwise identified, let alone agreed).
This is a symptom of not knowing Business Benefits true value. By not doing ‘benefits’ upfront, what happens is the design (TOM) is not based off implementing changes (i.e. business changes and technology enablers) that are specifically and intentionally identified, quantified and prioritised to realise the intended benefits, but in most cases the design is based on ‘solution mode’ first (i.e. treating the symptoms, not the cause of the problems the Organisations is facing now).
The other common mistake with benefis is when they are done, some benefits are financial benefits, measured on cash-terms, and othersare non-cash. What this causes is that is like comparing apples withpears. Both are fruit, but hard to compare. To make it easy to compare, Benefits need to be on like-terms.
Tips To Improve Your Evaluate
To improve your Evaluate Score, the best and quickest way is to ensure the Benefits Model and therefore the Business Benefits are done and done upfront (i.e. early in the programme lifecycle).
To do ‘Benefits’ means – Benefits are identified, quantified, prioritised and assigned a Benefits Owner who is responsible for their realisation, which includes providing input into the changes that are necessary to ensure their realisation.
As part of quantifying the benefits, benefits can be financial and nonfinancial. There is no right or wrong format or type of Benefits, however it is better that all benefits were on same terms – ie all cash, or all non-cash, which makes it easier to compare benefits.
The same applies to tangible benefits, and intangible benefits. Benefits can only really be compared when they can converted from intangible and are measurable – like staff satisfaction for example. To convert these intangible to tangible, benefits to tangible you can create a star rating – and assign a star to the different levels of satisfaction, making this previous intangible benefit, tangible and able to be quantified and compared.
This brings us to the next step, Step 5 Design.
Step 5: Design
Design is the fifth (5th) step in the Organisations transformation journey.
Design is also the fifth (5th) step in the HOBA® Design Process to develop the ‘design’ of the Target Operating Model (TOM), as well as manage the implementation of the ‘physical’ TOM and Business Architecture.
The activities (made up of Building Blocks and Blueprints) that are completed in Step-5 are to complete the HOBA® Target Operating Model (TOM) reference model.
Why Design?
Step 5 – Design, is naturally about design. The design of the Target Operating Model (TOM).
In HOBA®, the approach to developing the TOM is based on a Business Capability (‘capability’) driven design, which means the design starts with business’ capabilities.
These changes to the organisations business capabilities (made up of the People, Process and Technology) were identified and prioritised as the Business (people and process) changes, and Technology ‘enablers’ from Step-4 Evaluate, where the Benefits Model was defined.
This means the design is explicitly based on implementing business changes (people and process) and enables (technology) that directly impacts the realisation of the planned business benefits, which also addresses the pain points and improvement opportunities identified earlier in the Current Operating Model.
Common Design Mistakes
The two biggest mistakes with defining the Organisations TOM is either it isnt done (like defining the Current Operating Model), Programme stakeholders are ‘all too eager’ to “jump in” or “crack on” and do the seemingly ‘fun stuff’ and start with the ‘design’. What this means is they almost completely disregard any assessment or analysis of the Current Operating Model.
The most common cause for jumping into ‘design’ or ‘solution mode’ is there is often not a single agreed view or consensus of what the pain or the current state of the organisation is.
The problem this causes is by not having a single, agreed view of the problem (or problems) the business transformation is intending to solve, is it makes it hard, if not impossible to qualify or quantify the degree of change, or success the programme has had when all the changes are delivered and implemented into the business.
Despite the clear and obvious benefits of piloting some or all changes into a subset of the Organisation or stakeholder population (mainly to reduce implementation risk that the implementation of the changes to the Business cause minimal disruption and are more likely to achieve the intended benefits), as the Business Architect raising or suggesting the idea of Piloting, you are likely going to face some resistance and/or criticism on this approach – mainly due to lack of knowledge and understanding of what actually is involved in a Pilot and its benefits.
Tips To Improve Your Design
By following the HOBA® Design Process, and starting the design with Business Capabilities, you will identify the candidate capabilities that are being changed or enhanced specifically to address the identified and validated stakeholders concerns that directly contribute to the
Organisation realising the planned business benefits.
By using the Business Capability Model as defined in the HOBA® framework, and creating the enterprise wide view of the Organisation ‘at rest’, you will capture and represent these changes the programme is delivering to the Business, and confirmed with the stakeholders both within (and outside) the programmes the following:
- There is no gap, or duplication of work (i.e. two or more programmes are not inadvertently working on the same capabilities, or delivering similar functionality, and
- Identified any dependencies or conflicts with other projects and programmes across the Organisation and had conversations (and negotiations) early with these other parties before any ‘change debt’
- small or large, technical or non-technical (i.e. design and development of physical architecture) occurs, to reconcile any differences, timings and ultimately align the separate pieces of work.
In terms of piloting, as part of your conversation with your key stakeholders, keep in mind:
- The Business Changes and Enablers identified in the Benefits Model are untested, which need (and should) be tested. Pilots allow for the validation of the Enablers, Business Changes and implementation option are ‘fit for purpose’ (and not just ‘look good on paper’).
- Pilots follow is a lean-start-up technique, which is based on two (2) principles – ‘fail fast’, and ‘Build, Measure, Learn’. That is, build the Minimum Viable Product (MVP), test it on a small-scale implementation to see if you can break it, if it breaks (i.e. doesn’t yield expected results), tweak it (or throw it out), if it doesn’t break (i.e. yields expected results) – roll out the full-scale implementation.
- Pilots (MVPs) allow for better communication and stakeholder engagement. Through testing the MVP on a small number or scale of stakeholders, the stakeholder communication can be simplified and targeted. By having a smaller number of participants in the pilot allows for a greater level of collaboration between the programme team, pilot participants and ultimately the Organisation, taking them along the transformation journey together.
This brings us to the next step, Step 6 Implement.
Step 6: Implement
Implement is the sixth (6th) step in the Organisations transformation journey.
Implement is also the sixth (6th) step in the HOBA® Design Process to develop the ‘design’ of the Target Operating Model (TOM), as well as manage the implementation of the ‘physical’ TOM and Business Architecture.
The activities (building blocks and blueprints) that are completed in Step-6 is to complete the HOBA® Road Map reference model.
Why Implement?
Step 6 – Implement, is about the delivery of the ‘design’ of the Target Operating Model (TOM), and the implementation as the ‘physical’ Business Architecture that the TOM ‘design’ describes.
In terms of HOBA®, implementation is provided via the Road Map reference model. The Road Map reference model is used to define the design; the physical TOM and other road maps and activities to ensure the business and technology architectures are aligned, and the stakeholders concerns are addressed and traceable right the way through the design.
The terms of road maps:
- The design road map provides the milestones and time frames to develop and deliver the design of the TOM, and
- The physical road map provides the activities needed to develop and implement the physical TOM.
The Road Map model also covers the Benefits Realisation plan, which is used to track the realisation of the planned benefits that the technology and business changes recommended in the design, enable their realisation.
The benefit of the Road Map reference model is the building blocks and blueprints provide the visibility and transparency of the plan is to deliver the design, and also implement the physical changes to the Business,and helps stakeholders build confidence that the design will deliver a physical TOM, that enables the business to realise the intended benefits,and when they should expect to see them.
Common Implement Mistakes
One of the biggest problems with Implement (i.e. Road Map mapping), is thinking that this activity (ie Road Map mapping) has to start after ‘analysis’ (Step 3) and ‘design’ (Step 4) is completed. Thinking that Road Map mapping has to start after analysis and design is completed is one of the biggest mistakes with Implement, and can actually be started earlier in the Design Process.
Project Mapping for example is a Step-6 Implement building block that could be (and is recommended to) started earlier in the Design Process. Project Mapping can be done in parallel with other building blocks. In fact, it should actually be done at the beginning of the programme or close to the beginning as possible. Project Mapping identifies and allocates the prioritised enablers (business and technology changes) into discrete projects that will develop and implement those aspects of the physical Business Architecture.
Project Mapping provides a clear view of the responsibly of which projects are delivering the specific enablers that directly support the planned benefits and the relative timeline these will be delivered, and benefits realised, relative to the other (or all) projects within the programme. This visual tool provides the benefits traceability, which shows the relative contribution each project has to the overall strategy objective, which as the Business Architect, knowing the relative contribution each project has to the overall strategic objective, you are able to provide the Organisation with a guide to the prioritisation of the order of the different projects (and therefore Business Changes and Enablers) needed to be implemented for the Business to realise the planned benefits (in the order that it requires them in)!
Another example is although Road Map mapping appears at the end of the Design Process (Step 6), it doesn’t mean that you can’t or couldn’t start this step earlier, especially if you have eager (or restless) stakeholders that want to get a sense of the scale and scope of work required to develop the design of the Target Operating Model (TOM), and complete the programme. HOBA® Reference Models, Building Blocks, and Blueprints allows you to draft a strawman relatively quickly and get it out to your key stakeholders in the Business and on the programme for comment relatively quickly. Getting the Road Map (or an outline) out early to your key stakeholders is also an effective stakeholder management strategy to share with them your approach and process, to elicit early comment and incorporate their feedback which aims to get them involved and on board with the change journey so they feel part of the change, as opposed to having changed forced upon them (which never really works or inspires lasting change).
Tips To Improve Your Design
The three (3) biggest tips to improve your Implement score:
- Involve the Business Architect early:
In terms of Strategic planning and implementation, Business Architecture is ideally (and usually) involved in the Organisation Design ‘planning stages, which in most cases when the need for a Programme is identified and initiated. However, what often happens (mistakenly, and incorrectly) is this doesn’t always happen, and Business Architecture is bought in late, often after the programme has started or worse, after a solution is already selected. What this causes is the Business Architecture is then used to validate the solution, and design a TOM around the solution, as opposed to the other way round – bringing in Business Architecture early, developing a TOM fit for the Business, and then designing a solution to fit the TOM.
- Don’t wait to the end to start the Road Map mapping:
Don’t wait till you have finished the analysis and design activities (and developed the TOM design), you can get a draft outline out to the Business, and Programme early. This will provide early visibility (although not a final, or complete version) but enough to elicit feedback, and give your stakeholders a sense of the scale and scope of the work, activities and deliverables and get them on the change journey early.
- Use HOBA® and the Design Process to provide the ‘design’ roadmap strawman early:
One of the benefits of HOBA®, firstly as a framework – all the work, deliverables (i.e. the business architecture reference models, building blocks and blueprints), and activities to complete those deliverables is already known, and secondly with the Design Process – the process and the order in which to develop and deliver the deliverables is already known. This means that the list of all the potential work and deliverables is already known from the outset, which is tailored to your programme, depending on what you agreed as the first activity you carried in Step-1 (Focus) when joining the programme (i.e. agreeing the Statement of Work (SOW) blueprint, part of the Business Motivation reference model, which sets the direction and activities for both the programme, as well as for the Business Architecture). So when the SOW was completed, you already had the inputs into developing the strawman of at least one of the roadmaps – the ‘design’ road map. You can share this early with your key stakeholders to give them early visibility of what work is coming, what to expect and when to expect it, in an effort to help them to feel included as part of the change (as opposed to feel like ‘made to change’) which goes along way to reducing resistance to change and making your business transformation a success!
Thank you for reading this, hope you found a lot of value in it!
Sincerely,
Heath Gascoigne
P.S. If you want to join our Business Transformator community of like-minded Business Transformators, join the community on the Business Transformator Facebook Group here:
P.P.S. If you want to learn more about business transformation, check out The Business Transformation Playbook here.
For more information, visit https://www.hoba.tech
