Change Process

Failing at Change Management: A Good Thing

Failing at Change Management: A Good Thing

In this space, I have counted and analyzed the Lessons Learned of student groups in my Project Management courses at the University of Arizona.  Now I want to focus on one of my key takeaways that has come from years of experience: never underestimate the importance of Change Management, especially when you want to mature the project management practices of your organization.

My first assignment as a Project Manager was on a small effort of about $20M with approximately 15 people.  When I joined, the team had a nominal interest in planning, and one of my first tasks was to gather everyone together to create a new schedule.  The old one did not contain the current scope, had unstatused tasks with start and end dates in the past, and poor planning mechanics.  In short, it was not a predictive or accurate project management tool.  After I arrived, we spent several months stripping the old schedule to its bones and rebuilding it from the Work Breakdown Structure up.  In the end, we had an excellent simulation of our project from that point forward.

I flatter myself that I was persuasive in my arguments about the importance of a good schedule, but I am sure some went along with it to make points with the new boss.  My focus was on learning everything I could about my new project, but also in convincing my team that the schedule was a worthwhile investment of time.  Without it, I argued, we were walking around with blindfolds, slow in our progress, and prone to wrong turns on our way to reach the final destination.

But I wanted to take this process a step further.  My previous assignment had been on a much larger project with project management discipline, earned value requirements, and a deep, cultural belief in the value of planning, metrics, and analysis as a few of the bases of success.  A team at least ten times the size of my current one had implemented all of those things like a well-oiled machine.  Surely a group of 15 could do the same.  How hard could it be?

Everyone sighed with relief when the schedule was baselined – now we can go engineer! — but that reaction soon turned sour when I discussed next steps.  I talked about how we were going to implement full earned value, status every two weeks, and hold biweekly risk reviews, for a start.

Of course, you can imagine their reaction.

Unfortunately, I did a poor job of doing that before I briefed them.

I failed to account for the fact that this team was just getting used to a schedule in the first place.  (Many had to learn Microsoft Project and other bolt-on software packages we used at the organization.)  None of them had ever worked on an earned value project, much less been trained on the terminology or concepts.  I failed to enlist any allies, so that I stood alone in the face of resistance.  I failed to come up with a deployment strategy that involved training.  I failed on many fronts that day, but that turned out to be a very good thing, because I’ve never forgotten the lesson.

After much thought and discussions with informal team leaders, I devised an implementation plan that was backed by all.  Initially, we did not status online and it was a very manual process.  But I did receive monthly performance reports.  Initially, the team did not analyze variances, think about root cause analyses, or write recovery plans.  But those came after about six months, after they were comfortable with the systems, statusing, integrated change control, and the interpretation of performance metrics.  I eventually implemented most of my original vision, but it took longer than I had intended.  Sure, I could have been authoritarian and insisted upon my way from the beginning, but that would have resulted in compliance at best, resentment at worst.  In the end, my team understood the importance of the schedule, and how metrics and analysis could help them manage their work.

When I left that program, one of the informal leaders on the team said I was the best project manager he ever had.  I certainly didn’t start out that way, but one of the key things I learned was that change management is a process – not a switch.

In my next post, I’ll continue the story of this project, its “local” successes, and how those inspired change in the larger program.

Share your change management stories.  I’d love to hear your insights.

Tagged with:
Posted in Blog Entry
Ask Eve: Submit Your Question News & events

News & Events

The Risky Business of Small Projects (Part Three)

Risk Knowledge Area

In this space, I have discussed some tools for Risk Management on a

The Risky Business of Small Projects (Part Two)

Risk Knowledge Area

One of the great things about my Project Management course at the University

The Risky Business of Projects

Risk Knowledge Area

I teach Project Management at the University of Arizona, and my graduate students