Early in my PM career if I was asked whether I had a failed project I would proudly say “No!”. When questioned I would tell them how I equated project success to no surprises for my customer. Then I would go on to talk about the good documentation I created, and the places where I got the customer to sign off. It wasn’t unusual for me to have 30-40 change requests on larger projects (some approved and some not). To me the important thing was I eliminated surprises regardless of the impact it was having on value.
I will give credit to Tom & Mary Poppendieck for lighting a spark in me. Our customers don’t want to work with IT! Although my actions certainly meant the paper trail proved I was on time, scope and budget I’m no longer convinced I always had happy customers! In fact I’m sure in some cases I was driving them nuts with bureaucracy!
Just to be clear I am not saying we should eliminate the act of managing change. When something key has changed on a project it is the responsibility of the PM to ensure the right discussions happen, and the right people make the decisions. Without the effective use of change management your projects would be doomed to failure! The change management process is the tool you can use to help facilitate the actions you take. Just don’t cross the line and view the change management process as a means to CYA. Despite the benefits of managing change it doesn’t change the fact this amounts to wasted money in management activities better spent elsewhere!
Where I find most PMs fall short is in what happens after the change request is signed off (I used to miss this as well). In addition to all the normal communication activities, and setting action plans in motion you also need to do a root cause analysis. You need to find the situation which required this change request in the first place. Then more importantly work with your team and PMO to improve eliminating the underlying cause for the next time.
Here’s an example:
It used to be I would create fairly detailed scope statements. I would strive to list out each form, report, etc we would touch. When the customer came to learn something later we would go through the change management process (ich … painful!).
On one smaller project I was leading more recently I reduced the scope statement to one sentence! This one line focused on the business functionality our customer was looking for, rather than detailing how we would deliver it. Throughout the project the customer changed numerous details regarding the functionality they needed. But not one of these changes required us to create a change request! This does mean you have to manage to time & cost, but that’s what should be happening anyways! (future blog topic)
The outcome of this project was an overwhelming success! Everyone was nervous going in, but quickly saw the benefit! We created an environment which truly embraced change rather than tried to control it.
For those wondering whether I’d admit to project failures during an interview now. My views have changed considerably since those early days. Lets just say if I’m interviewing for an experience PM and they tell me they’ve never had a failed project … I cut the interview short. Either you’re lying to me, or you will lack the type of PM experience that makes for experienced PMs. Failed or troubled projects tend to make for the best education for PMs.
