We had some great sessions last week! Throughout the 10+ meetings, we had excellent turnout and participation from the many different schools and departments around the University. A ton of good process information was collected, and now Identropy has the (unenviable) task of analyzing it all and presenting a distilled version back to the team.
One common theme that sort of emerged for me after mentally digesting last week is the sense that any identity management project is really a series of balancing acts. On many different fronts, decisions need to be made that will impact large numbers of users, while still accomplishing the overriding goal of the project. For example,
Business Processes:
Current processes are most likely deficient in some way (inefficient, or insecure) but introducing new processes or procedures requires the buy-in of many different departments. It's important to balance their needs when implementing changes -- not to cause too much disruption to their daily routines and deliverables, while still making meaningful improvements to the processes as required by the project.
Technology:
Specifically, keeping current technology versus introducing new products. There may be times when existing products may be sufficient to achieve the goals laid out by the IdM project, but more often than not, you're going to have gaps in the stack of software installed today. The bigger question is whether to replace current systems with different vendors. It's a tough call -- on the one hand, you have already invested time and energy into learning your current product, and have some institutional knowledge around it. On the other hand, it may not be the right solution for the ultimate end-state, and the project would be better served with a new or different product, which of course introduces some learning curve issues for admins, on top of all the other process changes going on simultaneously.
Project Timeline/Deliverables:
As I discussed in a previous post, determining the scope of the initial phase of your IdM project is key to the overall success of it. Doing too much at once will likely cause burnout, and potential failure, but making too little concrete progress will cause problems with project sponsors and the leadership team who want to see that the (increasingly tight) IT budget is being well-spent.
