Business frameworks determine the
rationale of how an organisation produces
value. So why do we need so many, and
why do so many overlap and compete?
Achieving
Strategy
Success Through Aligning Business
Frameworks
DAVID HILCHER
Achieving Strategy Success through Aligning Business Frameworks
Introduction Note: This article is written firmly in the voice of achieving value through understanding industry
and business attractiveness. It is therefore consistent for a market-focused organisation but not a sales-focused
organisation chasing market share.
There will soon be available a full set of business processes for a generic organisation. These detail how to
develop and implement strategy.
The largest roadblocks and the simplest methods to developing and implementing strategy already
exists in many medium to large organisations: the current business frameworks.
Business frameworks determine the rationale of how an organisation produces value. So why do we
need so many, and why do so many overlap and compete? The simple answer is many were created
to fill a need for a particular discipline. At implementation, they infer that alignment is required, but
in many instances there are substantial gaps in capabilities in other frameworks, and the scope of
each progressively creeps. Siloed frameworks are fat and unreliable. Aligned frameworks are lean,
mean and informative providing competitive advantage to the firm through which it can influence an
industry’s structure.
The alignment and integration of business frameworks is a necessary step in establishing the correct
organisational behaviours required to cope with the demands of the market, and exploit
opportunities.
Business frameworks contain the techniques and methods with which to achieve success, but the
political reality of achieving success is that until there is alignment and integration of these
frameworks, success is a fairy tale. Instead of delivering what they set out to achieve, they become
an obstacle to successful delivery.
This article will discuss the techniques available to an organisation to achieve alignment and
integration; however it does not provide an organisation with the political will and tools to
implement the most necessary piece, the organisational change management (OCM) of the
framework owners and stakeholders. Without the willingness of the executive to confront this OCM
issue, the advice given here is unusable.
From reading this document, you should have the foundation knowledge for the creation of a
transformation roadmap for alignment and integration of all your business frameworks. It is unlikely
that the alignment and integration is a single transition.
To begin this transformation, an organisation needs to embed some key business principles
including:
In instances where frameworks overlap, the organisation shall choose which process is
embedded on the basis of enterprise benefit
During the transition period of alignment, stakeholders key performance indicators will be
heavily weighted toward their ability to integrate
All frameworks are owned by the enterprise and there are no silos. 6 Sigma, Enterprise
Architecture, Business Planning, Marketing, ITIL, etc. are business unit, branch, and
executive agnostic. All associates of the business are stakeholders in all frameworks
The alignment and integration of business frameworks offers substantial financial benefits to
the organisation through the elimination of duplication and the expedited manner in which
strategy is developed and implemented
The personalities holding the stewardship of business frameworks tend to be difficult. With the
benefits and risk involved, the work should be commenced six months prior to end of year reporting,
and the deadline for completion must be end of year reporting. Tie substantial portions of
stakeholders at risk income to the successful completion of the implementation roadmap because:
The benefits to the organisation are substantial
There is risk to the business operating in an environment of disconnected frameworks
Substantial culture change benefits received through stakeholder collaboration and
compromise are created by the process
Step 1 – Current State Analysis
The current state needs is analysed and documented. An important point here is that this must be a
warts and all analysis of the ‘as-is’ and not the ‘should-be’. It is normal when a baseline is being
documented that a subject matter expert will be wanting to only suggest they do work the way it is
supposed to be done, what is required is to document activities the way they are actually done. To
successfully achieve the documentation of the baseline, the following are suggested:
Use only experienced business analysts who have the skills in challenging stakeholders and
can quickly spot stakeholders who are wanting to document the ‘should-be’
If in the current state, there is no value chain, do not create one. This step can be distracting
and it is too easy for stakeholders to claim they are providing a service they really do not. Do
not allow stakeholders to see an end-to-end view when documenting the current state.
Leave that to the business analyst to determine where the gaps appear, and to come back to
the subject matter experts to determine if there is are missing processes
The outputs to this step should be:
A full set of business processes for each framework
A full set of inputs and outputs used in process
Business requirements for the frameworks
Dependencies for the processes
Assumptions for the processes
Logical data mapping
Step 2 - Current State Matrices and Mapping
Now that you have a full set of processes, the analyst will create a large matrix. Essentially this is a
spreadsheet in which all the processes are in rows, with the same processes spread across columns.
Using the knowledge acquired from documenting the processes, mark each duplicated process in
another framework. (i.e.) gather requirements, create a project charter. Because the analyst has
collected all the inputs and outputs, it is now easier to determine if there are synergies between the
inputs and outputs, for instance, a document called a ‘project charter’ in one framework, might
contain identical information to a document called a ‘statement of work’.
Process Names
X
X
Figure: Process Alignment Matrix
Next create a database to determine the fit/gap for all the inputs and outputs used in each of the
frameworks. Some of these data objects will forms, screens, reports, and documents. The mapping is
cross-functional across all frameworks. An example of the output of this activity should be similar to
below:
6 Sigma PMO Architecture
Project Charter Project Charter Request for Architecture
number <id> project <name> identifier <id>
title <name> number<id> title <name>
scope <description> scope <description> scope <description>
objectives <description> objectives <description> benefit <description>
cost <value> cost <value> problem <description>
time <value> time <value> requirements <description
time <value>
Figure: Fit/Gap of Data Objects
Step 3 – Current State Business Model Canvas & Business Scenarios
A business model canvas (BMC) takes one to two hours to derive. It is possibly the most powerful
technique used in deriving business requirements, but it is rare this piece of work is undertaken. For
the purpose of achieving this outcome is critical.
The BMC is tested against business scenarios. Some elements of what is required to create a
business scenario were documented during the business process activity. The purpose here is to
check the business processes and BMC are actually capable of delivering their objectives.
The following information is taken from The Open Group Architecture Framework (TOGAF) and
suggests a business scenario should be thus:
Indicate which processes are similar
A business scenario describes:
A business process, application, or set of applications that can be enabled by the architecture The business and technology environment The people and computing components (called "actors") who execute the scenario The desired outcome of proper execution
A good business scenario is representative of a significant business need or problem, and enables vendors to understand the value to the customer organization of a developed solution.
A good business scenario is also "SMART":
Specific, by defining what needs to be done in the business Measurable, through clear metrics for success Actionable, by:
o Clearly segmenting the problem o Providing the basis for determining elements and plans for the solution
Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints
Time-bound, in that there is a clear statement of when the solution opportunity expire
The Overall Process
Creating a business scenario involves the following, as illustrated in Creating a Business Scenario :
1. Identifying, documenting, and ranking the problem driving the scenario 2. Identifying the business and technical environment of the scenario and documenting it in
scenario models 3. Identifying and documenting desired objectives (the results of handling the problems
successfully); get "SMART" 4. Identifying the human actors (participants) and their place in the business model 5. Identifying computer actors (computing elements) and their place in the technology model 6. Identifying and documenting roles, responsibilities, and measures of success per actor;
documenting the required scripts per actor, and the results of handling the situation 7. Checking for "fitness-for-purpose" and refining only if necessary
As stated previously, the purpose is to check the validity of the documented business processes and
business model canvas. The outcome of this step should be:
Verified and validated business processes
A completed business model canvas
Fit/Gap analysis of the processes and data
Duplication report across the frameworks processes and data
Important: The step is not for a business unit manager to expeditiously fill the gaps.
(Source: The Open Group Architecture Framework)
Step 4 - Enterprise Segmentation
Each business enterprise is a body of elements of the organisation at different levels. These
elements are often described as strategic, operational, tactical or perhaps enterprise, segment and
capability. For the purposes of this document, the following will be used:
Strategic: Elements that relate to the overall direction of the organisation. For instance,
determining the business mission and determining market goals.
Tactical: Elements that are required to implement the activities required to achieve the
direction. For instance developing and implementing business capability, monitoring and
controlling business unit performance, interventions and performance lever activities.
Operational: The organisational behaviours that result from the implementation of strategy.
For instance, the day to day operations of the business.
Figure: Initial Enterprise Segmentation
The next activity is to place all the business framework domains in rows of the Segmentation block.
At this stage there are no assumptions about where each domain fits. It is quite normal at this stage
to discover more frameworks. It is up to your project sponsor to determine if they want to bring the
remaining frameworks into scope. Analysis is required to determine the cost/benefit of bringing the
extra work in, and the outstanding risk associated with leaving them out of scope.
Figure: Enterprise Framework Segmentation with Domains
Each of the above framework domains contains a series of sub domains. For instance your enterprise
architecture framework may contain:
Business architecture
Data architecture
Applications architecture
Technology architecture
Your PMO may contain:
Project management
Organisational change management
Communications management
It will be necessary to document these and prepare a similar view to the one above. There will be
change to these domains where some capabilities, and / or functions, shift from one framework to
another. An example of this is: business architecture and change management successfully
implemented in some mature organisations as a human resource capability.
Below is the final output as it will appear after a few more activities. It is provided here to provide
clarity with where the activity is heading. The final part of the segmentation is to add dimension in
the form of time.
Figure: Enterprise Framework Segmentation with Business Framework Domains and Timeline
Step 5 – Enterprise Framework Capability
The objective of this step is to document the ability of the domains to continue to provide value. The
importance of this step is to ensure you are documenting the current state, and not taking into
account the vision of an individual business unit manager. The information is critical to analyse the
current organisational maturity existing in the capabilities, and to determine the areas the
organisation will likely accept and consume change.
Within each of the Enterprise Framework Domains are sub-sets as stated in the previous step
information. We will call the sub-sets ‘capabilities’. A capability is three elements: people, process
and tools.
The capabilities are decomposed to business process level. An example output:
Process Domain Sub-domain Roles Tools Incumbent Architecture
Business Architecture
3.5.6 Document Organisation Charts
Business Architect
Visio Sparx Word Excel
Contractor
6.9.2 Generate Business Scenarios
Business Analyst SQL Writer Visio Sparx Word Excel
Contractor x 2 Perm x 1 Temp x 3
Figure: Domain Capability Updated with Process Ratings
Using the information that gathered during Step 3, allocate a rating to the process. For instance, if
the process proved to be adequate to deliver the value required, it would be green, if there were
issues it is amber, and if it is insufficient, it is red.
Next allocate a rating to the role capability. To determine the rating apply the following logic:
1. Contractors or temporary employees occupying the roles ‘own’ the capability. They are
temporary resources and are a red flag
2. Permanent employees in the position for close to or more than two years are an amber flag.
If there is no career plan for these people they will either leave or become unproductive.
3. A role cannot be flagged green unless there is a permanent workforce, and a structured
method in which adequately experienced and trained people are transitioned into the role.
Process Domain Sub-domain Roles Tools Incumbent Architecture
Business Architecture
3.5.6 Document Organisation Charts
Business Architect Visio Sparx Word Excel
Contractor
6.9.2 Generate Business Scenarios
Business Analyst Visio Sparx Word Excel
Contractor x 2 Perm x 1 Temp x 3
Figure: Domain Capability Updated with Role Ratings
The final activity is to allocate a rating to the tools.
NOTE: Step 3 collected business requirements noting the gaps.
Repeat this activity for each capability in each domain. Red, Amber, or Green status is assigned a
value for decision support when the current state is analysed by executives.
Assuming Red = 0, Amber = 5, and Green = 10 the result for the above totals 35:
Domain Sub-domain Architecture
Business Architecture
Figure: Final sub-domain ratings
The activity is continued and rolled up to domain levels. Ratings at domain level are determined by
each domain’s ability to service its clients. Example:
0 to 40% Red
40 to 80% Amber
80 to 100% Green
Domain Sub-domain Architecture
Business Architecture
Data Architecture
Application Architecture
Technical Architecture
PMO
Project Management
Organisational Change Management
Schedule Management
Quality Management
Business Planning
Business Analysis
Strategy Development
6 Sigma
Analysis
Planning
Implementation
Step 6 – Workshop the Business
This step tests the mettle of the stakeholders. It requires facilitation by a strong personality
interested in the best outcomes for the enterprise. An external consultant best handles that role
because the outcome will ruffle a few feathers, and the facilitation role is a poison chalice for
anyone with career ambitions in the enterprise.
The minimum mandatory participants are:
The decision makers of each framework discipline
The roles that understand the inputs and outputs of each process
Representatives from each area of the business empowered to make a decision
The business analysts who documented the processes and capabilities
Executive observers
The activities that are required in sequence are:
Create business scenarios to implement an actual initiative of recent strategy.
Create a value chain/s to reflect the implementation
Associate the business processes that reflect the value chain
Assign key performance indicators and performance levers for implementation success
Align the value chain and processes to reflect their position in the enterprise segmentation
Now reverse the scenario and undertake the same steps to develop strategy
Document the benefits, gaps, assumptions and dependencies
The following questions require answers:
Is there a sustainable analytical framework represented at each level of the enterprise
segmentation?
Is there a sustainable delivery framework represented at each level of the enterprise
segmentation?
From an end-to-end perspective, does the business model canvas for the framework
disciplines support analysis and delivery requirements?
While the development and delivery of strategy are critical, the frameworks will need to be
flexible enough to cater for business as usual activities.
The reality is there will be huge gaps and substantial overlap of resources. An outcome like that
expressed in the cube below is likely. What you are seeking to create is a roadmap for the future
supported by sustainable capabilities that offer a career progression for candidates from an
internship all the way through to their MBA. At particular points of the progression the portability of
the candidates can be reflected, (i.e.) at this point a candidate is suitable for use as a supervisor,
branch manager, General Manager etc...
Figure: Completed Enterprise Framework Segmentation
Based on the current business culture, and the realistic expectation of implementing change, the
workshop will produce a likely long term target state for the capabilities and frameworks. Do not
make this target state reflect best-practice; it must be the target state that reflects the most likely
path for success within the organisation. For instance, if in best-practice a particular role or
capability is best handled by a Six Sigma Black Belt, but the reality in your organisation is that the
people with that certification are part timers in that role. Then, they are really not Black Belts at all,
and the likelihood of making them full time and focused is probably a pipe dream.
Step 7 – Selling it to the Executive through Sustainability
Remember the scope of what you set out to do. If you intended to deal with the duplication and
eliminate it totally, or whether you intended to deal with the duplication where it affects the
development and implementation of strategy.
Some duplication is acceptable where you have overlaps in capability that exist at different levels of
the enterprise segmentation to cater for business as usual work.
Executives will look at your plan and ask the following questions:
1. How much is this going to cost?
2. How sustainable is this?
3. What is the benefit?
Questions 1 and 2 require addressing a similar way. The sustainability of enabling and embedding
the roadmap requires capability planning. That is you will need to identify the resources you intend
to transition through the career pathways, the manner in which you intend to up skill them, and the
regularity at which you intend to introduce fresh talent into the pool to broaden your industry
knowledge. The sustainability of a capability in these areas is likely to always need outside help from
either contractors or consultants. Factor this into the plan, not to show the gaps, but to improve its
reliability as many critical roles will need exposure to broader industry to ensure you are aware of
trends and knowledge. Your costed plan must show any planned and justified growth in the
capabilities.
The benefits are in many forms. While it always politically difficult to show mistakes from the past,
sometimes a few “if we had done this when …” helps to localise the theory behind the restructure
and apply a pragmatic reality to the means. Larger organisations will encounter financial benefits
from a reduction in overhead through alignment and integration. The stakeholders who are
responsible for harvesting benefits must sign them off. Without their support, they are simply
numbers on a page.
The final page of this document contains an example roadmap.
Support the roadmap with details for its implementation such as:
Year 1: Project managers from 6 Sigma will transition to the PMO. Benefits include elimination of
disparate project management software licences, and improved project management capability
from project managers with business improvement experience.
Year 2: Business architecture functions from business planning will transition to enterprise
architecture. This will provide 100% utilisation of the current skills and eliminate the need to employ
contractors to complete the workload.
I hope you have enjoyed reading this paper and urge you to share it and comment. Feel free to
follow me on LinkedIn or link to me to gain access to more material.
© Copyright 2014 David Hilcher