Kenneth MyersPresident| Blue Falcon CobraOakton, Va, United States
I'm developing a presentation for projectmanagement.com on Identity Management project management. It follows standard project management, but I want to highlight differences in successful identity management projects. Any suggestions which might of interest or would a basic identity management presentation be better? Saving Changes...
Hi Kenneth: my suggestions would really depend on your audience; if they understand what IdM is, then get technical (remembering that a presentation should not overwhelm with detail!). If this is for a business audience, break it down: what is IdM to them as a business? What is it used for within a project framework? Why is it needed? Who handles it (support)? Project management of an IdM generally involves significant security requirements, it would be useful to give an outline of these (NIST numbers won't help!). Once you answer the questions, maybe as a white paper(?) then you can start to draft your presentation
I would suggest separating the technical aspect from the business solution. I was PM for rolling out Control-SA, several years ago. It required a lot of back end work to get it set up, but that was because of how much we chose to automate. We put agents on Windows, mainframe, Unix, DB2, etc... and each had different password requirements, so we had to do a lot of negotiating on password requirements.
As technical as the implementation was, it was the value we added to the business that made the project a success. In our case, we had a call center where employees regularly locked themselves out of their computers. Because of how the phones were set up, the agents had to notify their supervisor, who called the service desk to get the password reset, and then the service desk would leave the new password on the agents voicemail.
As part of the implementation, we set up a portal then allowed users to connect even when their password was locked. Once on the portal, they could either unlock or reset their password. They could also synchronize their password across the various systems they accessed. Even though we implemented a lot of functionality for the security team, it was the value we gave to the business that really made the project a success.
As a presenter and attendee there are some basic rules but I'd suggest the following:
Overview, trends, successful projects to solve business problems, takeaways and action items for the audience. Good luck! Saving Changes...
Kenneth MyersPresident| Blue Falcon CobraOakton, Va, United States
Jan 21, 2017 2:41 PM
Replying to Tracy Alldridge
...
Hi Kenneth: my suggestions would really depend on your audience; if they understand what IdM is, then get technical (remembering that a presentation should not overwhelm with detail!). If this is for a business audience, break it down: what is IdM to them as a business? What is it used for within a project framework? Why is it needed? Who handles it (support)? Project management of an IdM generally involves significant security requirements, it would be useful to give an outline of these (NIST numbers won't help!). Once you answer the questions, maybe as a white paper(?) then you can start to draft your presentation
Thanks Tracy. Sounds like a great starting point. Saving Changes...
Kenneth MyersPresident| Blue Falcon CobraOakton, Va, United States
Jan 23, 2017 1:24 PM
Replying to Aaron Porter
...
I would suggest separating the technical aspect from the business solution. I was PM for rolling out Control-SA, several years ago. It required a lot of back end work to get it set up, but that was because of how much we chose to automate. We put agents on Windows, mainframe, Unix, DB2, etc... and each had different password requirements, so we had to do a lot of negotiating on password requirements.
As technical as the implementation was, it was the value we added to the business that made the project a success. In our case, we had a call center where employees regularly locked themselves out of their computers. Because of how the phones were set up, the agents had to notify their supervisor, who called the service desk to get the password reset, and then the service desk would leave the new password on the agents voicemail.
As part of the implementation, we set up a portal then allowed users to connect even when their password was locked. Once on the portal, they could either unlock or reset their password. They could also synchronize their password across the various systems they accessed. Even though we implemented a lot of functionality for the security team, it was the value we gave to the business that really made the project a success.
Thanks Aaron. What product is Control-SA? Saving Changes...
Community Champion
