This document outlines a process for aligning business and IT strategies through capability mapping, governance, and agile delivery. It involves mapping business capabilities needed to achieve strategic goals, defining supporting technical architectures, developing solutions, creating business cases, and governing projects. Approved projects are then delivered using agile methodologies to rapidly achieve business value through minimum viable products and iterative development. Regular measurement of value allows demonstrating returns to the governance body. The process aims to ensure IT strategies and investments support overarching business strategies.

2. This article outlines how I’ve tackled the
strategic alignment between the business
and IT through capability mapping,
governance and Agile delivery. It looks at
the overall process from a strategic business
objective, goal or idea through governance
to achieving business value.
Before I go into the detail, however, I thought I’d talk
about when this doesn’t work, in order to highlight the
importance of getting it right.

3. The Grey Area Between IT and the Business
This is the space between IT and the business where ideas and strategies are formed, and IT solutions are created and built.
Where, when done wrongly, a business strategy to release a new product results in another costly application built on top
of old systems, taking six months too long to attack the market.
This space can be filled with a variety of different people following a variety of differing processes (or often, none at all).
It’s where Business Analysts, Architects and Strategic Business Partners sit, but sometimes can be populated with
authoritative business “IT experts” providing the tech solutions to IT, as opposed to the business requirements. In a worse
case example, I’ve seen IT talking to the business about the business and the business talking to IT about IT – completely
miscommunicating.
When you get people and process wrong in this space, then the loudest person wins the IT investment. Tech is built
without alignment to the strategy, solutions are proffered over requirements and tech is built tactically creating legacy
debt, constraining agility in the future (and adding cost).
In the sections below I’ll describe the process I’ve used in the past and crucially, in my experience, what has (and has not)
worked. I’ll outline the CIO Hacks: the things that can make the difference between an abstract diagram and actual success
in a real environment.

4. High level view of Strategic Goal to achieving Business Value
The model to the right may look lengthy but
depending on the size of the investment or clarity
of solution can be very quick to achieve if applied
pragmatically. Ultimately it takes a business
strategic goal (or set of goals), maps the business
capabilities needed to achieve these and the
enterprise capabilities that already exist or need to
be built in order to fulfil those technically.
Solutions for those capabilities are then governed
through IT governance, business cases are created,
pragmatically detailed and designed in a way that
can be executed using agile methodologies, with
business value being delivered rapidly through the
Minimal Viable Product.

5. 1. Strategic Alignment
Running through the model with an example: the business identifies an
opportunity to expand a new product into a new segment. This is calculated to
growth the business by $500m and the organisation’s competitive advantages are
documented. Part of this advantage, let’s say, is using data the organisation
already holds to provide insight into this segment.
A capability mapping exercise is initiated that heatmaps the business capabilities
needed in order to be successful. The heatmap is generated against the
capabilities to show which ones exist and will support the strategy (green), which
ones exist but need modification (amber) which ones are lacking or missing
completely (red). To put this into context and depending on the level of
capability mapping this could be a macro capability like Customer Relationship
Management (CRM), or it could be major enhancements to the product engine,
or it could be the capability around using its data to create insights into its new
customer base. It’s the business capability not the technical solution.
The architects then dictate the right existing or new technologies to fulfil the
above capabilities. Note this is not the full solution only the architecture view on
how to achieve the capabilities, this might be an inhouse solution for CRM, data
feeds from internal systems into a data lake with a business visual reporting
technology sitting in top. It could be new off the shelf componentry or inhouse
development of existing solutions.

6. 1. Strategic Alignment – The CIO Hacks
In my experience getting a full set of relevant capabilities that span the whole business is the key. It allows IT to map current solutions,
map the business strategy and map strategic hotspots.
 Get the right business architect partnering with the right people from the relevant business departments. This could be an article in
itself. I’ve seen enterprise architects create these but in my experience, they tend then not to be business consumable. Someone
who intimately understands the whole business from IT is ideal (but hard to find at the right level).
 For the capability matrix itself you need detail but not at the expense of the time it takes to complete the exercise and /or losing the
value in pages of detail. Creating different summaries for different stakeholders can work. Be clever with what you leave out as not
relevant – but know you’ve left it out and be clear on the reasons. There are also plenty online for various industries, but I find
creating a customised one with your business’s language makes it far more effective.
 In one example I completely renamed the document from capability matrix (can lose people straight away as sounding “consultanty”)
and called it a “business skeleton”: “this is what we hang our business and IT strategy from”.
 Get the business buy in. Make this a joint deliverable between IT and the business (if the artefact is created within IT).
 Sometimes the exercise fleshes out the business strategy and can help document it.
The breadth and scale of this exercise can be designed for the problem. I’ve used it across APAC for all products and geographies or for a
single customer segment for one business unit, one geography. Ultimately it ensures a full analytical view of what’s needed to achieve
the strategy (not just what might be the hot potato at the time – “get this product in your configurator NOW” - but then on one thinks
about servicing the product) and helps prioritise the efforts of creating the individual solutions

7. 2. IT Governance
From our capability mapping we have a number of prioritised
missing capabilities. Solutions and business cases now needs
now to be governed. The artefacts created for governance
depend on the size of investment and clarity of the solution:
ranging from one pagers where the investment is small or the
solution clear and existing, to detailed feasibility studies
looking at technology solutions based on MoSCoW (Must have,
Should have, Could have, Won’t have) requirements.
The business cases are presented with the business
stakeholders representing and accountable for the value, IT
representing the solution and cost. Ideally this should not be
“another IT meeting”, achieved by mandating that the business
lead the investment proposals.
Part of the business case (alongside the normal ROI and
descriptions of the solution and business opportunity) is an
agile approach to delivery and a description of the MVP.
It’s worth pointing out that this sub process is also where new
business ideas and opportunities run through, things that
might be outside or in addition to the strategic goal.

8. 2. IT Governance – The CIO Hacks
There are a lot of “gotchas” in governance and I’ve seen a range of effective and not so effective forums; over participation (everyone attends and gives an opinion,
nothing gets decided), under participation / lack of engagement from the key stakeholders, the forum turning into an IT update session, unclear decision making authority,
lengthy business cases that take forever to complete, too frequent, too infrequent, not happening at all: the litmus test is are you making decisions? I’ve heard
governance described as making decisions on things you are not doing – if the IT portfolio is an ever-growing list of projects and business cases being worked on then you
know it’s not effective. There should be a clear set of projects, initiatives, opportunities that are below the black line (ie everyone agrees through governance they are not
prioritised and therefore not being actively worked on).
 It’s a lot of work to manage an effective governance and by underestimating this the result can be a badly prepared session isn’t effective at decision making. The prep
can’t be a side of the desk activity for a BA or PM, as it entails stakeholder coordination (the business, the architects, other BAs, finance, etc), creating a robust agenda
and creating pre-meeting reading in advance of the session. The lobbying for approval before the session should also not be forgotten!
 Know what you are doing there and why. Depending on the size, this could be a one page charter that outlines what everyone’s role is, decision making authority.
Don’t have sessions if there is nothing to talk about and keep the BAU in another place.
 Get the right people. They are the people usually accountable for the P&L. If you get too many interested parties then sessions can be bogged down with opinion and
“can we just go away and do X, Y and Z” before we make a decision. Don’t have the session if the key stakeholders can’t attend.
 Balance the documentation. Create thresholds for different sized investments so you are not putting together a 50 page business case for a 50k investment.
Constantly get feedback from the stakeholders on this.
 Communication. From the importance of the forum in the first place, to decisions and the progress of ideas and business cases: get it out there. Sticking it online with
#ownerNames can be useful so people are held accountable for their actions and decisions
 Make it business led. As described above, the business should be presenting the business cases, IT are there to facilitate and represent to IT solution and cost.
Lastly getting the right governance remit can be tricky: are you governing over a whole business, a business unit or an initiative? Are you governing over an IT team,
resources or budget? I’ve seen it work and not work in many of these areas, I personally think it works best when it’s not governing based on IT system, rather across the
business: rather than having a forum for governing system X spend, I’d rather have a governance forum across the business which incorporates system X (and Y and Z) – but
it does depend on the budgets and how IT is structured.

9. 3. Delivery
Following our example: the CRM project has been approved
through governance with the right funding. It’s utilising exiting
technology in the organisation but being implemented as part
of the sales process for the first time for this business unit. The
business case has laid out a clever way of getting value from
the CRM as soon as possible through an MVP that looks to map
the customer and sales hierarchy in the tool and deploy within
2 months alongside the integration of existing sources of data
into the system. The MVP also incorporate the redesign of the
business process.
The MVP is delivered and the expected value is measured
against the business case. Then measured again as additional
sources of data are integrated into the CRM in subsequent
sprints, each milestone goes back to the governance team to
approve the continuation of the project (along side other
investments).

10. 3. Delivery – The CIO Hacks
There are plenty of articles (and careers) on delivery and I’ll talk about my experiences
and thoughts around implementing agile in a waterfall organisation in another article
but in the context of supporting the business strategy I think the important point is the
following:
 Once the MVP has been achieved and value has been delivered, the ability to
measure that value and link back to the business strategic goal through the business
case and capability mapping should demonstrate a quality IT investment portfolio –
however I’ve never seen this stage done very well. Getting the right business
stakeholder’s ownership alongside an excellent Product Owner is key and ensuring
the governance forum mandate measuring the return on investment.
Please add comments below or email me at stuartfisher76@gmail.com

11. Unsullied diagrams follow
1. Overall model
2. Strategic Alignment
3. IT Governave
4. Delivery
Appendix

12. Strategic Business Goal
Business Architecture
Technical Architecture
Solutions
Business Cases
Execute
Business Value
AlignmentofITstrategy
tothebusinessstrategy
ITGovernanceDelivery
AgileCapabilityMapping
Regular.Non
Bureaucratic

13. Strategic Business Goal
Business Architecture
Technical Architecture
Growth targets in new customer segments with new products /
Operational efficiency targets
Using capability mapping, map out the business capabilities
needed to achieve the above business goal
Enterprise architecture then creates a roadmap for new or existing
enterprise assets
Solutions
Business Cases
Execute
Business Value
ITGovernanceDelivery
Agile
Regular.Non
Bureaucratic

14. AlignmentofITstrategy
tothebusinessstrategy
Technical Architecture
Execute
Solutions
Business Cases
Technical solutions are developed following the architecture
roadmap. The solutions reuse existing enterprise components
where possible. Feasibility studies may be conducted to asses the
viability of the solution.
Business cases are created and presented to a regular governance
body where the business represents the value and IT the solution.
Delivery is designed in a way that business value can be achieved
quickly through a well defined MVP.
Strategic Business Goal
Business Architecture
Business Value
Delivery
AgileCapabilityMapping

15. Strategic Business Goal
Business Architecture
Technical Architecture
Solutions
Business Cases
AlignmentofITstrategy
tothebusinessstrategy
ITGovernance
CapabilityMapping
Regular.Non
Bureaucratic
Execute
Business Value
Approved projects are funded and resourced and delivered in an
agile methodology where possible
Business value is achieved as soon as possible through MVP and
then through each sprint, major milestones are then reached and
the value is measured to take back to governance where
appropriate