Using our skill and wide-ranging experience to deliver automation in a Tier-1 client.
One of our most recent projects was delivering lifecycle automation for a Tier-1 client. As with any and every “DevOps project”, there were a number of challenges we overcame when delivering the project. In this blog, I will talk about some of the hurdles we came up against and how we managed to work through them, as well as some of the project successes.
We see a few common challenges in some form or the other at every client we work with. The way we work through these challenges and overcome hurdles is where our skill and wide-ranging experience in delivering this type of DevOps project really come into their own.
These are some of the challenges we came up against on this project:
1. Lack of awareness that change management is a critical part of successful implementation
On paper, implementation and roll-out of automation sounds quick and easy. But we know that technical and cultural change management (ensuring that the process, culture and system changes take root in a team and work effectively) is something which needs time. Implementation and roll-out across teams can be rushed but it usually doesn’t work in the long term! There will be some team members who are reluctant to adopt the new culture and processes, and as soon as the “project spotlight” has faded, they will revert to what they know well, and stay in their comfort zone.
Resolution
Right from the start of this project we evangelised change management, sharing our change management expertise, setting the client expectations and detailing the steps required to instil the cultural changes in the team. However the client chose to do its own change management using resources unfamiliar with DevOps. This put extra pressure on the delivery but we continued with the project, supporting the client where we could. For instance, we brought in an extra resource to work closely with the users and help to get services onboarded to the new process, while listening to feedback and evolving the systems to provide maximum user experience.
2. Resistance to cultural and process change.
During the project roll-out, we needed to engage with teams who hadn’t been involved in the early project phases. They were minor stakeholders who resided in a different department and didn’t have the senior management mandate to support our project. They were not willing to start using the automation solution which had been signed off by all other departments.
Resolution
We listened to their feedback, their concerns, their pain points and made a few modifications to our solution. We also engaged our senior stakeholder who worked with their department manager. Together we managed to find a way to implement our solution which was acceptable for the team.
3. Too many stakeholders delaying signoffs
We worked with the client teams to gather requirements, understand their bottlenecks, pain points and their goals. However pinning down the right person to give us formal approval on our proposals was difficult as there were too many stakeholders who could “potentially” give us signoff. This hampered progress in our project as we had to delay moving on to the next stage of the project at certain times.
Resolution
Ultimately, identifying stakeholders for each decision had to come from the most senior stakeholder who was funding our project. We asked them to delegate clearly which person was required to sign off each stage.
4. No team available to take ownership of new functionality post project
Another issue was that it hadn’t been formally identified which team would be responsible for owning and supporting the new functionality once the project delivery team had completed their work. When new components were created, we were asked to onboard them to the new automated system, otherwise the existing team would use the old manual system. So we were compelled to continue doing support and maintenance for our project which had technically finished. This took resource and time away from subsequent phases of work.
Resolution
This was a tricky one to resolve as the key issue here is that the right client team needs to be identified and enabled to own and support the new functionality. What we focused on was ensuring that the most senior stakeholder was aware of this critical dependency, and preparing for a thorough knowledge transfer and handover once the team was available. We also created a responsibility assignment matrix detailing roles and responsibilities both during and post project. Clear communication on the current status and timelines of the project helped to ensure all parties had the same expectations.
5. Push back when automation is not implemented in a “theoretically ideal way”
Once we started the rollout of the automation solution, a few people raised concerns that the solution was not exactly as they expected a full “DevOps solution” should be.
Resolution
The problem here was mainly a communication gap. We listened to their concerns and understood their expectations. Then we were able to walk them through our solution as well as the future roadmap for automation across this application. We also had frank discussions about what a “perfect/theoretical” automation solution would look like and why that would be impractical for their current setup. An example: the client was performing monthly releases across their application. They were not in a position to change this as part of this stage of the project. So we were restricted to supporting only monthly releases when designing their automated build/deploy pipeline which meant that we had separate pipelines for lower environments and production so that the pipelines were easier to manage.
6. Difficulty in getting time and attention of the client resources.
They are all very busy working on their own projects and in some cases, didn’t have management direction to give us the information we needed for requirements gathering, understanding the current processes and bottlenecks, and giving feedback on proposed solutions.
Resolution
Forward planning, communicating exactly what information is needed from each resource along with timelines. Scheduling meetings well in advance to ear mark the resources’ time. Transparency about our dependencies.
7. Software selection and procurement.
This project aimed to automate many different stages of the release pipeline. So new tools were inevitably required. As with most Tier-1 clients, procurement of new vendor tooling is a slow process which seemingly can’t be expedited.
Resolution
We are very experienced in dealing with Tier-1 clients who follow similar procurement strategies. Our experience tells us that the best way to mitigate the risk of procurement delays is to highlight this as a risk at the earliest stage of the project, then make sure that tool selection and procurement is prioritised as it is often on the critical path of project delivery.
However, despite all these challenging situations, the project was a big success!
Some of the things that went particularly well were:
- The client was very proactive in getting the project going and making sure our team were enabled with access, contacts and relevant documentation
- Once a team was identified to own and support the new functionality, they moved fast to start using the new system and onboard all the components.
- We were able to leverage the knowledge of some of our consultants who were already working in the client team (on a different project). They provided us with detailed information and understanding which meant we removed some of our dependencies on the client. This highlights one of our biggest strengths as a consultancy – we are able to quickly and effectively share knowledge and skills within our large team of consultants so we leverage all the expertise within Sandhata to deliver each project.
As I mentioned at the beginning of this post, we see these challenges recurring in the projects we deliver time and time again. In many cases clients do need to go through the pain of ineffective change management before they fully realise the importance of robust change management right from the start to the finish. Senior stakeholder buy-in and cultural and technical change management are such key parts of a successful DevOps transformation, but they are not always recognised so.
At Sandhata, we work very closely with our clients at all levels to highlight risks and share our knowledge and expertise with the client to help mitigate those risks. Our wide-ranging experience of these types of challenges mean we are able to predict and quickly detect these issues and act to resolve them before they snowball. This is one of our most powerful strengths and a key reason we are able to deliver successful projects which add value for our clients over and over again.
Learn More
To discover more about how Sandhata can help you achieve DevOps success, take a look at our DevOps brochure.
Bronwyn Davies
Latest posts by Bronwyn Davies (see all)
- Winner! Unicom Most Innovative Project 2023 - 27th February 2023
- Sandhata Gini – Our internal chatbot - 1st February 2023
- Goodbye 2022 - 19th December 2022