I’ve recently been involved in a number of digital transformation projects and wanted to share some lessons learned in this blog.
Firstly, there’s no one-size-fits-all approach to successful digital transformation, so it always helps to start with a why. For instance, why is the company considering digitalisation? Perhaps the competitive landscape has changed or some of the existing business models are becoming less relevant in light of new technological trends.
Regardless of the reasons, I would argue that no special digital strategy needs to be developed. Rather, we need to to see how digitalisation supports the overall business strategy, and how digital trends affect your company.
While strategising in the boardroom helps, keeping customers in mind is paramount. Rather than simply digitising existing business processes (such as going paperless), it’s useful to think about them as multiple customer journeys to maximise the value for the consumer.
Design thinking is a good method to use when approaching this, as it helps to create a customer-centric solution. It begins with a deep understanding of customer problems and iterates through prototyping, testing and continuous feedback. This process also aligns well with modern iterative frameworks for software development and broader agile working.
Learning from feedback on your minimal viable product (MVP) helps to refine your initial assumptions and adjust the approach where necessary.
For example, adopting and combining technology like Cloud, Big Data and Machine Learning can help improve the decision-making process in one department, so it can then be adopted by the rest of the enterprise once the business benefits have been validated.
Having a clear data architecture is key in such transformation. It’s rarely about just building a mobile app, but about making better business decisions through effective use of data. Therefore, before embarking on any data analytics initiative, it’s imperative to be clear on why the data is being collected and what it’s going to be used for.
While working with a Power and Utilities company, I helped them securely combine Internet of Things devices and Cloud infrastructure to connect assets to the grid, analyse consumption data to predict and respond to demand and automate inventory management. As outlined above, it started with a relatively small pilot and quickly scaled up across the enterprise.
Yes, traditional companies might not be as nimble as startups, but they have other advantages: assets and data are two obvious ones. Digitalisation can help make this data actionable to better service the customers. To enable this, such companies should seek out not only opportunities to digitise their core functions, but also find new growth areas. If some of the capabilities are missing, they can be acquired by interacting with other members of the ecosystems though partnerships or acquisitions.
It’s not all about technology, however. People play a key role in digital transformation. And I’m not only talking about the customers. Employees in your organisation might have to adopt new ways of working and develop new skills to keep up with the pace of change. Recruitment requirements and models might have to adjust accordingly too.
If you would like to learn more, there’s a free online course on digital transformation developed by BCG in collaboration with the University of Virginia that provides a good summary of current technology trends impacting businesses. Feel free to jump straight to week 4 for the last few modules discussing their framework and some case studies if you are after more practical advice.
I have worked in the Operational Technology (OT) environment for years, predominantly in major Oil and Gas companies. And yes, we all know that this space can move quite slowly! Companies traditionally employ a waterfall model while managing projects with rigid stage gates, extensive planning and design phases followed by lengthy implementation or development.
It’s historically been difficult to adopt more agile approaches in such an environment for various reasons. For example, I’ve developed architecture blueprints with a view to refresh industrial control assets for a gas and electricity distribution network provider in the UK on a timeline of 7 years. It felt very much like a construction project to me. Which is quite different from the software development culture that typically is all about experimenting and failing fast. I’m not sure about you, but I would not like our power grid to fail fast in the name of agility. The difference in culture is justified: we need to prioritise safety and rigour when it comes to industrial control systems, as the impact of a potential mistake can cost more than a few days’ worth of development effort – it can be human life.
The stakes are not as high when we talk about software development. I’ve spent the past several months in one of the biggest dot-coms in Europe and it was interesting to compare and contrast their agile approach to the more traditional OT space I’ve spent most of my career in. These two worlds can’t be more different.
I arrived to a surprising conclusion though: they are both slow when it comes to security. But for different reasons.
Agile, and Scrum in particular, is great on paper but it’s quite challenging when it comes to security.
Agile works well when small teams are focused on developing products but I found it quite hard to introduce security culture in such an environment. Security often is just not a priority for them.
Teams mostly focus on what they perceive as a business priority. It is a standard practice there to define OKRs – Objectives and Key Results. The teams are then measured on how well they achieved those. So say if they’ve met 70% of their OKRs, they had a good quarter. Guess what – security always ends up in the other bottom 30% and security-related backlog items get de-prioritised.
DevOps works well for product improvement, but it can be quite bad for security. For instance, when a new API or a new security process is introduced, it has to touch a lot of teams which can be a stakeholder management nightmare in such an environment. A security product has to be shoe horned across multiple DevOps teams, where every team has its own set of OKRs, resulting in natural resistance to collaborate.
In a way, both OT and DevOps move slowly when it comes to security. But what do you do about it?
The answer might lie in setting the tone from the top and making sure that everyone is responsible for security, which I’ve discussed in a series of articles on security culture on this blog and in my book The Psychology of Information Security.
How about running your security team like a DevOps team? When it comes to Agile, minimising the friction for developers is the name of the game: incorporate your security checks in the deployment process, do some automated vulnerability scans, implement continuous control monitoring, describe your security controls in the way developers understand (e.g. user stories) and so on.
Most importantly, gather and analyse data to improve. Where is security failing? Where is it clashing with the business process? What does the business actually need here? Is security helping or impeding? Answering these questions is the first step to understanding where security can add value to the business regardless of the environment: Agile or OT.
Agile frameworks are gaining momentum in software development and beyond. One of them, called Scrum, caught my attention recently.
I’ve had a privilege to work in one of the biggest dot-coms in Europe and immerse myself in the agile environment. I’ve had an opportunity to witness first hand that efficiencies gained through adopting an agile method cannot be underestimated.
To structure my knowledge and practical experience, I’ve decided to study for the Certified Scrum Master (CSM) exam offered by the Scrum Alliance.
I can highly recommend the two-day course which is a pre-requisite for the certification. This short module helps put everything into perspective and allows you to practice some of the key concepts in a safe environment during a number of workshops. For example, I’ve had an opportunity to work with the product backlog, facilitate sprint planning and retrospective sessions and write user stories.
It also clarifies the role of the Scrum Master in the team as a servant-leader and his/her relationship with Product Owner and the development team.
Find out more on the Scrum Alliance website.