From Procurement to Implementation: Mastering the Implementation of your SaaS IGA Solution [Intermediate]

In our session we will concentrate on how you will succeed in the IGA project. The next session with Dion will be about why the projects fail, but we are trying to concentrate on the success. Shortly about us. I work as a tech lead at S-Group. I have worked all my career in digital identity, basically with the authorization, authentication, directory services and cloud security. Our company is called S-Group. That's a Finnish cooperative corporation. We do retail. We have 50% market share in Finland in the grocery chain.

We have the fourth biggest bank in Finland, logistics, restaurants, hotels, energy business and all that kind of stuff. The S-Group consists of 50 co-ops and SOK, which is our employer, is kind of the centralized organization, which is providing, for example, IT and security services.

All right, you can introduce yourself. Hi, I'm Timo Majaneva, program manager and architect at S-Group. I have a quite long experience regarding project management, especially in IEM related projects. I guess my role is kind of take a business and take IGM and put together and try to enhance security. And in free time I'm golfing, skiing, fishing, playing guitar and rock band.

Okay, in this slide we highlight the key phases of SAS IGA project. There are six phases, which we're going to explain in more detail in the following slides. But maybe a special attention will be given to phase project delivery and phase testing and asset dams.

All right, so maybe most of the IGA projects start with the procurement. So your goal is to find the best product and the best implementation partner. There are kind of three sub phases in the procurement. So basically the RFP phase, where you kind of try to achieve understanding the market. So you should have as many vendors and implementation partners as possible in the RFP. And then kind of disqualify them fast to the RFP, where you should only have two. And in the RFP, it's quite hard often to get the cost transparency.

That's because different licensing models and so on, and also standardized evaluation. So what kind of scorecards are you having? And after that, you probably move to the baffle and contract award, where you select your solution and implementation partner. And you should design your procurement in a way that you disqualify fast, so you don't spend that much time for vendors or products that you're probably going to buy anyway. Then next up is the negotiations.

So you try to ensure that you have a clear and fair, and it's also very important in my opinion, because I have been working in both sides, so consulting and customer side. So in a way that the agreement is beneficial for both parties. And basically, don't try to drive the costs down or the hourly pricing, for example, down, because you will get worse resources. So if you want to have a very experienced ITA team from the implementation partner, you should probably not try to drive the costs down in the individuals also. In our project, maybe a short background on our project.

So we had our ITA project, which started a year ago. We just closed it. We have 65,000 internal and external employees and a lot of summer workers and so on. And in our negotiations phase, by the way, the product is Saviant and the implementation partner is DNV. So we quite soon noticed that the solution outline is very hard to do if we don't do the pre-study.

So basically what we did, we had a comprehensive one month workshops with the DNV architects and developers, where we kind of draw out all the interfaces and integrations, went through the IAM landscape of S-Group and find out all the technical components that we had and then build the project plan based on that. And then attach the project plan to the agreement. All right.

Yeah, maybe I'll continue. Yeah, actually the project initiation is a part before project start. And it's some purposes, it defines the project scope, it defines the project purposes and things like that.

And yeah, it's very important that you initiate your project very carefully, because it's in that point you said how well your results will be. Planning, focus on refined plans, completing tasks, collecting methods and tools, and of course define the scope. Scope is very important in project. Management addresses, deliverables and asset and right areas, which are also very important.

Timelines, milestones, financial controls and communication protocols. In governance, asset roles and responsibilities, start risk management and other project management domains like change management and so on. And then kick off the project. And Janne mentioned solution outline, which actually created during negotiation phase. And now it turns the project first baseline. And it's important that everybody knows what we are going to do, what this project going to deliver and so on. And when the project is completed, then we have the final baseline. And of course there will be some changes.

There's any project which going through any changes. Scrum framework is recommended for daily very base, because it's flexible, it's iteratively. Of course you can use some other project management methods if that is more suitable for your project. Design creates the user stories and of course collecting requirements and so on. Define product design, refine backlog and plan the sprint work.

Delivery, implement and test continuously user stories. That's an ongoing process during the delivery phase. Collaborate effectively, deliver work increments and review the results. And start the documentation in centralized tool. For example, Confluence is very good for this purpose. Apply templates and version controls and link documentation to Jira issues. That makes project management easier for everybody, because you can find everything in one place. And keep also document at JIL. Scrum ceremonies are also essential for good project.

For example, daily dance ups, review the results and so on. In the delivery phase we build and in the acceptance and testing we test what we have built. And does it meet all our requirements. We have the end-to-end testing during the sprints to validate the full workflows. That was kind of the easy part. But then the user acceptance testing is in my opinion the most critical part of your project. And it will take a lot of time. So if the building takes three months, then the testing will probably take at least two or so.

Basically you should have your best IAM experts or hire someone who knows very well your organization. Basically we had three guys doing the acceptance testing. And then we have an external consultant who had worked for us for 20 years and developed our old ITA system. So basically we had this kind of team verifying that all the processes were built correctly. And even though we did a lot of testing and rebuilt a lot of things. In the end when we went to the production, we have such a large environment. So there was still some little pieces.

For example, some HR attribute in some sub-company, co-op company. They had some different naming standards and so on. So those kind of small issues were still there. Then about the go-live. So after you have accepted your user acceptance testing and kind of signed it off. Then you will have the go-live planning. Probably the most important part of that is the communication. So basically you should have different communication plans for different audiences and stakeholders. We built this kind of IAM hub, which is a SharePoint page where there are all the learning materials.

There is a link for the Saviant University, how you could educate yourself. Then there are also videos about the most common use cases with Saviant. So how to do the access request or how to approve an access request and so on. Maybe the next phase is managing the chains. So we're trying to have as much like boosting the IAM hub as possible. So people would find it and frame themselves before the go-live. Maybe the last part is the project sign-off, which we have now done. Collecting the lessons learned and then prioritizing the backlog.

So we have quite many items that we needed to drop out during the project. To be on time and budget, so to say. So there will be the items for the phase two. All right. Then we have collected six key success factors for your IGA project. Many of those are quite common sense, but they are still missing in most of the projects. They are not very clearly defined, so to say. So first one, you should have clear business objectives. Our business objectives for this or the vision and strategy for this was to enhance the security, compliance, cost efficiency and productivity.

That sets the goal for the whole project and the organization to transform towards the new world, so to say. Then define the governance model. This is something that we had planned, but it is still kind of in the building phase. Basically me and Timo have been doing all the decisions in the project. We don't have a steering committee in this project of this size. But that is something that we would need in many cases. So the management support and also clear process for decision making.

Yeah, it's hard to make the management understand how important this whole part is, our business. Yeah. Then have a clear I.M. vision and strategy. I already mentioned about that. Have a right tool in place. That's kind of obvious to say, but there are some cases that you're selecting wrong implement. I think most organizations select the right product, but then they kind of struggle with the implementation partners. And that may be, for example, based on the cost driving and so on. Like cost driving decision making.

Yeah, I would say that choose integration partners which have a clear method for implementation. It makes it much, much easier to implement the whole thing. Yeah. And which has, let's say, 15-20 implementations in the background. So that will make the whole journey much smoother. Then manage the change with the communications, trainings, certifications and all that. And maybe last but not least is the cross-functional collaboration. So basically, we already started that before the procurement process. We started collecting and contacting different organizations and co-ops in S Group.

To kind of engage them and give them information about the procurement of the IGA product. And the benefits and what we will require from them. For example, we have a bank. So there is quite a lot of compliance matters and those kind of things that we need to take into account.

Okay, maybe one thing more. Have fun on your IAM term. Thank you.

Yep, thanks. Thank you. Do we have any questions in the audience?

Okay, I would have one question. Of course, I'm the moderator, I need to ask questions.

So, we talked about business objectives. And you also mentioned to make management understand the importance of what we are doing.

So, what would you say, what is the right time to involve our stakeholders? And how do we convince management of our initiative?

Well, I would say as early as possible. Yeah, as early as possible. You are kind of forced in many organizations because you need to get the investment, the money from the top management.

So, you are kind of required to have a plan and like the investment plan and so on for the top management. But as early as possible. And quite many times the starting point is that the whole IAM is IDs and passwords. And you start to explain to management what actually is IGA and all those terms. You can turn it, let's say, in common language. IAM is IAM, yeah. And you start to explain what is it. It takes time. And maybe one comment. What we have now done is basically we have rewritten the whole IAM policy.

And we also included the IAM steering committee, which will be kind of conducting reviews quarterly. And that's because we find it very hard to kind of always explain the whole terminology. What is IGA? What is authentication? And so on.

So, that's why we have now kind of built this kind of system from selected people from the management to kind of go these items through like once a quarter. And that will kind of drive our change faster than always starting from nothing, so to say. That's a great point. Finding a common language.

I mean, as complex added guests, we need to understand each other. There was a question from the audience. Can we take it? It was here at the front. Thank you for the presentation. I have one question regarding the title. You have said implementation of a SaaS IGA solution. But I am not sure if I missed something. Do you see differences between implementation of a SaaS IGA and an on-prem IGA?

Well, I think building the platform will be much, much harder, so to say. So, if you are buying a SaaS IGA, the only infrastructure that you will need is kind of a connector service for your on-premises AD and so on. But when you are building an on-premises IGA solution, you need to kind of make the whole. Whole server platform.

Yeah, and the SQLs and databases and so on. So, I think that phase will take much more longer. Perfect. Thank you so much. Are there any other questions?

Okay, then. Thanks again.

Yeah, thank you. All right. Thanks a lot.