When a new technology comes along, no one, apart from the original developers, really understands how it works and what can be achieved (and more importantly what can't be done!) As the product becomes better understood and more widely used the ways of doing things (methods) become more defined and shared among the community. Professional Services organisations bring those methods together and create methodolgies (a  grouping of methods) that they will then follow when undertaking a project utilising that technology.

This has certainly been true of Identity Management products.

I remember in the early days of Novell's Identity Manager (known as DirXML originally) working with a couple of consultant colleagues as we grappled with understanding how it worked and what it was doing. After a few months we thought we knew the best way of working with it, and then one of the original engineers showed us a "feature", and things suddenly got a whole lot easier. As that product matured, it has become a lot easier to use with an ever growing set of options open to the designer/developer.

Whenever I am part of an IDM project, I always look to using the best available people, and if they are not immediately available, bringing them in as soon as possible. And I always ask them to help other people to learn a bit more.

What became as important as understanding the technical methods of delivering the project, was the initial designs, the test plans, the testing regime and the management of all those pieces. It was also crucial to learn from other partners and clients about what they had achieved and how they had done it.

While the process is important to follow, the focus of your attention should always be the final deliverable(s). Follow the methodology with your end game in mind all the time.

I believe that no two IT projects will have the same project approach for obvious reasons - the requirements are always unique.  For this reason, while I encourage you to use someone to deliver who has a well-defined methodology, you should also look for someone who is prepared to be flexible in the way they apply it.

So, use a clear, well defined and proven project approach, use the best people you can (and get them to mentor junior staff), and when you think it's all over make sure you all sit down and learn from the good and the bad of the project.

We all have our own preferred way of doing things, but if you'd like to take advantage of my experience in delivering successful IDM projects give me a call or email me using the details below.