• Authors

  • Calendar of Posts

    October 2011
    M T W T F S S
        Nov »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

Lessons learned about change control

Two weeks ago, I posted that I was planning a lessons learned meeting for the project I’m leading currently. That meeting hasn’t happened, the project has not ended, and we’re all still chugging along. And that in itself represents a lesson learned.

I work in health insurance. We are in a highly regulated environment, and that includes deadlines for when we can and cannot accept applications for new enrollments. 10/1 was one of those deadlines. The project I am working on was to allow us to accept telephonic enrollments through a custom built CRM into our enrollment systems. The project was delayed when the key developer walked off the job after leading us on for over 2 weeks. This pushed us extremely close to the 10/1 deadline. The core work for phase 1 was complete a week before 10/1, and the work for phase 2 is delayed, and may be launched by 11/1, if we’re lucky.

On 9/30, coincidentally a Friday, the department we were partnering with, who uses a different CRM system for a different set of members, suddenly annouces that their CRM is also not set up for the 10/1 deadline. So, they want us to scramble all weekend to add functionality to our system to accommodate their business. Should I mention it’s 2pm? We say, “sure!”

Fast forward two weeks. Our CRM is set up to accept our members and the other department’s members. IT has gotten the file feed to talk to the enrollment system (after 10 days). Then, I get a call from Compliance, howling about the number of applications that were captured and not entered in the 7 day time frame, because IT took 10 days. Next day, quality assurance calls to complain that they have no visibility into the raw data. Then enrollment calls to complain.

What went wrong? No change management plan. We accepted the expansion of work at face value. We had the resources in IT who could crash the development. We had the testers available to work on it. The external vendor was ready. But, we didn’t take the time to see a) what compliance needs surrounded the request, b) what necessary timeframes were, c) what the needs of the end users where, and d) what this cost overrun meant to the overall project.

There is the lesson here: when you read the case studies in the PMI materials, they talk about these added features that get tacked onto projects, and I always assumed they were talking about those out-in-left-field add-ons (the “flip flops with a bottle opener in the heel” type add-ons). But, scope creep can show up at the 11th hour, and looks like you’re just salvaging another department’s work, instead.

Mental note: enforce the change management plan, even if it looks like the worse option!

Advertisements
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: