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.

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