Tuesday, August 02, 2011
Going Fishing for IdM
What Eye is this? Well, it's the FishEye group. Currently specializing in OIM, this practice features some pretty savvy architects, engineers and old friends. I'm looking forward to seeing what they can do!
Wednesday, December 29, 2010
2010 and the Year in Identity
Tuesday, October 05, 2010
Couple of Random Things
However, I do have a couple of quick things that I'd like to share.
First off, I will be at SAP TechEd, which will be in a little under two weeks from now, in Las Vegas. If you're going to be there, please leave me a comment or let me know via a comment, LinkedIn, XING, or any other way that works for you. There's going to be a lot covered for NetWeaver IDM and I plan to report on it. Would not mind having a little after hours round table.
Also I've been picked up on the Planet Identity blog. Looking forward to being a part of that conversation as well.
Tuesday, June 29, 2010
Credit Where Credit is Due!
Saturday, April 10, 2010
SAP IdM Training - Wrapup
Wednesday, March 31, 2010
Monday, March 29, 2010
News Update
Monday, February 23, 2009
Managing Project Communication
I've written before on the topic of how to prevent project failures, but very little about what happens as projects are failing. I was recently chatting with some colleagues about what does happen when a project begins to head south.
First of all, there always seems to be a tendency to blame the outsider. Basically this argument looks something like: "You never got the requirements right (from the customer) / you never delivered correct requirements (from the consultant)"
What does this boils down to is a failure in communication. Now the question from a risk management approach is how one keeps this communication in sync. Based on our discussion we came up with the following:
- Regular status meetings. If your executive sponsor is not at these meetings, schedule regular steering committee updates which should be just the project manager(s), architect(s) and the executive sponsor. They might not need to be weekly, but they must not be optional any of these people. Do not rely on only one side to make these reports. Everyone must be on the same page. Make sure the sponsor is aware of the key challenges so that there are no surprises.
- Obtain consensus and settle the issues quickly and decisively. If there are dissenting opinions about major decisions, get the issue settled once. Don't keep circling on the issue. If there's an issue that just won't go away, get the parties in front of the executive sponsor as I've noted above. Get a final ruling and move on.
- Establish change controls. For some reason, no one likes to use these. There's a feeling that these are things to hide behind, rationalize additional cost or bog down the project in extra paperwork. None of these are true. All that's being done here is making sure that all project principals are aware of the change. This establishes responsibility and sets up controls for making sure that things don't get out of control. And I'd imagine that the amount of paperwork involved in a change control is minor compared to having to write the report of why the project failed. Trust me, this is not fun.
- Use and establish some sort of project strategy/methodology. I don't care what it is, but make sure a project plan exists and that there is structure in place. There should be a project manager who will make sure that there is a plan to complete the project, but the architect and senior engineers should make sure that there are development standards which must also include documentation!
These points are intended to increase communication and decrease mistrust and politics. If the project team meets regularly, tracks what they are doing and how the project changes and has a structure for managing progress and change there is less of a chance of having a post-mortem and more of a chance of documenting the best practices that were done right!