Delivering IT solutions in 2015 can no longer be a matter of creating a fat set of design documents, throwing this over to the developers to build, for them to then throw over the fence for operations to run. Actually, that was never the right way – but we know better now, right?
Digital Transformation is the objective of many large companies, but truly this is a Digital Revolution for most of them. For the CIOs and CTOs this is too often focused on the technology and their annual budget. This misses out the importance of cultural and structural changes that are required to implement an effective long-term delivery and operational model. That is organisational level change, not IT change.
In 15 years I’ve seen the delivery of IT industries change from on-premise, to application service provision, to managed services, platform as a service and hybrid cloud. At the same time, we’ve moved through the ‘proven‘ waterfall methodology, through extreme programming and settled nicely on Agile. Disconnected from most of this is the business – who still see IT as running late, over budget and not actually delivering the value that they need.
Within the remit of IT, I see three core elements that make a huge difference in helping to deliver better: Automation, Cloud Adoption and Change Management.
Automation, in the sense that I’m advocating, is largely encapsulated in a DevOps culture of delivery. A culture, not a role.
A DevOps culture looks to deliver an integrated design through to operation solution. It also recognises that digital solutions are rarely ‘finished’; websites need updating, systems need to integrate with third parties, the business needs new functionality to match market trends and changes.
Automation features highly in this delivery culture, where manually completing repetitive tasks is risky and costly – more in terms of opportunity cost than in salaries. Tooling these days also means that automation is much more than testing. With infrastructure as code, you can now have self-healing, auto-scaling, on-demand systems.
Get smart people to work on tough problems, leave the handle cranking to a script wherever possible.
The much hyped ‘cloud’ is more than just a space to deploy your applications. Over the past few years many enterprise solutions have been built in the cloud. This allows you to better deliver core systems outside of your legacy applications.
Salesforce is one of the most obvious examples. As a CRM and Service Management platform, it provides a compelling alternative to almost any other bespoke or legacy system.
However the cloud also offers more in the way of how we, as IT, can deliver better. With elements like cloud based code control, build management, backlog management and global load testing, most with on-demand payment plans, you get to utilise the very best solutions that deliver greatest ongoing value.
Broadband speeds mean that we’re even taking our desktop environments to the cloud more and more. Microsoft, Adobe and Google all offer browser-based subscriptions for their key products – no longer just limited to email.
Cloud storage is also much more than the place that you keep your system databases and archives (although with things like AWS’s Glacier that can be crazy cheap). Instead most people now have a Dropbox, GDrive or similar service which forms as much a part of their desktop environment as their C drive.
Putting everything in the cloud makes it so much more convenient – not only to access wherever you are, but also to interact at a business level with your suppliers, partners and customers.
Where is management in all of this? Agile doesn’t even recognise the role of Project Manager in a delivery, favouring self organising teams – does that mean that senior management no longer has a place in delivery?
I’d argue that the role of Project Manager is largely redundant for smaller deliveries – where the business and IT teams are fully committed to an Agile way of working. The Product Owner leads on the ‘what’, ‘why’ and ‘when’, whilst a multi-functional delivery team lead on the ‘how’.
For larger programmes, I am yet to see how this can be delivered without formal management. That isn’t to imply this is the sort of ‘management’ that tells clever teams what to do, but rather runs communication, prioritisation and stakeholder engagement across a span of projects.
This Programme Manager then becomes an agent of change management and communication. Their responsibility is to set and manage the expectations of what it means to deliver in a digital world – to development teams who are often in the details of their specific delivery and to the business stakeholders who are often siloed in their domain of delivery.
IT sits at the heart of most modern companies of any size. As such, we need to know which projects are running, how they fit into an existing IT landscape and how they will fit into the future IT landscape.
Product owners continue to represent their business areas, whilst the Programme Manager looks at the entirety of the IT investment with a healthy detachment from any single business interest.
To my mind, this means that you should ideally have a Programme Manager who is able to sit with the business and provides input into the overall business strategy to best align IT spend. This aims to ensure that delivery isn’t just servicing the loudest stakeholder’s demands.