Context of our Client
Our client is a blue-chip mobility solution provider with a storied history. They have earned their stripes in their sector through an alliance with one of the biggest global players but have lately sought out opportunities to diversify away from their core activities to become less dependent on this particular relationship (and the revenues associated with it).
After initially hitting a bit of a rough patch in their efforts to diversify, the choice was made to recalibrate and focus the bulk of their diversification efforts in the mobility sector, where they have the most experience.
This has led our client to pursue several complimentary strategies, such as:
- Increasing downstream vertical integration off its own core competency
- Branching out into new types of mobility, particularly those linked to the opportunities offered by ongoing electrification efforts
- Cementing its intermediary, platform-like role by betting heavily on digitalization, with a focus on creating continuous sources of revenue through their Software-as-a-Service offer.
The staging ground for today’s use case was created in the pursuit of the third diversification strategy. Prior to SteepConsult’s mission, our client had decided to become heavily involved in the creation of a new sector-specific ERP system.
Context of the Project
As our client acts as an intermediary for a wide range of SMEs within the mobility sector, it had understood the need for greater digitalization in the operations of its partners. Given the fragmented landscape in Belgium, it also understood that its partners would need a strong shepherd to help them through the difficult investment and consolidation phase that lay ahead.
Our client thus envisioned a grand programme, culminating in a three-pronged implementation initiative seeking to simultaneously:
- Replace the existing outdated ERP system with an entirely unrelated, state-of-the-art new ERP system developed by a foreign partner
- Integrate the new ERP system into the wider IT-landscape they had already begun to set up (and make a plethora of adjustments to it while they are at it)
- Switch to an entirely paperless way of working
In most organizations, each of these three aims would have been turned into a separate programme.. At our client however, they chose to combine all three into one big behemoth of a programme.
Thankfully a structure was chosen that allowed for some experimentation. The client introduced three stages in this project:
1 – The Pre-test stage, executed in cooperation with one of their SME partners
The goal of the pre-test phase was to validate whether the developed ERP system performed its tasks as intended.
2 – The Pilot stage, executed in cooperation with one of their SME partners
After a successful pre-test, the focus would shift from the tool itself to the approach. The goal would be to validate whether the developed implementation approach worked effectively.
3 – The Mass-rollout stage, implementation at all of their remaining SME partners
After a successful pre-test and pilot, both tool and implementation approach would be validated and now they would be implemented at scale
Given our specific experience in the fields of Innovation, SteepConsult was brought in during the preparation for the pre-test stage, as everything was not going as smoothly as our client had initially hoped for.
Facts and Figures
To understand why the client needed additional support, we must first delve deeper into the complexity of the challenge. That this was a gargantuan project is already clear, but to drive that point home, we have listed some data to further contextualize our efforts:
- Projected is expected to take 7 years from start-to-finish
- Over 2.000 users, spread over almost 200 locations, will need to be trained
- Core program team is dividied into various, smaller project teams. There are at least eight different teams involved, each with their own leadership structure
- Core programme team in the pre-test phase consists of over 70 people, this is expected to further expand in the future as this number will rise even further in the future and be complicated by a shift in which teams will carry out the bulk of the work. This means that within a programme team that expands slightly overall, some teams will see dramatic reductions of their head count, while other will have to upstaff dramatically. In total, more than ten other application teams are directly impacted by this project. These speak four different native languages and are a mix of internal employees, freelancers and consultants derived from four different suppliers
Root causes of the Organizational challenges of our client
Aside from the facts and figures outlined above, which would have created a massive challenge in the best of times, there were several factors that further muddled the waters. To borrow a metaphor from tennis, we would describe these as unforced errors made by our client:
Definition(in sport, especially tennis) an unforced error is a mistake in play that is attributed to one’s own failure rather than to the skill or effort of one’s opponent.
The major unforced error in this case, was the governance structure that was not properly thought out before embarking on this megalomanian programme.
The unclear delineation of roles and responsibilities, combined with the enormous stress the programme incited, had led to a rapid deterioration of relation between business, IT and the pre-pilot partner.
Further exacerbating this, even within the IT department there were conflicts, as no one had ever bothered to create a clear and comprehensive overview of the IT-architecture. This caused trouble between the core team and the teams who were more marginally involved, as it was hard to get buy-in from the ancillary teams to attune their own release schedules and holidays to the timeline that the core team needed. With a clearer understanding of the IT-landscape and the various interactions between all the involved applications, it would have been easier to demine conflicts of this kind.
These unforced errors had many consequences, primarily that there was no clarity on how to exactly progress with the pre-test, as no one knew the resources that would be required, where these resources would come from and how they would be organized.
It is at this point the knights-errand of SteepConsult enter the picture. Given our vast experience with change management, governance, innovation and alas also crisis management, we were asked to step in and help defuse tensions.
Goals of our Mission
We had three months to get the various feuding parties back around the table, map out the required resources to turn the pre-test phase into a success, highlight any gaps and create a coherent strategy to deliver the desired results.
Such a strategy would eventually take on the form of a Support Model, which would detail the various levels needed to funnel questions and problems of end-users to the right person, have an overview of all the involved roles and what their responsibilities where, would specify evaluation criteria to determine success, contain all the practical information on working hours, parking arrangements and so on and so forth.
Needless to say, all of this needed to be done under immense time pressure as the client’s management would not stand for any delays to their timetable. This time pressure would make it impossible to solve issues by staffing up or provide in-depth training trajectories. We would have to make do with what was already available in house.
Our approach
To fulfil our objectives, we had to adopt a six-step plan which we shall explain below.
Step 1: Get a clear mandate from the leadership
Since the programme leadership could not agree on a strategy to arrive at a coherent support strategy by themselves, it was therefore also unable to engage in any type of capacity planning. By putting the ownership of developing such a strategy squarely in the hands of the SteepConsult team, we were able to solicit time and feedback from all the teams that were directly involved.
Step 2: Use our experience to sketch the outlines of a viable model within the constraints presented in the previous section
Normally, we would have preferred to add some time to do desk research and scour the scientific literature and our own use case library for potential inspiration. Given the fact that we only had a very limited amount of time and would not be able to mobilize any additional resources, our options for the Support Model were, however, very limited.
In this case, we thus chose to draw on our experience in other implementation efforts to create a classic three-staged model focussing on the proper flow of information (both upstream and downstream).
As can be seen above on the Support Principles slide, we designed, information is received from the end-users at the various pre-test sites by 1st Line Support providers, who use JIRA to pass this information on to a War Room to provide 2nd Line Support.
Since this War Room contains a large body of specialists, each with their own expertise, a filter role was added into the mix. Depending on the domain in which the JIRA ticket was logged and the actual content of the ticket, the filters would assign the ticket to the right experts. That way, the specialists could focus on the tools they knew best, without having to sift through the endless barrage of tickets that would come our way and did not touch directly on their own area of expertise.
Finally, in case the War Room was not able to fix an issue, there should be an escalatory option to request 3rd Line Support from the involved developers and other technology partners. Most of the questions would go towards the main development partner, but as there were more than ten other impacted developers, we also needed to foresee the option to enable us to contact them.
This last part of the assignment was confounded by the aforementioned fact that no clear overview of the IT architecture of the programme existed. With some time and effort, we were able to weed out which teams were involved, but without a detailed plan of the IT-architecture, we could not be exactly sure how that involvement functioned in practice (e.g., which type of interactions are there and when do they happen).
Step 3a: Do the rounds and talk to all the different teams involved
The most time-consuming aspect of our entire journey was talking to all the teams involved and getting everyone to focus on the common goal. Even though we had a clear mandate on this from the leadership, we still had to fight every step of the way to overcome infighting within the involved teams.
This is natural of course, as tensions were high, and the wound had festered for too long. Still, we had to execute this step in parallel with step 3b to get an overview of all the foreseeable challenges and potential solutions.
This meant working together with all the various teams to assess their capabilities and availabilities, gathering their ideas on the type of support that would be required and could be provided and generally encouraging them to zoom out from their specific part of the process to focus on the ‘whole’.
Step 3b: Talk feasibility with the pre-test partner
Parallel with the consultation round in step 3a, which was conducted internally at our client, we also had to carry out a diplomatic balancing act with their pre-test partner. This was exceedingly difficult, due to the fact that there had been excessive cross-pollination between our client and its pre-test partner (with sensitive knowledge of the programme having leaked to the pre-test partner through hires and backchannel communication).
This had unbalanced the relationship between our client and pre-test partner, which in turn had bred unrealistic expectations about the potential support our client would have to foresee during the pre-test implementation period.
We thus had to engage in an intricate dance with the pre-test partner on the one hand and the various internal teams of our client on the other hand. Changing one aspect of the proposal in the living document we had created to curate it, meant that we had to pass the gauntlet of all the other teams once more.
Step 4: Align support needs with capacity
The intense consultation process we described above eventually led to a proposal that contained an overview of all the required support positions. We already had a good idea of the available capacity and knew that this was not going to be sufficient to cover all the required slots.
We thus had to engage in three important exercises at the same time:
1 – Organize a training journey
The goal was to upskill the available resources in house to play their role during the implementation test with a modicum of self-confidence
2 – Negotiate surge capacity
What can we provide employees/teams to entice them to accept structural overtime for the duration of the pre-test hyper care
3 – Consolidate all information in a capacity planning file
We had to take align capacity with needs in one central file from which we could keep track of deployments, assess risks and keep track of the impact of any unforeseen changes if necessary
Step 5: Set up the necessary procedures and tools
Now that the hardest (human) challenge had passed, it was time to finetune procedures and create the necessary tools for the implementation effort to succeed.
This included amongst other things, setting up a dedicated JIRA environment, creating manuals, escalations flows and communication guidelines.
Step 6: Execute with confidence
With all the heavy lifting done, we set about implementing the programme at the pre-test partner sites of our client.
Results
By executing the six steps described in the section above, we were able to:
- Provide a clear estimate of both the needs and available capacity, as well as highlight divergences between them;
- Provide proper incentives for employees and partners to help fill any vacancies;
- Create a planning that was perceived as fair and equitable by both the leadership of our client and their pre-test partner;
- Deliver a successful rollout at the various pre-test sites.
- 4 pre-test sites successfully onboarded on the new system
- Approximately 100 pre-test users taken
While circumstances for this project were not ideal and we would definitely have advised earlier changes to the governance of the programme, we were still able to achieve success against the odds during the pre-test phase.
This, however, took a lot of time and effort that could properly have been more productively deployed elsewhere in the project.
