1. Do create a robust business case
If the proposed transformation doesn’t stack up on paper, it won’t miraculously stack up when you start committing real money, as a rule costs go up during delivery, not down.
A robust business case is critical to ensure the planned changes are justified and can be afforded (before work starts), and that the resulting run costs post transformation are favourable.
Ensure that the “hidden” costs are included in the run part of the business case especially if planning a migration to the cloud, but similarly ensure that things like volume discounts are factored in as these could make the difference between an approved or rejected business case.
Do ensure contingency and cost tolerance is included based on sensible assumptions about things that may fluctuate like exchange rates, human resources required, more or different infrastructure being required, greater time required to resolve problems. Be sure to price in any unknowns too with sensible estimating.
Once the business case has been created, use it frequently to validate spend and check that what was planned financially is still on track.
2. Do get requirements and designs signed-off
If you are not clear about what has been requested (requirements) and how these will be achieved (design), you won’t know if, and when the transformation has been successfully delivered.
Further to this, clearly approved requirements and designs enable traceability from the desired business outcomes to the requirements to the design and ultimately the delivered solution.
Do document requirements, do get them signed off in advance by the beneficiary of the requirements. Do ensure designs on paper are created and signed off and used to validate that the solutions will work before committing infrastructure and resources and do ensure that the designs on paper are within the cost parameters of the business case.
3. Do focus on non-functional requirements
Despite the growing maturity of the IT industry, non-functional requirements (NFRs) still seem to be a dirty word.
Often an after-thought rather than what should be the first thought when planning an infrastructure transformation, not sexy like an application’s functional requirements, but guaranteed to stop an infrastructure transformation in its tracks if not handled properly.
Infrastructure is all about the non-functional requirements, so it is essential to clearly understand the business requirements around up-time, resilience, disaster recovery, scalability, data recovery times, data loss times, bandwidth, throughput and security.
Failing to understand the non-functional requirements and providing suitably sized infrastructure will either mean the system and therefore the business will suffer operational outage at some point, or you have spent far too much on a solution that wasn’t warranted.
4. Do ensure the transformation has a strong sponsor
A strong sponsor is critical for any significant change and infrastructure transformation is no exception. Far too often infrastructure transformation programmes fail due to weak or inadequate sponsorship.
The role of the sponsor is to lubricate the path of the transformation with the business and assist in clearing obstacles or maintaining progress when there are headwinds.
The sponsor is often the prime beneficiary for any change but doesn’t need to be. From experience senior stakeholders from IT Audit, Finance and Risk make good sponsors as well as the obvious candidates from IT. Being a sponsor requires a certain set of skills, so chose your sponsor wisely (if you have a choice) and remember not all sponsors are equal.
Once the sponsor is in place, ensure that they clearly understand what is required of them. Don’t assume everyone knows what is expected of them and what they should be doing – a sponsor is no exception.
5. Do consider the service as well as technology
Frequently, major benefits associated with infrastructure transformation come from the opportunity this offers to change service, or in other words change the people and process surrounding the technology. Changing technology alone will never maximise the value that can be derived from an infrastructure transformation.
When considering the business case, the cost of service is a massive contributor to the run cost, and service should be given equal importance in designing the end-to-end solution as the technology solutions. Be sure to get this right to avoid the need for subsequent transformation and/or transition in the short-term.
The adoption of cloud solutions doesn’t remove the need for service. The focus of the service may change, but it is critical that this is not overlooked.
6. Do have a robust plan and structured delivery framework
The old adage “failing to plan is planning to fail” is still as true as ever when it comes to infrastructure transformation.
Plans should be considered from a top-down perspective creating a framework of similar items or groupings supported by plans created from the ground up detailing how the high-level outcomes will be achieved. Do ensure that the plans, and associated resources and durations are reflected in the business case.
Plans are used for multiple reasons ranging from supporting communication, enabling team members to see what tasks are allocated to them, considering and testing the order in which tasks must happen, generating conversation, calculating the resources required, understanding what the critical tasks are that if they don’t happen on time will lead to delay.
7. Do employ good communications with all stakeholders
All aspects of life benefit from clear communication, and infrastructure transformations are no exception.
Communication should be planned and targeted towards different types of stakeholder.
Communication should start early, notifying what is changing and why, and be used to secure support and set expectations. As time gets closer to actually making changes, communication must become more frequent and detailed informing of outage and again any operational changes. Careful consideration should be given at this point to ensure all the right people get the right messages. Communication should be specifically targeted at the business and operational providers of the service as it transforms.
Finally, communication should continue following a successful transformation to remind stakeholders of the benefits that have been delivered and ensure there is a way of feeding back comments and concerns.
8. Do foster a sense of team
A team is much stronger than a group of individuals. A team will self-organise and communicate amongst itself outside formal meetings and direction, a team will want to succeed together, a team will have each other’s backs.
Transformation leaders must set the tone accordingly and include and treat all contributing people, 3rd parties, suppliers into the team. Ensure all parties know and understand what other parties are doing. Run a regular meeting where all parties get chance to rub shoulders. Use Microsoft Teams or similar, to establish a place for the team to communicate and store documents.
1. Don’t assume everyone is always on the same page
Don’t be afraid to ask silly questions (there’s no such thing as a silly question!), repeat yourself, check the obvious, confirm that tasks have been completed and ensure that the left hand knows what the right hand is doing.
Technical SMEs do overlook things and make mistakes. Being a good team member means watching over each other. Relying on assumptions has proved time after time to be dangerous and usually leaves you with egg on your face, wishing you had just asked that one “stupid” question.
2. Don’t overlook testing
With applications and their functional requirements there is so much to test, but with infrastructure it is also critical to test during and after a transformation. If you have adhered to clearly documenting requirements and solution, then deriving the test plan from this should be (relatively) easy.
Ensure maximum loads and throughput are tested, ensure fail over and Disaster Recovery (as soon as you can) are tested, validate that backups (and restores) are working in production as required, check all management consoles can be reached, and all monitoring tools are active and reporting
Finally, don’t forget to test the security measures and ensure unwanted intruders cannot access any part of your infrastructure.
3. Don’t believe everything you are told
It is easy to believe the things you want to hear especially when they will reduce your workloads and make your life easier, but are the people saying them actually authorised to do so and are you wise to believe them?
A prime example of this is a CIO stating that it is OK to take a system offline to ensure delivery is met within time and budget constraints, but not actually authorised by the business to make such a claim.
Just because someone is senior, doesn’t mean they are authorised to make every call. Check the information is coming from the horse’s mouth before acting on it.
4. Don’t think that significant savings can’t be made
Time and time again I have seen major MSPs and ISPs claiming that a team of 50 or 60 people (often mostly offshore) is justified to deliver a service that in reality can be provided by a much smaller well-trained and organised team for a fraction of the price.
Depending on the size of your organisation and infrastructure footprint, millions of pounds a year could be removed from your operating costs whilst maintaining or improving the levels of service.
5. Don’t settle for a service model that doesn’t fit
Building on the point above, major MSPs are not set up to deliver a bespoke service aligned to what the customer really needs. The MSPs want customers to conform and fit into the systems and tools they have invested in even if these are not what is really required.
To maximise the benefit and value that can be derived from an infrastructure transformation the service and the supporting tools will likely need special consideration.
6. Don’t overlook the hidden costs of infrastructure in the cloud
The cloud is great, but not always necessarily cheaper than more conventional infrastructure hosting. So, when considering the requirements and the business case think carefully about the run costs of the future solution and whether there is a preference for Opex vs. Capex funded infrastructure.
With the cloud you pay for everything, and not once, but month after month.
If you forget to turn something off or un-reserve it you pay for it month after month, if you elect for a service like a hardened image you pay for it month after month instead of developing it, deploying it and paying for it once.
Data transport costs are another real killer. Failing to consider and include these in the business case will make you very unpopular if these hidden costs start to bite once the transformation is complete.
7. Don’t overlook Security
Cyber security should be the responsibility of everyone in an organisation, but technically speaking it is secured at its foundation through the infrastructure and the choices made around this.
Don’t forget to secure your networks, hosting platforms, end user devices, ingress points, and put in place tools to monitor various attacks from DDOS to phishing.
Overlook this at your peril. Ensure adequate budget is baked into the business case for this. Don’t make security an after–thought. Do consult from day one of planning an infrastructure transformation with security staff and CISO.
8. Don’t just move things because they are there
When considering an infrastructure transformation especially around hosting and platform, simply moving stuff is usually not the answer.
The first thought should be around whether the business still requires the application and for how long? Frequently, poor housekeeping means that on-prem systems are left running long after they are required. Establish, if retiring applications is possible immediately or if retaining for a short time in the legacy state then retiring is the best option for the business case.
Where retiring or short-term retention is not an option, the choices are re-host, re-platform, re-purchase or re-architect. All should be considered in equal measure in terms of future requirement and cost of transformation and run.
How IT Naturally Can Help
IT Naturally can support any business in planning and making infrastructure transformation a success and works with SMEs to global enterprises.
IT Naturally will work closely with your infrastructure teams, applying the dos and don’ts from above to understand and analyse your current estate, identify your requirements, and design and deliver homogeneous technology and service solutions using IT Naturally’s Service Desk, Service Management and network, platform, security and desktop experts.
Please contact us to learn more about how we can help.