Skip Links

Seven ID mgmt. project risks and how to avoid them

Seven risks of identity management projects

Security Identity Management Alert By Dave Kearns, Network World
January 30, 2006 12:53 PM ET
Kearns
Sign up for this newsletter now!

The foundation for security and enterprise management

  • Print

In the "predictions for 2006" issue of a few weeks ago, I offered thoughts from industry insiders as to what the new year might bring. One of those predictions, offered by Sun's Mark Dixon was: "2006 will bring new methods for more quickly and easily implementing identity management solutions."

Dixon, who carries the mouth-filling title, "Practice Lead, South Central Area, Identity Management Practice, Sun Microsystems," is now back with a caveat: There are seven risky behaviors that could kill your identity management project. He lists them as:

1) Poor pre-project preparation.
2) Poor requirements definition.
3) Large initial scope.
4) Inexperienced resources.
5) Poor project methodology.
6) Scope creep (the project grows bigger each time someone takes another look at it).
7) Not using available support.

And I certainly can't disagree. While the seven (Dixon wanted to call them the "7 deadly risks," others at Sun thought this too over the top - those people should be reassigned) can be said to be true about any project, they seem to crop up on identity projects much more frequently than on, say, Web site design projects.

Dixon has promised to explore each in depth over the next few weeks at his Discovering Identity site, and you should all - especially those involved with planning or implementing identity projects - pay heed. Today I simply want to draw attention to risk No. 2, which can facilitate No. 6 usually due to No. 5.

Many times over the past few years I've emphasized taking what I call baby steps - small projects with short-term milestones that enable early success (click here for an example). This doesn't mean creating many individual projects, but creating a single project with multiple deliverables and milestones spread over a long period of time.

Each of these "mini-projects" is then susceptible to being well-defined and well-planned as they have a single, easily understood purpose. Because that purpose is readily understood by the potential customer base (your users), the risk of "scope creep" is minimized.

People tend to want to broaden the scope (or increase the feature set) at the point they have an "aha!" moment - the point at which they get the breakthrough which causes them to finally understand what the project is intended to do. If this moment comes before the project is initiated (because your mini-project is easily understood) then the "aha!" occurs in the planning stage, not during late beta trials. Of course, good methodology (e.g., only letting people who "get it" test the pre-release project) can also minimize the number of folks who might have late-in-the-cycle "aha!" moments.

There's nothing radically new here, it's all tried and true project management stuff, but it bears repeating. If you think that "everyone knows" this stuff, the realization that new team members don't know it can come too late and could doom the project. Follow Dixons' exegesis on identity project management - it can't hurt, and it may do you much good.

Read more about security in Network World's Security section.

Dave Kearns is a consultant and editor of IdM, the Journal of Identity Management.

  • Print

Videos

rssRss Feed