I don’t know who invented the term ‘boiling the ocean’ but it is a great description for projects that are too large, too ambitious and, ultimately, headed for failure. Identity management projects run the risk of being setup to fail because their sponsors are trying to boil the ocean.
The problem lies in the scope of a typical IAM project. These projects can often try to do far too much — the sponsor and project manager confuse the bigger, long-term goal with the project objective.
In a IAM strategy report I completed last year, my recommendation to the client was to use a phased delivery approach:
Smaller projects are easier to manage because they have a single focus and set of outputs to produce. Adjustments to follow-on projects can be made based on lessons learned. And with shorter projects, management can more frequently see the real results as each project completes – reports/briefings can be written and financial benefits documented.
Since 2007, I’ve been working as the IAM Program Manager for another client and putting these ideas into practice. This program has been established with eight releases. Each release is a project that runs between six and eight months, depending on the current needs of the business and our sponsor.
The key for keeping these projects short is scope management. The scope is determined a month or so before the project starts. Inevitably, we get a change in scope sometime in the first few months — a new application needs to be integrated, the auditor wants a critical feature added, etc.
As any project manager knows, the triple constraint means that if you increase your scope, you can either extend the project schedule or add resources (and cost) to get the work completed on time. This triple constraint is often addressed by clients by pushing out the schedule. This also increases cost of course, even if the team size stays the same.
My philosophy is a bit different. I look to trade off scope for… scope. If six weeks of extra work are added, I will look to see if six weeks’ worth of scope can be removed. Lower priority work can often be removed from scope and planned for the next project.
In other words, I want to keep the project schedule and costs fairly static so that the team can focus on an end date — and, by extension, new work and a new project after that date. In a longer term program I place a lot of value in delivery. The sponsor needs to see solutions delivered and projects closed. We must be able to report to senior management actual business value and a list of real accomplishments, not just the percent complete on a project.
The end results are higher team movtivation over the long haul — in three years, I have had zero team turnover — and better, more measurable business results.
Mike
I read this article in my feed reader and thought, “This is really good, I should send it to Mike” and then realized you *wrote* it. =)
“We must be able to report to senior management actual business value and a list of real accomplishments, not just the percent complete on a project.”
I totally agree with this; one thing we isolated when about to “refresh” a client project was that we wanted short cycles because we wanted the team to feel they were working towards something, we wanted our client to know where we were at on a regular basis, and most of all we wanted people to know we weren’t scared of being accountable.
Here is an interesting link from PM Hut: http://www.pmhut.com/why-smaller-projects-are-more-successful-than-the-big-ones
Mike