15 mins


Sumit Kohli, Colin McCarthy, Ian Leslie

The best laid plans often go awry. As you dive into the transformation, suddenly the project balloons. Simple processes become convoluted. Easy integrations turn tricky. How do you not panic and slip into despair? How do you stay on top of your game? In this episode you’ll see what happened when our changemakers started executing their plans. How they went down the valley of despair and came out the other side.


Narrator: In the world of startups, there’s a phenomenon called the Valley of Despair.

It’s the point in a company’s journey when the initial enthusiasm wears off, the work gets tough, and results slow down.

It can feel like you’re working for no reason, like the finish line is always out of reach.

A lot of entrepreneurs quit.

But the bravest leaders stick with it. 

They hold their mission close and keep on working. Eventually, they start climbing out of the valley. They climb up and up, surpassing their original starting point. When they arrive at the next peak, their business is stronger than ever. 

The Valley of Despair is tough… but you have to go through it to achieve great things. 

And it’s the same story in digital transformation. 

IT leaders spend months — sometimes years — on research, analysis, and planning. When they get to the implementation phase, it can feel like the end of the process — but the work is only getting started. 

They dive into the transformation, and suddenly the project balloons. Simple processes become convoluted. Easy integrations turn tricky. Performance often dips. 

When they’re down in the Valley, the finish line can feel like a million miles away — but it’s not. 

Just like entrepreneurs, IT leaders need to stay strong and fight their way through to the other side. 

So what happened to our Changemakers when they stopped planning and started executing? 

Ian Leslie: There wasn't much confidence in IT team, for instance, there was a time when I first joined, company email went down for a week. I mean, literally, seven days, and people were like, "okay, whatever, I'm going to use Gmail, I'm going to use Yahoo." Because, they just expected it to be this way, they're like, "Oh, yeah, IT, there you go. There wasn't even any kind of uproar, outrage, it was just so accepted that IT is not going to work and the systems weren't going to work.  

Narrator: That’s Ian Leslie, IT Governance and Portfolio Management Lead at Dangote Industries. 

Before we dive into Ian’s story, here’s a quick primer on the company. 

It dates back to the 1970s, when it emerged as a local Nigerian importer. In the late-1990s, they pivoted to manufacturing by opening saltworks, sugar refineries, and cement plants. Through the ‘90s and early 2000s, it grew at breakneck pace. 

When Ian arrived in 2013, the company was already a pan-African manufacturing conglomerate. But as you just heard, one department wasn’t exactly cutting edge — IT. 

Dangote recruited Ian, along with several other IT professionals, to fix things. 

Faced with the scale of the challenge, they brought in an external consultancy, who recommended Dangote use a complex ITSM platform called BMC Remedy. 

But it was too much, too fast. They didn’t have the underlying processes in place. 

Ian Leslie: We went live, and the gap between reality and what we had on the tool was just too difficult. We just couldn't bridge it, and the users were confused, they didn't like the UI, and the help desk team were confused as well.  

Narrator: The implementation stalled. And then it collapsed.  

The experience sent Ian back to the drawing board. Instead of bringing on another tool, he decided to fix Dangote’s foundations.  

He rewrote the entire process manual, designing new incident management processes, service request workflows, change management policies, and problem management plans. 

He rolled out an open-source ITSM platform called Spiceworks. It was basic and built for small businesses… but it was good enough to test out his improvements. 

Once everything was running perfectly, he migrated everything over to an enterprise tool. 

Ian Leslie: So, in terms of implementation, we had a service catalog defined already in Spiceworks. So, we started off with that, and we looked at mapping some of our processes, some of them, we were able to scale pretty well, and transfer it on. And, some of them we actually decide to look at our existing processes and redraw them to see the tool better, and to also kind of work better for us. 

Ian Leslie: Copying some old processes over and looking at some of the processes with the fresh eyes, fresh pair of eyes, saying, oh, how can we tweak this to ensure that it works well on a digital scale? So, that was a pretty big effort, in terms of defining all our services, I would say redefining because we did have something to start out with, and loading it onto Freshservice. 

Narrator: Today, Dangote’s IT department is nothing like it was when Ian arrived.  

Its processes are secure and stable. Its platforms are reliable and trustworthy. And if the company’s emails go down, you can be sure that Ian will hear about it from his colleagues. 

While Ian’s strategy of testing processes on an open-source platform is unusual, testing itself is not. 

Sumit Kohli: We started with a vision to modernize our support platform to have a modern help desk platform. But, that's just a statement, but our actually bigger vision was that we wanted to have a platform, which is the help desk platform within Education First. We wanted to bring all the support functions onto one platform, we wanted that help desk platform to be the most important part of staff’s everyday professional life.  

Narrator: That’s Sumit Kohli. You might remember him from Episode One. He’s the Head of Collaboration Platforms at Education First and had to roll out a new help desk platform in just three months to coincide with the company’s new headquarters opening. 

But as you’ve just heard, Sumit’s plans were far more ambitious than that. 

He wanted to unify the company’s patchwork network of support platforms and transform how employees engaged with the IT department. 

That’s a huge project. It’s way too big to tackle all at once. So Sumit broke it down. 

Sumit Kohli: We actually broke it down and we started the scope as a something which is manageable. We started with a smaller scope, so what we did was we actually launched this support platform, which is Freshservice, with the opening of our new headquarters in Zurich, just for the IT support for Zurich office. And, when I say headquarters, I mean that office actually is a multi product office, it has the representation of all EF products in that office. So, which we thought was the right place platform to launch the product, because it will gain the attention, it will give us the feedback. And, if it works well, we would then be able to advertise it and make it aligned with our vision that we have. 

Narrator: The test project was almost perfect. As Sumit said, the Zurich headquarters was a multiproduct office, meaning it did a little bit of everything. It was like a smaller version of the whole company. 

After rolling out Freshservice, Sumit mined the Zurich team for information to learn what was working and what needed to improve. 

Sumit Kohli: Talking in terms of new technology roll outs, or new service roll out, I always feel that feedback loop is missing. 

Even though the feedback is talked about during the launch or during the product implementation, there is less importance given to it when the product is actually released, to see how it is actually taken by the people that are using it. In this case, what we did was we actually gave them a feedback button at the bottom, and it was a simple process at the backend. Whenever the feedback was submitted, an email was triggered and I was actually getting that email. And, I was making sure that I actually read all the feedback, and made a summary of the feedback of the improvements that we can do. And, if something wasn't right, from the feedback where the user was wrong, I made sure that I initiated the contact with the user and made that clear. So, they felt that their feedback were actually getting accounted for, rather than going into a black box. So, we actually had about 500 feedbacks from the people, and that actually helped us make further improvement few months after the new setup was launched in May 2020. 

Narrator: That willingness to adapt, change, and pivot is often the difference between the success and failure of a transformation. 

Because as they say, no plan survives first contact with reality. 

By remaining open and receptive, Sumit could course correct and keep his implementation on the path to success. 

Another one of our Changemakers liked this idea — a lot. 

Instead of using feedback to refine, perfect, and optimize, he harnessed his whole team to design the nuts and bolts of the service. 

Colin McCarthy: I think there's nothing wrong with just setting it up and then adjusting it on the fly. It's almost like the Google and other startup ways of working is you throw something at the wall and see if it sticks. We weren't damaging anything. We weren't going to break anything. We would still be able to respond to people's support requests. And we had the ability to learn and refine the product in a live environment, which we could have never have done in a hypothetical environment. 

Narrator: That’s Colin McCarthy, VP of Global IT at Essence. We heard from him back in episode one. 

He told us about how Essence grew quickly, outpacing its old IT infrastructure. 

When it came time to implement a new system, Colin honestly wasn’t sure what support his teammates needed. So he designed an MVP, launched it to the company, and asked people what they thought of it. 

Colin McCarthy: But I was sort of overwhelmed and it was because I was being asked lots of questions. It's like, "How do you want this queue set up? How do you want that queue set up? What should happen if this happens? What do we need to set up for here?" And it's like, "I don't know. I don't know how we want it set up." 

"You know what? I'm not going to overthink it. Let's just set it. Let's just have all of our emails feeding into it. And once we get some live data then we'll know what to do with that because looking at my email inbox and the emails that are coming in, which are the email tickets, I can't visualize accurately what it's going to have to look like in fresh service. So, let's just throw some live, have the emails. We can carry on receiving them in our normal inbox and we'll respond some of that way. Let's send a copy into Freshservice then we'll be able to see some live data, some live questions coming in. And then we'll be able to work out how we want to have it structured. 

Narrator: One memorable fix came during the first few weeks of the COVID-19 pandemic. 

Previously, IT support was grouped by office. London engineers picked up tickets in London, New York techs handled tickets in New York. You get the idea. 

But the pandemic threw a wrench in the works. 

Colin McCarthy: When you have a much more of a dispersed workforce and also people not going into an office and not working from 9:00 till 5:00 or 9:00 till 6:00, it's very difficult. Initially, a lot of people on the west coast that maybe had families would... Sorry. A lot of people, say on the east coast that would have families, they would open a ticket at 9:00 or 10 o'clock at night or maybe I'd say seven o'clock at night. 

Colin McCarthy: They'd open a ticket after 6:00 PM. So, that's normally when the New York guys have stopped working for the day, but that ticket at seven o'clock would be stuck in the New York queue when I've got a whole team out on the west coast, it's only four o'clock their time. They could easily pick up that ticket. So, we just like were, "Well, let's get rid of some of our separate queues for different offices and locations and just make one giant queue for North America." And then when you do have people working different hours or in different time zones, instead of having these smaller teams picking up tickets, we've got one giant team picking up tickets, and that simple change that we implemented was very beneficial. 

Narrator: Colin says he’s made hundreds of small tweaks and changes to the platform since it went live. 

Each one adds another one or two percent to their performance. 

It’s a helpful reminder that change initiatives are never really done. Yes, we get new tools live… but there will always be an opportunity to improve, refine, and optimize. 


Narrator: As we’ve seen, the Valley of Despair can be a pretty daunting place. Work feels never-ending. Results seem non-existent. Perfectly laid plans often end up crumpled in the trash. 

But the Changemakers who held steady and kept working managed to achieve truly amazing things. 

Ian Leslie bounced back from a failed change initiative to deliver a world-class IT transformation.  

Sumit Kohli hit his exacting deadline and used it as the perfect test environment for his implementation. 

And Colin McCarthy harnessed his entire workforce to drive crowd-powered development of his ITSM platform. 

On the next episode of The Changemakers, we’ll jump forward in time to discover what their transformations really achieved. 

Did they help IT teams work smarter or did they end up on the scrap heap as yet another vanity project? 

Coming up… 

Prasad Ramakrishnan : Most people get too wedded to the tool rather than the real problem statement. When you take a tool-centric view and it's akin to the other statement, which you would have heard. If the only tool you have in your backpack is a hammer, everything looks to you like a nail. Try to understand what the problem statement is and what problem you're trying to solve. What is your vision of... What is it that you want to solve for? If you take a tool-centric approach, you'll forget about the users, you'll forget about the real problem, you'll forget about the process. And then you may have a case where the tool is implemented the best possible way, and you have an operation successful, but the patient is dead. 

Thanks for joining us.