Costing an IdM implementation project - how to anticipate surprises
The next block of our publications on IdM will be devoted to finance. Namely, the two most difficult and painful topics are the evaluation of the IdM implementation project and its justification before management.
The total cost of an IdM project is made up of equipment costs, software licenses, the work of the contractor and the project team. According to experience, the main difficulties are connected with the assessment of the cost of work on the implementation of the system, so we will begin with this question.
Difficulties with assessment usually arise due to insufficient elaboration of system requirements. Due to the peculiarities of IdM technology, it is objectively difficult to accomplish this task at the proper level without attracting contractors. But convincing management of the need to finance a project to prepare for implementation is even more difficult, so the company often simply accepts risks and hopes that they are not implemented.
The risks are quite serious. In particular, they consist in the fact that the contractor will overstate the cost of work in order to reduce its own project risks, and then the project budget may not be agreed at all. Or, on the contrary, an optimistic assessment will be issued and defended, but already during the implementation it will become clear that the tasks set cannot be solved for the indicated budget.
We will try to help organizations prepare and evaluate IdM implementation projects: we will take a closer look at the main blocks of implementation work and the factors that significantly affect their workload.
At the first stage, as a rule, the collection and analysis of requirements is carried out, the design of a technical solution - in short, everything is approximately the same as in projects for the implementation of other information systems.
It includes interviews with representatives of key project stakeholders, collecting data on access control processes, information systems that are within the project boundary, how they manage users, and how to integrate with them.
The cost of this stage depends on the number of employees you want to interview, and the information systems for which you need to collect data. Its complexity is more or less predictable, and the duration on average is 1-2 months.
One of the main technical units of work is the connection of information systems. It is carried out on test environments, the provision of which could be a stumbling block for some companies. There may be no test environments, there may be no servers, hands, etc. for them. Most often this affects only the project’s time frame, but may also affect the budget, for example, in case of a shortage of equipment.
Often, to integrate an information system with IdM it is required to configure it, providing interfaces for technical interaction. If the information system is supported by a third party, this may incur additional costs. Some vendors (for example, Diasoft) provide the required technical interfaces, but at an additional cost. Even if the customer supports the system on his own, there may not be enough time or competence of his own specialists to provide the necessary technical interfaces. This affects the timing and budget of the project.
Information systems connect to IdM via connectors. A vendor may declare that he has ready connectors to all your information systems, but in reality everything is not so simple, and, as they say, there are nuances.
Information systems that provide a standardized interfacing interface (for example, AD) practically eliminate the risks that a ready-made connector will not work. However, there are a number of information systems (for example, 1C and SAP) that allow you to provide various options for interacting with IdM: uploads, web services, views in a database. You may prefer a particular option to which the manufacturer of the connector does not have, and you will need to refine / develop it. And this is time and money again.
There may be a lot of other features that significantly affect the timing and cost of the project.
The interface may be standardized, but provided through an integration bus, which may also require the redesign of the connector. If the vendor has adapted his information system for you, the standard connector may not be suitable - and again you will need to set budgets and time for refinement.
An important role in connecting information systems to IdM is played by the technical details of access control to information systems. Often they are not visible at the initial stage, but ultimately lead to an increase in the amount of work. For example, when in order to provide access to a new user to one information system, it must be registered in two others.
Sometimes additional or built-in operations that are required from IdM fall out of focus. For example, if you want to not just create a new employee mailbox in Exchange, but according to certain rules choose a storage for him. In one of the projects, we encountered an information system in which it is technically impossible to assign more than one role to a user. When it turned out, we had to completely redesign the access control process in it to take into account the process of requesting additional permissions, which can be many. There may be quite a few such trifles, this is all additional work, and not every IdM system can support them.
Taking into account these features, the laboriousness of connecting an information system to IdM can vary significantly depending on the company's infrastructure, and the duration can be from two days to two months. As a result, the lack of detailed information at the assessment stage greatly reduces its reliability and increases project risks.
A significant block of work, which can also significantly affect the project costs, is setting up the processes of filing and approving applications for access. If your processes are supported by the selected software, then it is easy to set them up. But, without knowing the processes thoroughly, you can only very roughly estimate how software supports them. Accordingly, it is difficult to understand whether revision is needed and to what extent.
Many of the problems of process automation are connected precisely with the fact that very few people understand how they work in detail. As a result, processes often have to be reconfigured during the pilot operation of IdM. The scale of rework of the IdM system depends on the number of unaccounted nuances. Here's what to look for:
All these elements may have their own characteristics in each company, and they are not visible without detailed immersion. Sometimes even a simple process element can lead to a noticeable change in the scope of work.
For example, if the regulation has a rule that an application that is not agreed upon within two working days should be escalated, this raises a whole layer of questions for IdM: where to keep the production calendar, who will do it, can it be possible to integrate this information with this information? or an existing system, etc. Therefore, the cost of adapting specific software to automate access control processes (and its general need) can be assessed only after a detailed drawing of these processes. Otherwise there are risks that automation will not be done in full.
Contrary to user expectations, practice shows that reports are rarely typical. Given the differences in the details of the processes (for example, a simple difference in the attributes of the employee card), each time the reports are required slightly different. Their preparation does not take much time only provided that the IdM system audit log contains all the necessary data. And to assess the availability of this data without the form of report templates will not work out reliably. Therefore, it is very useful for the evaluation to have the forms of the desired reports, otherwise it may be necessary to reconfigure or revise the audit.
This is a very cunning block of project work. Some companies have standards for project documentation - a list of documents and requirements for their execution (for example, according to GOST). In some organizations, documentation is less formal and is satisfied with the vendor’s documentation.
Since the IdM system configures the processes of a particular organization, full-time documentation on software rarely fits. You will have your own categories of users - employee, manager, resource owner - they will have certain application forms, interface sections, reports, alerts, and they will need separate instructions. It will also be difficult to develop the system without an explanatory note, to take on operation without the instructions of the administrator. Sometimes, in addition to the documentation, training materials are required - presentations, videos. If the number of persons with whom all these materials need to be coordinated is large enough, the development of documentation may require several hundred person-days, although at the initial stage this unit is greatly underestimated.
These stages are more or less deterministic. The main tasks that can somehow affect the duration and cost of work is the loading and binding of data.
In the IdM system, it is required to fill in all the necessary directories, assign persons responsible for roles, fill in the catalog of authorities, set up roles. This can be done in automatic mode, then the corresponding data will be required.
Associating employee cards with accounts is also mostly automatic, according to the rules. However, there is always some percentage of accounts that need to be linked manually. And sometimes it’s not so easy to find their owners.
Pilot-industrial operation in most companies takes place within a month, and in terms of costs, it is almost always exactly predictable.
Estimating the total cost of an IdM implementation project requires taking into account the cost of equipment, licenses, and sometimes the project team’s time, but these issues are often not as difficult as evaluating the implementation of the system due to the complexity of their calculation and, at the same time, a significant impact on the project’s success.
I tried to collect all the main factors that significantly affect the duration and complexity of implementing the IdM system, and I hope that this will help companies pay attention to key points when preparing a project, formulate more complete requirements, get a better assessment, and ultimately reduce project risks of budget overruns and human resources.
In a week I will try to collect for you all the best practices of justification from the management of the project on the implementation of IdM.
The total cost of an IdM project is made up of equipment costs, software licenses, the work of the contractor and the project team. According to experience, the main difficulties are connected with the assessment of the cost of work on the implementation of the system, so we will begin with this question.
Difficulties with assessment usually arise due to insufficient elaboration of system requirements. Due to the peculiarities of IdM technology, it is objectively difficult to accomplish this task at the proper level without attracting contractors. But convincing management of the need to finance a project to prepare for implementation is even more difficult, so the company often simply accepts risks and hopes that they are not implemented.
The risks are quite serious. In particular, they consist in the fact that the contractor will overstate the cost of work in order to reduce its own project risks, and then the project budget may not be agreed at all. Or, on the contrary, an optimistic assessment will be issued and defended, but already during the implementation it will become clear that the tasks set cannot be solved for the indicated budget.
We will try to help organizations prepare and evaluate IdM implementation projects: we will take a closer look at the main blocks of implementation work and the factors that significantly affect their workload.
Survey
At the first stage, as a rule, the collection and analysis of requirements is carried out, the design of a technical solution - in short, everything is approximately the same as in projects for the implementation of other information systems.
It includes interviews with representatives of key project stakeholders, collecting data on access control processes, information systems that are within the project boundary, how they manage users, and how to integrate with them.
The cost of this stage depends on the number of employees you want to interview, and the information systems for which you need to collect data. Its complexity is more or less predictable, and the duration on average is 1-2 months.
Connection of information systems
One of the main technical units of work is the connection of information systems. It is carried out on test environments, the provision of which could be a stumbling block for some companies. There may be no test environments, there may be no servers, hands, etc. for them. Most often this affects only the project’s time frame, but may also affect the budget, for example, in case of a shortage of equipment.
Often, to integrate an information system with IdM it is required to configure it, providing interfaces for technical interaction. If the information system is supported by a third party, this may incur additional costs. Some vendors (for example, Diasoft) provide the required technical interfaces, but at an additional cost. Even if the customer supports the system on his own, there may not be enough time or competence of his own specialists to provide the necessary technical interfaces. This affects the timing and budget of the project.
Information systems connect to IdM via connectors. A vendor may declare that he has ready connectors to all your information systems, but in reality everything is not so simple, and, as they say, there are nuances.
Information systems that provide a standardized interfacing interface (for example, AD) practically eliminate the risks that a ready-made connector will not work. However, there are a number of information systems (for example, 1C and SAP) that allow you to provide various options for interacting with IdM: uploads, web services, views in a database. You may prefer a particular option to which the manufacturer of the connector does not have, and you will need to refine / develop it. And this is time and money again.
There may be a lot of other features that significantly affect the timing and cost of the project.
The interface may be standardized, but provided through an integration bus, which may also require the redesign of the connector. If the vendor has adapted his information system for you, the standard connector may not be suitable - and again you will need to set budgets and time for refinement.
An important role in connecting information systems to IdM is played by the technical details of access control to information systems. Often they are not visible at the initial stage, but ultimately lead to an increase in the amount of work. For example, when in order to provide access to a new user to one information system, it must be registered in two others.
Sometimes additional or built-in operations that are required from IdM fall out of focus. For example, if you want to not just create a new employee mailbox in Exchange, but according to certain rules choose a storage for him. In one of the projects, we encountered an information system in which it is technically impossible to assign more than one role to a user. When it turned out, we had to completely redesign the access control process in it to take into account the process of requesting additional permissions, which can be many. There may be quite a few such trifles, this is all additional work, and not every IdM system can support them.
Taking into account these features, the laboriousness of connecting an information system to IdM can vary significantly depending on the company's infrastructure, and the duration can be from two days to two months. As a result, the lack of detailed information at the assessment stage greatly reduces its reliability and increases project risks.
Business processes
A significant block of work, which can also significantly affect the project costs, is setting up the processes of filing and approving applications for access. If your processes are supported by the selected software, then it is easy to set them up. But, without knowing the processes thoroughly, you can only very roughly estimate how software supports them. Accordingly, it is difficult to understand whether revision is needed and to what extent.
Many of the problems of process automation are connected precisely with the fact that very few people understand how they work in detail. As a result, processes often have to be reconfigured during the pilot operation of IdM. The scale of rework of the IdM system depends on the number of unaccounted nuances. Here's what to look for:
- Types of IT users - for example, full-time / non-regular employee. Often they work within completely different business processes.
- Process participants . It should be understood which roles are involved in the processes and from where the system receives data about them. For example, if the manager participates in the approval process, then the managers of the employees should be placed in the personnel system or in some other way get into IdM.
- Additional data for processes . For example, if the process requires data on employee training, you need to understand where the IdM will receive it. This is either an additional integration or a manual process.
- Negotiation routes . They may be different for different employees, depending on the authority or any external conditions.
- Exceptional situations . It is important to envisage the behavior of the system for situations where the person responsible for coordination on vacation or dismissed is how to act and where to get the necessary information.
- Alerts . As part of automated processes, the IdM system sends notifications to participants. The question is who on what steps and what information should be received.
- Application forms . Often the company needs to adapt the forms of filing or approval of applications, for example, to display additional information for decision-making.
All these elements may have their own characteristics in each company, and they are not visible without detailed immersion. Sometimes even a simple process element can lead to a noticeable change in the scope of work.
For example, if the regulation has a rule that an application that is not agreed upon within two working days should be escalated, this raises a whole layer of questions for IdM: where to keep the production calendar, who will do it, can it be possible to integrate this information with this information? or an existing system, etc. Therefore, the cost of adapting specific software to automate access control processes (and its general need) can be assessed only after a detailed drawing of these processes. Otherwise there are risks that automation will not be done in full.
Reports
Contrary to user expectations, practice shows that reports are rarely typical. Given the differences in the details of the processes (for example, a simple difference in the attributes of the employee card), each time the reports are required slightly different. Their preparation does not take much time only provided that the IdM system audit log contains all the necessary data. And to assess the availability of this data without the form of report templates will not work out reliably. Therefore, it is very useful for the evaluation to have the forms of the desired reports, otherwise it may be necessary to reconfigure or revise the audit.
Documentation
This is a very cunning block of project work. Some companies have standards for project documentation - a list of documents and requirements for their execution (for example, according to GOST). In some organizations, documentation is less formal and is satisfied with the vendor’s documentation.
Since the IdM system configures the processes of a particular organization, full-time documentation on software rarely fits. You will have your own categories of users - employee, manager, resource owner - they will have certain application forms, interface sections, reports, alerts, and they will need separate instructions. It will also be difficult to develop the system without an explanatory note, to take on operation without the instructions of the administrator. Sometimes, in addition to the documentation, training materials are required - presentations, videos. If the number of persons with whom all these materials need to be coordinated is large enough, the development of documentation may require several hundred person-days, although at the initial stage this unit is greatly underestimated.
Translation of the system into the production environment and pilot operation
These stages are more or less deterministic. The main tasks that can somehow affect the duration and cost of work is the loading and binding of data.
In the IdM system, it is required to fill in all the necessary directories, assign persons responsible for roles, fill in the catalog of authorities, set up roles. This can be done in automatic mode, then the corresponding data will be required.
Associating employee cards with accounts is also mostly automatic, according to the rules. However, there is always some percentage of accounts that need to be linked manually. And sometimes it’s not so easy to find their owners.
Pilot-industrial operation in most companies takes place within a month, and in terms of costs, it is almost always exactly predictable.
Summary
Estimating the total cost of an IdM implementation project requires taking into account the cost of equipment, licenses, and sometimes the project team’s time, but these issues are often not as difficult as evaluating the implementation of the system due to the complexity of their calculation and, at the same time, a significant impact on the project’s success.
I tried to collect all the main factors that significantly affect the duration and complexity of implementing the IdM system, and I hope that this will help companies pay attention to key points when preparing a project, formulate more complete requirements, get a better assessment, and ultimately reduce project risks of budget overruns and human resources.
In a week I will try to collect for you all the best practices of justification from the management of the project on the implementation of IdM.