Episode 11: Building a Long-term Partnership With a Fortune 500 Client

Maciej Kłodaś (MK): Hello everyone, my name is Maciej. I’m the leader of Analytics Experience Competency Group and this is C&F Talks, a place where experts discuss about ideas and challenges from the perspective of an IT partner. And my guest today is Piotr Pielasa. Hello Piotr. So tell me who you are, what are your responsibilities at our company?

Piotr Pielasa (PP): Sure, sure. Piotr Carlos Pielasa. I often go by Carlos. I’m with C&F over 20 years now and I’ve been everything from the pedestrian developer or support specialist when I was young, and thin, and naive up until now. Now I’m C-level at C&F, which is the board of directors level.

I’m responsible for delivery of all we do in terms of solutions for our clients. Now it’s 20 years of experience and not so thin anymore, let’s put it this way. A lot less naive. So I’ve been places, I’ve seen things, I have tales to tell.

MK: Waiting for those tales.

PP: When I was joining, the company was size four. I was the fourth employee and how do you grow such a company from Poland from four people to 400 people and from working with one client to working with many clients, competing with the biggest competitors out there. Being able to witness this myself I think it’s great material for a book.

MK: We only have some time today, but we can also extend it to a few episodes. But let’s start from the very beginning because you have started cooperation with the client number one.

This is still our biggest client to date. So you have seen it all and I’m very curious to hear about the most difficult implementation in your history and in the history of our company.

The most demanding project in C&F’s history

PP: Oh yeah, the most difficult you say. I guess that would take us back to 2019 just before pandemic. Let’s call it a project D because we cannot be too specific about the names and the client names. The confidentiality agreements apply here. So project D had two difficulties within it. One: it was very complex.

I’ll tell more about what this complexity means. Number two was it was enormous in scale both for our client and for C&F as well. So from the get go we knew it’s going to be operation on a scale we haven’t managed before and nor did the, client and that was one big item that you have to consider at the very beginning.

And if you add to this complexity that we’ll dive into more, it’s a very risky situation because you need a lot of people to be prepared on both sides and things cannot go wrong. They need to be organized very well, because ineffectiveness in such a large team will cost you a lot money-wise basically. This needs to be a machine that works from the very beginning at a very big scale very well.

MK: So this was the first black swan in the company where we had to scale up a lot like double the number of employees in a very short time frame.

PP: Obviously growing from 4 to 400 we’ve been doubling in numbers in several years, and so there’s been kind of black swans every now and then to be able to grow like this. So the fact of growing itself wasn’t so unusual for us anymore.

Let’s say those swans were grayish at this point. So we as a company, we knew we need to grow, we knew how to do this, we had methods of scaling up in certain areas. This time around this 2019 project this was one that you know it’s less of a problem to double your team when you’re 40 people. When you’re already 200 people double them in three weeks, that’s a bigger challenge and that’s what we needed to do.

So we tested our ability to scale up with this project. I mean we tested it all the way but we kind of reached the level our imagination wasn’t reaching and yet we did it.

The main challenges of a large scale digital transformation project

MK: Okay so what was the main challenge main problem of Project D? In fact Project D sounds like a zombie movie so what was the challenge?

PP: So there were a couple. The complexity was the one that I mentioned before so let me dive a little bit more into the complexity of it. Complexity meaning the project was about digitalizing manufacturing operations for a huge pharma client and that alone is a challenge on its own. Because if you imagine what a company that produces drugs manages they have dozens of manufacturing sites where they produce drugs and there are a lot of different kinds. And usually they’re acquired by a lot of divestitures or mergers and acquisitions of sorts, so they it’s like having a couple dozens of companies in one company if you will.

They’re managed in different ways, they have different operations they actually do different things because any site isn’t equal to another. There are several kinds of those sites. There are biological ones that you need to produce drugs that are active biologically, but there are also very chemical drugs. Different sites do that.

Those sites produce ingredients for other sites, there’s a lot of complexity alone in that. And every such site is operated like a small company and yet as an enterprise you want to integrate them you want to do things similarly you want to be able to manage certain processes on a higher level.

So big companies deal with this in some ways, but digitalizing the way they’re working this is the goal they were after. How do we even streamline it more? How do we integrate these sites more? How do we help manage things at sites? Even the normal operations of producing, of changing shifts? How do we optimize them using software? Because right now we have processes that work but they work in a very human-oriented very paper-oriented processes how do you take the next step and digitalize them? So in a nutshell that was the big challenge of the complexity and the software that we needed to produce. It need to fit like 40 companies at one go if you will. You have to accept all their flavors in your software to still have one version of the process but applicable to so many various sites.

Agile: the best way to approach a massive project

MK: From what I remember there was a process in place, a paper process presented a concept of this digitalization right? But the key was to think of a real solution, a real implementation using real software in order to go live with this concept and having in mind such diversity of different plans different environments. There a lot of different stakeholders, so how to assess how to estimate such big unknown adventure? Because this was a project first of its kind for us as a company but also for the client.

PP: Yes, correct. So first, one correction: this paper process wasn’t just a concept it was a living process already. However only adopted to a certain extent by multiple sites and so digitalizing it would get another level because then things become serious. There is no more room for interpretation, software won’t allow it. It will be then executed more thoroughly and more universally if you will.

So that’s one correction and how do you take a stab at estimating such a monster? Because also another thing you need to understand you don’t get to pick few smaller processes to digitalize. You have to do it all, and you switch everybody to “this is how we do things now”. You have to have the critical mass of processes that come together. You cannot start small, unfortunately, because it will not be adopted. It needs to be a transforming change that already has some critical mass. So if we were playing poker that would be already starting with high stakes at the very beginning. There is no small blinds.

And so how do you take a stab at something like this? First thing that is really obvious is: you have to go agile. And from what I saw through this 20 years working with big companies it used to be different. There was more willingness on the client side to outsource the risk to partners, to those who need to execute and there were more big bids like RFPs. There still are of course, it’s part of the procurement process. However it was more about fixed cost fixed bid before even for large programs, which of course caused that any risk anything that is not sure would be translated to just more money in the bid, and then vendors would just bid higher and higher and this wasn’t very cost effective.

So, what I see more and more, bigger projects are still posted as RFCs but in the time and material mode, so client from the beginning accepts that they need to be part of the journey part of the risk management, but it’s cheaper in that way. Especially if the goal is big but somewhat undefined, which means a journey of making it more tangible and more executable together is a journey that you start.

How do you estimate it? You first estimate the bandwidth so with what with what crew you start. This will determine the pace of the work that you can plan so you have to have a rough idea of the scope, you have to appreciate all the flavors that of work that need to happen from the very technical one that we’re good, to very organizational one that typically belongs to the client side. It also cannot be understaffed on the client side as well, which we already know after these learnings. So you define this pipe, the width of the pipe if you will, and then you start pumping work through this pipe and the question is how long will it last. That’s overall how long you need to execute this work, this will shape your final cost.

MK: Have we been aware of the size of the project from the very beginning? And moreover was our client aware of it also? Because this was something very new and a very huge program, and I believe that this was a very big challenge also to estimate the results and the work needed from the client perspective.

PP: Correct it wasn’t as clear for the client as well. And to be frank the client tried to begin the program that we’re talking about, project D, in some other setup, with another partner, and those early attempts were ending in a lot of technical debt. The reason for it was, they underestimated the bandwidth they need to deal with here. So, the moment we were invited to the project we took over the technical part, but also there was a major reorganization of the project from the client side. New budgets, new bandwidth was established, new baseline of what the team sizes should be. So we were already benefiting from some of the experiences of the previous attempts which allowed us to appreciate the full scale of the bandwidth we’ll need to provide.

Sustaining stable delivery when ways of working change dramatically

MK: Okay, so we had to learn a bit to optimize the work in order to arrange the whole setup to work with such big number of people on our side. This was agile, we implemented the SAFe framework for that. But also to create a pipeline of cooperation with tens of different stakeholders on the client side. And this was the pre-pandemic time, but as soon as we learn how to set it up and streamline the process the COVID pandemic hit, right? so what was the impact on the project and our approach?

PP: That’s what actually caused me to bring this project as the most challenging one. Because if you think about such a big and complex project being a black swan for a company like ours, then the fact that just about where we’re supposed to start the project, the pandemic hit and changed all the rules that’s like corresponding to meeting a black swan. Which is very rare occurrence of events.

Maybe a side story here. Not sure if you know where the black swan term is coming from. It’s a Latin saying from like a second century in Rome, so from Europe, this saying actually assumed very rare occurrence of an event something almost impossible because Europeans didn’t know about existence of black swans at all. It was only like the 17th century where some Dutch sailors in Australia noticed a group of black swans and this is where they actually proven that okay they exist but it’s very rare.

But like those Dutch sailors found the group of black swans, this is how we felt within the project. We’re doing something unique, something first time in our company on this scale, without precedence. So is the client, and now this happens, so of course we all know a lot of things have changed, companies always write those business continuity plans for rare disasters like the pandemic, but most of the time this is a very theoretical exercise. However, C&F works for a lot of pharma industry, which are very regulated clients and we’re audited a lot, so we had those plans always up to date and well maintained and they worked perfectly.

If you remember, we switched seamlessly to the remote mode. Of course there were other unknowns: people working from very distant locations, we have people being sick, we have people not available for same reasons on the client side. And yet, the project needed to continue and even more so it needed to continue because of the pandemic. We’re actually working with manufacturing sites and they’re actually involved in producing drugs that were so much needed during the pandemic at some point. And being able to streamline at least by 1% then the cycle of producing those drugs meant huge gains for our client in production sites, and they were at stretch at the time.

Also, the demand for our software went up by like thousands percent. So if you think about such integration for a big client, it’s also not an easy sell internally. To deploy a centralized system that unifies the ways you’re working, you’re planning, you’re reporting to your management and so on. There is internal resistance to change of course, and they’re doing important things and they don’t want to be disrupted the change is not so welcome on manufacturing sites the whole controlling is about not changing basically. So change is not something they like.

And yet this time around, because of the pandemic, because of those processes being very manual and people meeting physically at sites to even make a shift change between two groups of people who are working 8am to 4pm and those working 4pm to I guess 10pm. For the second shift to take over, there were just big huddles on corridors, where people were meeting, and they had to follow these processes to make the shift happen. And now, if you could do something for them not to meet physically, that would decrease the risk of them getting sick and effectively not showing up to work that still was needed to happen, that’s what was driving this internal demand. And this demand was transferred to us as well. Now you do faster better and oh, by the way, you still need to be compliant.

Staying agile while being compliant with strict client requirements

And like I said, there’s the compliance in manufacturing sites, so the way you produce software, you control whether it’s not introducing a bad change. Similarly like you control quality of drugs, they adopted the practices from manufacturing and applied them to controlling software, which in modern world is a bit change-preventive if you will. So on one hand, we needed to go agile to be effective cost-wise. Plus the goal wasn’t clear, the whole concept of what we’re building needed to mature and adapt which required multiple iterations with stakeholders. You know the whole agile principle, where you deliver an increment of work and you show it transparently to those who need to use it. You capture feedback, you adapt you make another increment, and so on.

In an environment that is actually all about not changing things, all about keeping them as they were, because they were tested, proven, and we need to work like a machine all the time. It needs to be predictable, and repeatable, and so on. So that marriage was something that took a while to happen. Took a lot of therapy if you will. Couple months of therapy to marry these two concepts: agile delivery framework like SAFe, and compliance that was coming from good manufacturing practices. It took time, but also cooperation and open mind of people on the client side who are responsible for this. Because it’s them who needed to thoroughly understand what we’re doing, and set new boundaries, new rules on how we can build things and deploy, still compliantly, but much faster than before.

MK: These were some of the challenges, right? Because we also discovered those challenges along the way. It’s not like we’ve been aware of everything from the very beginning, and we’ve been partnering with our client hand-in-hand, working on this solution and learning along the way. Adapting along the way. So, besides of the resistance compliance to specific setup and security and everything else, what were the biggest challenges and risks along the way? What we learned from delivering such a project?

Earning the trust of a Fortune 500 company

PP: Maybe first I’ll comment on the fact, that you don’t get such a project just like that. The company is trying to do such a transformative change, large scale digitalization for the very core of their business which is manufacturing drugs in particular. You do it in an agile way, which means the contract says: give me good people and we work together, but you’re not entirely responsible for the outcome, we take this with you. That’s a partnership. And you don’t build a partnership easily. So it was a journey, this is where all my stories come into play. How do you grow from 4 to 400 with clients like this? How do you have clients for 20 years from top Fortune 500 companies?

This is about relationships, this is about building trust. I often compare it to this game of Minesweeper in Windows where you discover hidden mines by going through the field. You just get a piece of information, there is a mine in proximity, and you lose if you just make one mistake. Building this trust over years is similar. You have to succeed continuously to build your reputation, one misstep may cause you to lose this reputation, and then you’re not considered for these projects. You have to build this history, you take small steps first. At some point you are recognized at the level where you can be trusted with something so big, even for the client. And you’re invited to this experiment, because you’ve proven yourself in smaller cases, and it’s been a while, so that’s how you come to the place where you can be invited to such a big experiment.

And speaking about other challenges or learnings that we have from this big project. Something for our clients: for sure you cannot underestimate your own effort. There’s basically two paths. You either have a clear vision of what you’re trying to do. It’s innovative, you want to go your own path. This is where you need to staff up on your own side, have this vision shared with a lot of peers, have it vested before you start implementing it. It needs to be mature enough before you hit the ground and start building things. You need to pick a trusted partner, someone you’re confident to experiment with. That’s one path, the innovative path. The other path is if you don’t have this, or you don’t have the manpower to staff it on the client side, on the owning side of the solution. Then, you should rather look for standard ways, proven solutions. Then you don’t need a trusted partner for experimenting. You need a partner who is proven to have delivered the standard solution multiple times, and you go for non-innovative but safe. You don’t need to have such a long bench on your side to own it.

So after this project we’ve had other clients trying to build similar things and we’re more experienced ourselves right now, but what we see is that we also sometimes need to help the client to own the solution. Because of various things. It’s even like evangelizing your own business structures on what Agile is and how you fund it, because there is no cost of the whole solution known at first right? And that’s not a usual concept for procurement to not know how much things cost. They may cost from X to Y and it’s a very long way from X to Y. It’s not a widely accepted concept for procurement departments.

MK: But this is about stakeholder management. One of the key elements of such wide programs it’s working with resistance inside of the company on the client side.

PP: Yes, and you have to have people for this. People who will understand enough technology to be able to convey the message to the other levels of stakeholders who will buy into this model. It’s known to be very effective, but it’s not how you usually buy things. It has an element of risk. You don’t see the final shape at the beginning of such a big project, so you need structures to constantly work on this. You have to have people who will work on adopting this software at the sites, and you need to be prepared for it. It’s not just deliver great software, you also need to have trainers, you need to have people who will go to the sites and prepare people to start using the software. There’s a whole machinery of program management structures, scrum masters, SAFe ceremonies that need to happen for such a big agile project to have the least of overhead, but yet still all the levels need to be satisfied. And in the end you’re planning a software release in a very controlled environment. So with all this crowd with all this organization you still need to be able to do this in a controlled way and with very quick turnaround in the end.

MK: So it’s about digital transformation. It’s about working and partnering with clients. It’s about trust, but it’s not like we are delivering such projects on a daily basis? It’s not like such wonderful things happen all the time?

PP: You can say even that, at least from my point of observation, such projects happen once in 20 years, I guess. This is how long it took us to get to the level where you spin off a project for 200 people in a couple weeks, which is transforming your own company, transforming the core part of business on the client side. A very rare thing, however, it also emphasizes the sense of doing other things. So, I believe all we did before was enabling us, and actually getting us on this journey to be able to be trusted with such a big work, in such interesting times. So I guess, like the saying says: everything is for a reason sometimes we just don’t know the reason yet. Just embrace it.

MK: Okay so thanks very much thanks for having the time to be here and talk about your experience and your 20 years at C&F, and one of the most interesting projects in our history. Thanks Piotr for being here

PP: Thank you as well.

MK: Thank you very much and see you soon in the next episode of C&F Talks.