Perfect. Yeah. Thank you for, for the introduction. Yeah. Today I would like to talk about the success factors of, of pump projects. I did several pump projects. Sometimes I did the, the mistakes myself. Sometimes I saw the mistakes where we forgot success factors or topics, which are really necessary for, for the success of Pam, bro. So what are the topics today? Who I am, who is CX or short introduction already? Then the second topic is the right project planning with the right scope. I am pretty sure. Sometimes you would say, Hey, that's, that's logical. Yes, it is for, for me, for you, but sometimes not for the customer or you forget something then the right strategy. Also here, I think some of the points are really common, but some points perhaps not one point is to hand over to the run phase. There are a lot of success factors.
Sometimes projects forget a really important success factor. Our documentation. I go the topic, which documentation are for me, the most important for a successful hum project. And also it's very important interface to other systems. So who I am with CEX, I already mentioned it. I'm I'm the managing partner of Cyrex. I'm the founder of Christo Eckard there. What our oil topics, its information, security management, non-financial risk up, risk it, compliance, identity, access management, privilege, access management, Siemens, and monitoring. So later you can can download here and, and have a deeper look in it. So I am PM and see it's it's my topic. And the left side, it's small is Chris the main skills so that you have a slightly overview who I am, who is CX. So the first point I would like to go in is the right project planning with the right scope.
Often I saw a customer that said, okay, that's the budget. That's the time. And that's really to, to review it because a pump project, it's not only a small project, it's not only a process. It's not only a tool. It should be really reviewed good of budget and time. So, and of course the scope should be really defined of the infrastructure. Often I see too much infrastructure to less infrastructure, too much modules you re really have to review what are really exactly the needs of the customer. It's every customer is different. You know, then if you all stakeholder involved, that's a really important topic. I often see that's going wrong. So best case is active directory. Do you have a stakeholder, a specialist of the company in your project because every, every infrastructure, the difference. So you really need a specialist there also from network firewalls is, is a big topic.
If you don't have the stakeholders and your project, you could be the best expert. The project will fail. I'm pretty sure. So also, what is the purpose of the company with this project? Start with the infrastructure. Start with the applications. That's always different question where they come from. Is, is there a finding, do they care about security in, in general? That's that's really a question at the end. It's also success factor. Yeah. Do you have a stream for processes? So really don't forget processes within the pump project. Over the pump project. Yeah. So it, you hit almost every department in, in, in the company. If you do a really big pump project, so you have to think about it. How, how do I get privileged access? That's a process. How do I get rid of privileged access? That's a process. What's if I change the department, that's a process. You have really care about that. Also documentation. I will go deeper in later. Do you have a stream or a sub project for documentation often, really? I saw there's no budget for that. You forget it. You, you don't have in mind to, to really document the project very well. And you can do the best project of, of the world. If you forget the proper documentation, it might be really that you fail here. Yeah. And the last is, is there done study before?
Do you know which tool you, you need? Do you need a tool? Which interfaces do you need? And also big topic. If you have a privileged session manager, for example. So a pump project often has a tool involved there, then applications need to be installed there. Do you have a list of that? So that's, that's really only three question of it. I, I can continue with, with 10 question, but for me, that's the, the key questions to have a success factor later in the project. So the strategy, that's also a very important question for, for success in the project. You should be aware before you start or when you start. So, as I said before, you have really be aware of your scope and that's really important. You have to be very clear because of the things out scope. That's, that's really more important at least as the scope because that the customer will always challenge you there.
So if, if you don't define out scope, that's really a C that, that you could miss the project success here. So then you, there are a lot of questions for success there. Where do you start with the processes with the tool decision? So there are so many tools at the market, like cyro beyond trust to cut. I dunno. Do I divide installation of tool and processes? Huh? That might also be, be a question the then with what do you start? Yeah. Do you start analyzes the infrastructure, middleware application, database technical accounts and so on. So that's, that's really a success factor where to start. So that's, I can't, can't say you have to start with infrastructure. They are customer, they have to start with publications or wise versa. So that's really a key factor here to be success in, in the project to really be sure with which you will start also the strategy with shared account, no personal accounts, which have privileged is, is really important in my, my experience that that's always the first question raise and you in a long, long discussion.
So you can do a robust strategy with shared accounts, or you can say each privilege has a personal account. There are so many strategies you can do with that. Yeah. But you should be aware at the beginning of a project that your project gets successful here. Also a big point often forgotten is the license management. So if you implement a tool like Cy a, like let's say Cy ARG there, you have put on applications on it. Like tiled there, you need licenses. Yeah. So you have to be aware before you start because that's budget. So also the license management, you, you should be aware of it. And at least the strategy should, should, you know, before you start, the project is about the automation onboarding accounts. So you can onboard, that's only a snapshot, huh? You should be really aware what's after there are new accounts, their old accounts, what should we do with them? Huh? What should we do with the privileges? That should be really clear when you start that you have the right strategy.
Also the success factor is, is really, and, and really often difficult and not the main topic, but it's really important is to hand over to the run phase. So it should be in, in, in the beginning of the project, you should be really clear where to hand over. Well, so you have a infrastructure, you build up a infrastructure, you build up processes, development process, you build up administration. Huh? So is, is there a department you can end over pers they are already stakeholder in, in your project or do you need a party who do the infrastructure of, of your pump tool? So I, I often saw that there's no standard. If you have a database, which is hard often the, the company current do the run run phase here. So they really need a decision what to do. So be aware, who do you hand that also with the administration it's it's could be complicated to, to bring it to the company, to the employee.
Sometimes the company said, Hey, there's a third party. So then it's perhaps not this problem. But sometimes they said, okay, I have an administration here or yes, already three tools. Now it's the fourth tool. So you have to hand over him, that's a little bit more difficult. Also the deployment process. I'm pretty sure you do a proper project to do the development of cyber a, of your trust of tic. You have a lot of codes, but how do you hand over, where did you do code? Do, do you have bit bucket how you can translate it to the department of your customer? Also the, the process. How do you, you do the handover of the infrastructure accounts processes. That's very important. So you really have to define a point where you are not responsible anymore for that because you have your, your scope and you have really to, to see that's, that's, that's your budget. That's limited normally. And the last point here to, to hand over the run phase and really often forget even like me, it is mistake. Also one time, the help desk. Do you think about help desk? On the one side, they have to be aware of all the processes they need groups or something like that. On the other side, often the help desk also has a privileged accounts. Huh? So you have to hand over something to them also really important.
So the next point is the documentation. I think that's, that's a, a common topic for you, you know, this documents, but I just wanted to, to bring it on, on the paper here that you see what's for me, the most important documented for our success full project, of course, the design slow level, high level designs, the architecture, also the project plan it's often important for, for the company, for the customer. If they have follow up projects with their own project manager, if they're small, that they really see what we have done. Of course the processes you have to write down, all processes around the pump project, around the pump processes. Now a really important topic is also the lessons learned. Often I saw there are processes involved in, in the Palm project of, of the company, but they don't know how exactly the, the project runs.
Because for example, I am working normally for enterprise customers. So really to write down how to request something, which firewalls, what was really the topic, which customer's time, that's really important for the customer. So he learned himself better. Huh. And also important is the summary of the decision. That's really a documentation you will need. How Gil later there a manager was not there, where you do project. He really has to know why you decide why, because of security because of whatever trainings material I don't have to tell you that that's, that's really important. And a point often forget is how to, for administration. As I said, if it's a third party, don't care about that. If it's the employee itself, you really need some documentation. And that's a really a big point for success factor of the project. So if you have the best project ever, and the administrator can't administrator, because you have, for lack of, of knowledge, then it could be really a problem.
And at the end, your project is 99%, 1% not good. And the 1% is really that's. The customer will see at the end. Yeah. And the last point for the success factor. And it's a very, very important point. Often forget something is the interface to other systems. What do you mean with that? For example, you have a tool implemented very fine. It works very properly, but there have to be a lot of interfaces per to other systems CMDB. That's very important there. So if you don't know which server are in, in, in the, in the infrastructure, you will lose, you will not have a success because today it's only a snapshot tomorrow. 10 of could be a wait and new server could be there without a CMDB or connection to a CMDB. You will not know the ticket system, if ticket tool or incident, problem change system, it could be worth to, to investigate if it's good to, to have a interface to, to your tool, to your pump processes.
So for example, the, the, the administrator don't have old privileges. If there is a ticket incident or something, he can request privileged access, but the system has to see, Hey, there is a ticket. So it will be worth to investigate there. If, if there could be automatic interface, Siemens is, is a big topic. So I don't think as, or let's say C and M tool that the two tools, I don't think without interface are a pump process, a pump tool don't make sense. So the pump tool is, is really a lot of, has a lot of information for the sea and the em tool is really mandatory for re-certification for, for access. Really? So the pump tool can't do that. Yeah. If you need access, if you need privileged access to something, you should request it in, in the M tool and at ATLA. So that's high advantage.
If you have any chance, chance to, to be part of a deployment process, for example, there's automation workflow or something like that, you can be a part with automation, automatic onboarding or something like that. It will be really worth to investigate there in, in the interface because you can really save time later. And that's a really success factor if you really save money there for the customer. Well, that was the success factor. In a nutshell, of course I could, could review that or continue one hour, two hours. There are a lot of more points. I hope I hit the most important topics there. Yes. So do you have any questions to.
