When IT is your responsibility but not your primary area of expertise, it can be difficult to figure out how to gain the IT capabilities that you want while ensuring you have the IT security that you need.
Talking to IT service providers seldom clears the fog of uncertainty and asking peers what they are doing can be fruitless – Each organisation is unique, with different risk tolerances, priorities, and capabilities. It’s enough to drive you to drink.
My defined roadmap can help you work through the process in a pragmatic and sane way. And just like Alcoholics Anonymous, it involves 12 steps.
The 12 steps are grouped into the 4 phases of what I call the ‘W4 methodology’, with each phase delivering a specific outcome.
Executive Summary
4 phases. 12 steps. 1 image.
Click the image to view a PDF version
WHERE
The WHERE phase focuses on where you are right now, where you could go, and where you want to go. This is not only informed by the technical possibilities and current capabilities, but also by the expectations of your stakeholders and regulators.
Step 1: Assess
Assess where you are today – in terms of technology, capability, constraints, concerns, risks, and stakeholder needs.
Step 2: Discuss
Discuss where you could go – In the next 12 months, we discuss what could you do, within the realms of possibility.
Step 3: Agree
Agree where you will go – Informed by what emerges from steps 1 and 2, we discard the impractical and focus in on what you the pragmatic, logical, achievable place.
WHAT
Now we know where you will go, the WHAT phase focuses on how you get there:
Step 4: What
What do you need (technology, capability, etc)
Step 5: How
How do you get what you need?
Step 6: When
When should you get these? What order makes sense?
WHY
You are now in a position where you are clear on where you want to go and how you can get there. Now it’s time to explain to your stakeholders (e.g. Compliance and Risk, C-Suite peers, CEO, Board members) why this is the right answer for your organisation.
As an aside, by the time you get to this phase, you will be far more comfortable talking in plain English about technology.
Step 7: Document
You will have documented your work at each step along the way, but now it’s time to put it into a shape that can be circulated to stakeholders for further discussion and clarification.
Step 8: Engage
You will have engaged stakeholders informally along the way. Now it’s time to engage them on a more formal basis, talk them through what you are planning to do and how you will do it, and verify that it all aligns to their needs and expectations.
Step 9: Agree
All stakeholders are on board. It’s time to formalise the agreement and get the funding allocated. Depending on your organisation and the formality of its signoff process, this step may occur as part of Step 8.
WHAT NOW
You have a clear goal, a clear path, and buy-in from your stakeholders.
Now comes the easy bit – Doing it.
“How do you eat an elephant? One bite at a time.”
I recommend that you adopt an iterative approach to the implementation, especially if the level of change involved is significant. After each iteration, you will have a better sense of what is achievable and what needs to be reviewed.
You will have identified the high level iterations during “Step 6 (When)”. However, you may want to refine or rework these to reflect insight you gained from your engagement with stakeholders in steps 7-9.
For each iteration, you should follow the 3P’s approach:
Step 10: Plan
Plan what will you do in this phase, who needs to be involved, how long will it take.
Step 11: Progress
Do what you planned to do. Track it. Beat it into shape.
Step 12: Persist
Once this iteration is done, you have moved closer to your stated goal, so you need to ensure that your new baseline persists.
About the Author

Sam works with the CFOs and COOs of regulated firms who are responsible for IT, even though IT is not their primary area of expertise.
They are frequently under pressure to deliver capable, secure and compliant IT solutions that align to the risk appetite of the firm’s internal stakeholders and to the expectations of regulators.
It’s not about technology. It’s about business outcomes.