I thought I’d do something a little different for my first post in 2025. I’m usually something of a security magpie, writing about some fun technology or new(ish) development, but this time I’m going to write something a bit fluffier, about some lessons learned delivering real change in large enterprises. For context, I’ve been lucky enough to work on some seriously large technology-enabled transformations across both private and public sectors; the things I will write about below are drawn from practical experience. Of course, it’s my own practical experience and so others will have different perspectives and preferred approaches, but I’m hoping enough of it is transferable to be of some value to others!
Firstly, it’s important to understand the
context of the change you are hoping to make. Know where you want to get to
(and why!) and where you are starting from. This covers a wide range of considerations
(not in any particular order):
- Business context – why do your stakeholders want this change to happen? Do you still need to do a job of convincing the stakeholders to fund the change? Change requires cash. What will the business get for its money?
- Stakeholder context – do you know who the key stakeholders are? Who will pay for the change? Who will be impacted by the change? Who will see the change as a positive and who will see the change as a negative (either personally or organisationally)? Don’t assume your stakeholders are idiots. If you see something that looks plain odd or weird, ask around and find out why things are as they are. Yes, sometimes things are horrible but there is often a reason behind that status. (And, yes, sometimes folks do make curious decisions – but validate, don’t assume).
- Technology context – can you actually do what you want to do, within the timeframe you want to do it, with what you know of the current and target technology landscapes?
- Agree, and enforce, the Vision. I can’t stress this one enough. Everyone needs to know the target state and why it is the target state. The Vision needs to be owned and supported by someone with enough organisational heft to stop different parts of the organisation from diverging from the overall Vision. You may get folks who are not 100% aligned with the rationale, approach or Vision itself – you need a suitable authority to be available to corral dissenters (alongside offering an opportunity for constructive input). Perfect is the enemy of good, better than current state is better than current state. Progress is important and you can’t get dragged down by continual discussion prior to doing stuff – not least because you are burning time and money whilst you wait, plus risking missing out on the benefits of the change (particularly if they are time-critical).
- Agree success criteria and definition of done. How will you demonstrate that the initiative has successfully completed? What metrics will you use to demonstrate progress along the way?
Okay. So let’s say that we now know who our
key stakeholders are, what we want to do and why we want to do it. We then need
to do it. Some thoughts…
- Skills. Know when you need specialist support. Don’t try and force generalists into specialist roles. Some degree of stretch is good – it gives folks an opportunity to learn – but don’t put people in roles where they are being set-up to fail. Mentor and support, get them help if needed.
- Trust. If you’ve spent time putting together your team, trust them to get on with delivery. Do NOT micromanage. It destroys enthusiasm and only corrodes team spirit. If you don’t trust someone to do the job you’ve asked them to do, bring in someone you do trust. The folks on the ground will have a better handle on what is happening from a practical delivery perspective than programme leadership. Listen to their concerns and help to remove blockers. Advice from leadership can be helpful. Cross-organisational insight from leadership into the context behind the blockers can be useful. However, if delivery folks are escalating an issue, it’s usually because they want some help – giving them further actions is not helping. See what burdens you can take off them and what barriers you can remove for them. Help and lead, don’t hector and belittle.
- Lead by example. Every so often, teams will need to work long hours and/or do tedious work. Roll your sleeves up. Do some of the nasty stuff if you can. If the team sees that you are willing to spend long hours buried in the latest Spreadsheet of Doom, then it helps to build a degree of team spirit – that we really are “all in this together”. If you commit to do something for your team, do it. You expect that of your team, they have every right to expect that of you.
- Track progress. Yes, project management matters. I’m not going to pretend that this is the bit of the job that I most enjoy, but I do recognise that we need to be able to demonstrate progress to stakeholders. (Seeing milestones hit, or backlog items delivered, is also good for team morale. People like to see their efforts having an impact!). Know your critical path and dependencies, work backwards to make sure that what you want to achieve is achievable given wider constraints.
- Communicate. This ties into the above… you spent a lot of time identifying your stakeholder community, you really need to keep in touch with them. Let them know how the initiative is proceeding. Ask them for help if you need it – senior stakeholders are often keen to help as it justifies the time they are spending meeting with you.
- Meet with purpose. This ties into the above… (again). Communication is good. It’s much better if meetings and communications have a clear purpose though. If you’re getting time with senior folks, be very clear about the purpose of the meeting, be diligent about preparation for the meeting and have some defined required outcomes. I’ve found few things irritate very senior folks like having their time wasted through attending a call where the preparation hasn’t been done, resulting in the need for yet another call. Don’t irritate very senior folks without due cause, it’s not helpful.
- Delivery methodologies. Pick the right tools for the job – whether project management, architecture frameworks or industry standards. But don’t be dogmatic and do NOT assume that everyone has the same understanding of what you may think of as standard industry terms. Establish a common taxonomy as part of agreeing the overall methodologies.
- Quality is important. I’m a pedant. I know this irritates my team on occasion. However, I am unrepentant. I think it’s important for documents to be of a high standard, typos and grammatical errors are distracting for the reader, whilst any internal contradictions or lack of appropriate definition of terms just leads to confusion or (worse) incorrect interpretation and follow-on action. Be clear, be concise, be accurate.
- Respect reality. Requirements may change during the course of an initiative. You may encounter unexpected obstacles, perhaps even insurmountable obstacles, during delivery. I’m not going to go into the basics of change management here, but I do want to stress the importance of recognising when things move from difficult to (practically) impossible. Don’t risk burning folks out trying to do the impossible.
- Enjoy yourself. We only have one life. We spend a lot of that life at work. Try to be a nice person to work with, or work for. Respect others, help others, try to have fun – just because what you’re doing may be deadly serious, it doesn’t mean that you can’t try and enjoy the experience.
And I think that's where I’ll stop for now.
It’s probably a bit motherhood and apple pie for those who have been around for
a while. I acknowledge that there are lots of books out there around project
delivery (although I do keep having an urge to write something around enterprise
security architecture and change, apologies in advance should I succumb). I’ve
just had an itch I wanted to scratch for a while about jotting down some of the
things that I’ve found helpful over the years, alongside some of the things
that I’ve found less than helpful. I sometimes see folks entering the security profession
wondering why things don’t “just work” or don’t just get fixed. I’m hoping the
above helps to provide a bit more insight into the kind of things that need to
happen, or at least should happen, to actually drive positive security transformation
in large organisations.
Itch scratched.
