In an earlier post, I said that June is going to be identity and access management month. I will be making key posts during the month touching on different aspects of the technology.
As with any new technology, I think it starts with making a solid business case. A business case needs the following as a minimum:
- A strong business champion
- Demonstrated ROI on the project
- Case studies that prove the technology is viable
- Direct benefits to the business
- A set of business requirements
A business champion
Every project needs a champion. This person takes the responsibility to sell it to the rest of the organization as well as overall responsibility for its success. When possible, champions should come from the business. When a champion comes from the business, this shows that they have a stake in the project as well.
You can usually get ROI figures from vendors. I would be careful about using these. Ask your prospective vendor to tailor the ROI numbers to your organization, taking your specific business environment into consideration.
I personally like case studies. Case studies allow me to understand the problems a business had and what technology was implemented to address those problems. Although vendors are very happy to supply case studies, they should be given the same scrutiny as ROI figures. Case studies usually give specific company names and contacts so you can call and verify the case study with the company and learn first-hand the value the technology brought to the company.
Let's face it, the business wants to know how it will benefit from using this technology. Yes, the ROI is important, but what other benefits will the business gain? Other benefits might include first to market, reputation and competitive advantage. Although these other benefits might be difficult to quantify, your organization's marketing and sales departments can use these benfits as additional selling points.
Requirements are not generally part of a business case, but I like to include them because it lets senior management know that I did my homework and I understand the needs of the business. Generally, functional requirements are all that's needed. The following is a basic example of a functional requirement for an identity and access management application:
"The applicaiton or system, must be role based. The application should allow the administrative staff to create templates based on roles and be extensible, based on existing roles. In addition, the administration of roles must be managed from within the business by a designated representative."
The business looks at identity and access management as a security project. Security projects are not usually at the top of the list of "must do" projects. Security professionals usually have to resort to providing threatening scenarios to the business as to what might happen if they don't buy off on a project. I don't see identity and access management as a hard sell, but it's always smart to have a good business case to back you up.