I just read an interesting blog entry on Mike Wyatt's Blog entitled "Project Managers as a Critical Success Factor or Identity Management Projects". It peaked my interest because it has become a recurring topic of discussion amongst some of the folks in our integration team. Mike talks about clients not wanting to shell out the extra service dollars for the PM, opting to use their own "experienced" PMs. Mike aptly points out...
...in order to "get the deal done" vendors will make this concession. More often than not, when a project gets in trouble, the common issue is not technology (the bits) or even the vendor's technical team. It is usually the lack of strong project management, especially when customers are providing the project manager.
A few points that our team has come up with:
- Use Case definitions for identity projects are quite helpful, especially in defining expected behavior of the IdM system based on predefined inputs. Many times, PMs get caught up in the tasks that need to be completed, and become task masters who babysit the team to ensure that tasks get done, many times losing the big picture. What is the big picture? Its what the client wants, and that needs to be defined up front. So one of the first tasks for a PM should be to engage the client in order to clearly identify the use cases with accompanying pre-conditions and post-conditions. This document should read easily for any business user, so that the client PM (or equivalent) agrees to the exact desired behavior of the system upon project completion.
- If the use case document is clearly written, it can be used for project sign-off in the development environment, prior to migration. A meeting can be used to bring all relevant players together in order to demonstrate that the system behaves exactly as the client requested - using the use case document as a checklist. "This is what you wanted. Let me demonstrate that for you...great, it works. Let's check it off and go to the next use case."
- In the "Use Case" phase, the PM could be used heavily while using the architect for reference and sanity checks. Once the Use Case is completed, the PM could take a back seat and let the architect roll up his/her sleeves. The PM from this point only needs to monitor the project rather than to be involved and bill day-to-day. (Of course, the architect has to step in to ensure feasability before the use case is signed off on by both parties.) This shows the client that you could use a PM (and architect) effectively, and make them feel comfortable that it won't cost them a substantial services fee at the same time.
More to come on the PMs continuing role in the project...
Posts
