At its outset, the blog IDM Project Methodology outlines the main goals of an Identity Management (IDM) methodology, including such aspects as basing project decisions on empirical experience rather than abstract formulations and containing all the complexities, and costs of corporate ID management projects as early as possible during the course of a project. Author Kostas Stamatakis writes that IDM methodology should, first and foremost, provide solutions to repeatable problems during Identity Access Management project lifecycles.

Other goals that the blog enumerates are to generate “return ON investment” rather than “return TO investment”; define in advance the most effective internal selling benefits that the Identity Management project must provide; enable the delivery of measurable business value within two to three months of launch of the Corporate Identity Management project; enable the delivery of measurable business value each and every quarter; and provide increased independence of both the IT organization and the business-user organizations.

By shifting capabilities and responsibilities out to the user community whenever possible and appropriate, both organizations are freed to meet their goals as efficiently as possible, Stamatakis explains.

The blog goes on to discuss how, according to horizontal (rather than vertical) methodology, the four phases of the methodology occur one after the other for each phase of the project, and not for the entire project. By using this approach, Stamatakis writes, functionality is gradually introduced to the user community.

Horizontal implementation is the better of the two approaches to IDM project management, Stamatakis argues, especially when ROI and business value are important considerations. The reason, he notes, is that vertically implemented projects do not proceed until all aspects of the project design are completed, which puts off the delivery of functionality for many months, if not years. Oftentimes, he continues, there is little chance that the vertically implemented project can justify itself quickly enough to avoid an erosion of interest and perceived value on the part of business users and executive decision makers.

On the other hand, projects organized using the horizontal implementation approach are in position to deliver functionality earlier, thus sustaining interest and leading to payoff earlier on, according to Stamatakis.

Horizontal implementation, as the blogger puts it, is " ... basically a backward approach starting from the project end. ... The first question is not what is needed to do in order to implement the project but, rather, what are the specific business values, or process automation processes sought by the organization. Once those business values and/or process automation features are listed and mapped, they are broken down into separate 'mini-projects', with each mini-project devoted to the delivery of a specific business value or automating a specific process."

The next step involves analysis of the " ... mini-projects to determine which of them may be completely delivered in the shortest possible time. ... The end result is that the project is divided into a set of mini-projects, with each mini-project having its own deliverable time and high-level implementation roadmap. Finally, the team decides which mini-projects to complete first, and begins their deployment as though they were completely independent of one another."

The only limitation of horizontal implementation that Stamatakis mentions is that there needs to be a project-wide awareness of all the ramifications involved at any given moment so that members can integrate their efforts productively.

More Information

IDM Project Methodology Stamatakis's blog [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter