How to prepare and run an IT project transition for the best possible chance of success? with Karolina Trzcionka and Paweł Pukocz

Michał Grela (MG): My guests today Karolina Trzcionka and Paweł Pukocz great experts from the field of project management. Would you be so kind as to introduce yourself guys?

Karolina Trzcionka (KT): Sure. Hello. My name is Karolina Trzcionka and I’ve been with Future Processing for over 11 years now. I’ve started my career as a quality assurance engineer, and then I’ve moved to the role of project manager and team leader, and then delivery manager. And as a leader, I was quite often involved in the transition of project, being a receiver of the project from our customers. As a delivery manager, I was also involved in transiting the project from Future Processing to another supplier.

Pawel Pukocz (PP): Hello, my name is Paweł similar to Karolina, I was a QA at the beginning of my career, and then I moved to the team leader role and project manager, right now I’m a delivery manager. And during my career, a couple of times I was involved in transition of the service from our customer to our company.

MG: Brilliant case, thanks a lot. That’s a very, very exhaustive experience. So the topic of this discussion will be moving an IT project from one supplier to another, or from… To buy it, to supply it, basically the transition of the IT project, because when working with a software development partner, often there is this process of just moving development of the project, or maybe service from one supplier to another. And as far as I’m concerned, it can be considered from both sites can it?

PP: Yes. As you said, we can be the supplier. So customer came to our company and wants to do some project development on our site or move some services from his site to ours. And, but as Karolina also… We’ll be talking in the future, in a couple of minutes. We can be, let’s say a giver, so we have some development in-house and maybe our customer decides to move to another supplier, so we need to move the service there.

KT: I would say that the most common scenario is of course moving the service of the project from in-house to another supplier. So risk-wise, most of our clients tend not to change suppliers during the development of the project. But of course it might be due to several reasons starting from operational agility or cost implications, down to just the simply dissatisfaction of service. So sometimes it happens as well and I would say that this is even more challenging scenario to move the system under development from one supplier to another.

MG: But guys, what do you exactly mean when you say moving development or the transition of a IT project, how would you describe it? What does it really mean?

PP: I think in most cases, our clients wants to increase capacity or change the supplier. So they have some in-house development of the product and they decide to go to different country because the costs are lower there. And would like to find some supplier who will be able to take responsibility for the development of the product completely, or they want to extend the existing team on their site. So everything is connected with some product development, project development and moving one service from one area, one country, maybe to another one. So it consists of many small things that we’ll be talking later, that needs our attention in the meaning of transition to make this process successful.

KT: What I would like to add to that, is that in some of the cases being a supplier means that we are taking over only some small part of that service of product development, because we are only an augmentation to the team on client site. And in this case, the transition I would say is pretty straightforward. It’s an ongoing process. So we will not cover this in great details here, but what we will cover is that sometimes there is a need, from the client perspective, to move the whole development of a area, or the whole product to another supplier. So not in-house, but to a supplier. And this is what we mean by actual transition, because this is something that has to be managed.

MG: To be honest, looks fairly simply. I mean, this isn’t basically moving responsibility of the development from one company to another. So what’s complicated in there?

KT: I would say that first of all, we need to be mindful of the size of the thing to be moved. So putting it at scale, the project that I’ve mentioned at the very beginning, the one that we’ve moved from Future Processing, being one supplier to another supplier, it was developed by us, by the team of over 20 people for more than five years. So it was quite a big chunk of development. It was also quite a huge variety of services that were provided to the client. So, obviously even the knowledge transfer, the domain knowledge, the knowledge about the solution itself, it was extremely complicated.

So as I said, the simplicity varies based on the size. But the other thing is that, based on our development, we see that very often, what is slightly neglected on client site is the importance of the time needed for the transition. So once the client decides that he would like the project be moved from in-house to a supplier or from one supplier to another, sometimes it is a little bit forgotten that it requires time and there shouldn’t be any lower quality of the service in the meantime, but still the transition itself will consume time and money. And this has to be planned because if not, then the business continuity is put at risk.

MG: So how long did it take for you guys to transfer this project you’ve mentioned?

KT: Transition itself, took few months and it was carefully planned and managed to as a regular project.

MG: All right. So I would agree. I would suspect that stakeholders don’t actually plan extra three months when moving development, just for the transition itself.

KT: Yes and that-

MG: It can be a challenge.

KT: It was a challenge indeed. So what we did was that… Again, we looked from all of three sites. So from the client perspective, from the old supplier, from the new supplier, we looked at it all together as a project. So first of all, we’ve appointed the project manager, the transition project manager on every site. And we’ve formulated together a project plan for the transition. We started planning this, a year ahead. So in order to match the business calls. So the first thing I would say, apart from appointing people responsible for managing the transition, I would say that apart from that, the other very important thing is to do the stakeholder and the scope analysis, because transitioning the project from one supplier to another, or even from in-house to a supplier, is a very good opportunity to think of what you do want to have in in-house and what would you want to outsource.

So in this particular case, our client decided to take some of the services that we were providing at Future Processing, to take it back in-house. So he has reduced the scope in some way. But this was the very important exercise to understand what we are actually providing and what the new supplier is able to provide and what the client would like the new supplier to provide, so this is the first thing. And the other thing is the stakeholder analysis, so to understand who is affected by the transition and how, and what are the important business goals that have to be met regardless. So this is the thing that as the old supplier we’re bound to fulfill. I would say that a very high level goal of every transition, is to move the knowledge and the source code and everything needed to provide the service from one place to another, while keeping the business continuity.

MG: That sounds pretty much as a challenge. Pawel, what else can be challenging when transitioning IT project?

PP: I would like to add to what Karolina said, that moreover when you’re, let’s say the giver, so you have some service in-house and you are not realizing that how many different areas are in the project, because let’s say you are working within domain many years.

MG: Just got used to it.

PP: You get used to it. And so from your perspective, it looks simply, we just hire another team in different country and then plan maybe one month of transfer of the knowledge, without any details, we just ask a developer to came to our office, spend one week with them, et cetera. But in that case, you have to realize that the people are not aware about the domain about the… Or even organization on the customer site. Don’t know what are the stakeholders. So they know nothing about the projects.

So it is something that is, let’s say it can be underestimate by the customer in most cases. So that’s why, like Karolina said, it’s important to maybe start… Treat it as a project and do all this project management stuff at the beginning and then show it to the customer. And this is one thing that is, I think, most crucial to explain it to our customer or what is needed to do the transition effectively. And in my case, when we be a taker, receiver of the projects, it also took six months, sorry, you said three months. And it took six months for us for a much smaller project. We also had to take care of our business continuity. And we even have some, let’s say internal deadlines during the transition that part of the customer staff were moving to different companies. So they were missing in part of the transition process. So we need to plan, let’s say some milestones to see what happens when this guy leaves and to plan it, according to the… Let’s say, this movement of those people somewhere else.

KT: I would also add that, based on what both Pawel and I said before, I think that, and I think you Michal, did the same thing, you started with this sounds fairly simple, but it’s not that simple. And sometimes it’s even a responsibility of a good partner, of a good supplier, and to be able to clarify and just be quite straight forward with your new client about what the transition is, because sometimes the client might not be aware of it.

And this also means any cost implications. So if the transition is being managed as a separate project, it should have a separate budget. And the budget implications are also important for our clients in terms of, because usually for the transition period, they are sometimes paying twice the price because they are paying for both the old and the new, and the new supplier or for the guys in-house that are doing the transition, and for the new guys that are there taking over. So if this is limited in any way, this will obviously limit the amount of activities and the amount of time that we’ve got for the transition. So it’s good to know it beforehand, to plan and to prioritize the transfer based on how much time have we got.

MG: So how would you prepare for this transition? You’ve already mentioned… I really like that comparison, treat it as a project because, well, basically you have time, you have scope, you have some budget limitations. So this approach really got me. But how would you prepare for that?

PP: Karolina mentioned that the stakeholder’s analysis, I think is the first point. You need to understand the goal of the customer and the goals for many stakeholders, because different stakeholders on the customer site may have different goals, in the transition. And based on that, you just prepare a proper, let’s say you address those stakeholders in proper way. So crucial in my case, is to convince the giver that we, as a supplier will be able to first, do the transition and second, to make the project working on our site, so to have this business continuity and by mean, convince somebody to do this transition, was to prepare our plan, some kind of presentation to show what exact activities will be done during this period, how we address, let’s say the knowledge transfer, which is the most crucial thing in our case, because convincing customer to this was mostly by showing him the exact plan, the exact activities in very, detail.

I mean, even showing him how we would like to plan the knowledge transfer. How many times we will be visiting them? How we manage the knowledge transfer? What will be the tools used? How we will be, let’s say taking the knowledge here? What should be a part of documentation of the project? Maybe some records, some sessions of this, with discussion with our customer, with those people, do some kind of job shadowing during the project.

So putting as many details as possible to this presentation, to this plan was something that convinced our customer, okay, we would like to progress on it, we would like to go with this approach. However, we need your confirmation each two weeks. What is the status? What results do you see? How we address those risks? How the people are feeling in the project on our site? If we see any risk with our people internal? So we needed to be very, very transparent and it, in general, it helps in our case that the transition was successful. However, we started normal project right now. So we have a different, let’s say, a different challenge to make the situation stable and to make the business to be continued on, on our side because the customer resigned from those people that were previously responsible for the project development.

MG: You’ve said a lot about knowledge transfer and how it can look like, but I bet it’s just a first step of a proper transition, isn’t it?

KT: Yes. So we’ve been talking a lot about how to plan it and how to treat it as a project and to understand the needs and the timelines from the business perspective, but on the implementation level, it does start with knowledge transfer. So the knowledge transfer is the very first step. I would say that the even previous step is to put the knowledge altogether. So either as a old supplier, or as a client, to just have a couple of internal session and sit down and try to put down at least an overview of what we would like to transfer in terms of the knowledge. So, as Pawel said, a couple of minutes ago, sometimes, especially when moving from, in-house to the new supplier, we might not understand and fully realize how much we already know.

So, working with a system for several years, usually means that we forgot the very simple basics that a new supplier will not understand because he’s not so fluent in our domain as we are. So keeping it from the very low level and in the way that you will speak to a four year old child or something like this, it’s a good thing. So starting with knowledge transfer, what we did and what I can recommend being a good way of approaching knowledge transfer is to run the knowledge, transferring sessions. They might be done via Skype and I would even say that it’s almost as effective as face to face. So they are being recorded and the session itself consists of a topic.

So if the system is very complex, it’s good to appoint, and let’s call him knowledge manager for this particular area. So, to appoint a person who is the most fluent and the most experienced in this particular area, both domain-wise and code-wise and solution-wise, it might not necessarily be a project manager. It might be a QA lead developer, basically anyone. In the case of the project that I’ve mentioned, that we’ve transferred to another supplier, there were several areas and almost everyone in the team was responsible for area. So it was kind of a, almost a team activity.

So we do have the person and the person has got an outline of what to say. And we start with running the session, there usually several sessions on each topics, they might be an hour long or so. It doesn’t matter. It doesn’t have to be very long. The important thing is that they get recorded and the other side then paraphrases what they understood. So after the session, the documentation is being produced, by the other party, so by the receiver. And then the documentation is being signed off, or at least read and signed that this is what we’ve meant by the client or by the giver.

MG: That’s very clever. I mean, like that’s proper way to ensure that both sides are on the same page.

PP: It’s also good to think about this knowledge transfer and these artifacts that will be created during the knowledge transfer in the long term of the project, because in the normal, let’s say conditions, it happens that people are leaving the projects, you have to hire new ones. So having this transition in place, you could build, it’s a big knowledge base of the product, which will facilitate or just make the farther extension of the team-

MG: Say sort of a documentation?

PP: It’s documentation, it’s recorded sessions, even existing team can get back to this artifacts later when they forget about something. So it’s good to have it.

KT: And once the knowledge transfer is complete, I would say that the quite common and quite clever next step is to do the job shadowing and reverse job shadowing. So we start with… If the process where we are now getting down to the real job and the job shadowing, in the job shadowing process, the new supplier, or the first supplier, if you are moving from in-house, just sits down and watch, how do you work with the code? How do you work with the solution? In our case, it was a two week sessions in here, so in our offices at Future Processing, where our team was more or less working, they used to work before, but each one of them have a peer buddy to do the peer programming and work on typical, both issues back and new development together with the new supplier.

And so in the job shadowing process, the new supplier is looking how it works and asking questions and observing. And then we do the… Again, depending on the size, it might take two weeks, it might take a month. Then we do the reverse process. So reverse job shadowing and in this particular case, it was even done in the new supplier’s office. So it was then our guys who traveled for a few weeks to supplier’s office. And then it was the other way around. So the new team was starting to do the job. And we were only sitting and looking behind the shoulders and just asking, maybe not asking, but being asked and answering questions, but not saying a word until it was necessary.

MG: How do you manage this business continuity in that case? Because as I understood is that the… Some of the people are busy with only transferring the knowledge, yes?

KT: So the team, as I mentioned was over 20 FTs, so we had the transition team, so to speak was I think, around 10 FTs at this point. So these were the guys who are busy only working on transferring the knowledge and the rest of the team was still taking care of the business continuity. And the huge perk of working in this, in a project management model was that the expectations of the client were quite clear and we’ve planned the transition in the period where the business continuity was put at the lowest risk. And so we could go more into the maintenance mode. So, it was the period of the lifecycle of the product, where we do not have to create any new functionality. So we could mostly focus on the transition, but also on the maintenance of the existing solution. So it does not affect in the end customers in any way.

PP: In my case, the team was much smaller. It was four people on our site and three guys on the customer site, who transferred the knowledge to our company. And at one time we need to freeze the transition because the business needs were much higher than we expect. And that results in some delay, in the final result of the transition. However, it was… There’s discussion with the customer, that we need to postpone some training sessions, some transfer knowledge sessions, because we need to focus on the business, which is also a good, good thing, because then we work together as a team with our customer. So it’s a part of the transition as well. I mean, to work closely with those guys, looking at them, how they work, what actions they need to, let’s say do, in order to get some information to, let’s say do the task with the functionality. So it’s also a good experience to work in parallel for a couple of weeks, not only focusing on the transition, but working on the business.

MG: Fair enough. I really liked the bit you said, that well business comes first and you always have to adapt. And getting back to what I said earlier, now, I would never say that sounds fairly easy. So you got me there. So guys, how would you start the whole process? What should our listeners look out for when starting transitioning of their projects?

PP: Project management staff will be helpful here. So I think it’s mentioned first time in this discussion, do the stakeholder analysis and discuss with the customer, what are his expectations, not expectations from the transition itself, but the farther expectations, what he would like to do with us in the future. Let’s say, assume that we finished transition, we will have the service here. What you would like to do with us? It is I think the crucial thing that you need to know at the beginning because then you can adapt the whole process to this, having knowledge only in the short period of time, in the short future that means we need to transfer the project from our company to yours. It’s not enough, it’s only a part of the screen of the whole situation on the customer site. So it’s, I would start from this point.

KT: I totally agree with Pawel. I would say that starting, first of all, with appointing transition project managers on all of the sites, or just person responsible for transition, it’s one point. The other thing that we have not touched yet is to manage and supervise the transition, so that the process and the progress is visible for all of the parties. So Pawel mentioned that, obviously the business continuity and sometimes our business have to, so we have to adapt to the changing circumstances of the business, even during the transition.

But it’s good to have a common understanding and the visibility of the progress among two or three parties. So we know what are the goals and we have even a very rough plan of, let’s say that at this point all of the knowledge should be transferred, at this point, you should be able to perform, for example, first bugs, or to create the very simple functionality and communicate and to monitor it all together. So for example, to sit down on a call every second week and to discuss the progress, to be sure that first of all, the transition goes as we planned and that, to address the risk that Pawel just mentioned, that nothing has changed from client perspective. And that we, for example, do not need to adapt anything.

PP: It also is to know the real reason of the transition. So why the transition is happening, because of the cost, because of the availability of the people or a different reason. So not only the goal for the transition, that we need to transfer the project from this point to this point, but why a customer-

MG: On a higher level?

PP: … wants to transition. Yeah, on the higher level.

MG: So what would be… Summing things up, what would be your one best tip for our listeners that would transfer the project?

KT: So I would say that if you are a client that is willing to transfer your project from in-house or from one supplier to another, the most important thing is to appoint a person responsible for on all of the sites. So on your site and on the new supplier site, who is responsible for the transition and managing the transition.

PP: And my recommendation for the supplier. So for the second site would be, to be as transparent as you could be in this, communicate it clearly, what would be the plan for the transition, communicate what you heard from your customer in this plan to confirm that we are on the same site, we would like to go in this direction and we are compliant on both sites that this is the goal we would like to achieve. So good communication and transparency, and provide a plan of the transition, how it will look.

MG: Thank you guys. That was very, very informative. So I guests today were two great project managers from Future Purchasing Karolina Trzcionka and Pawel Pukocz. That was IT Leadership Insights by Future Processing. Thank you guys.