• Authors

  • Calendar of Posts

    October 2017
    M T W T F S S
    « Dec    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

Lessons Learned about Lessons Learned

I’ve been meaning to write about my lessons learned meeting, and closing my CRM project. I finally hosted my lessons learned meeting 2 weeks ago.

The project proved to be interesting, because the majority of the team only worked on one or two tasks each, so with one exception, I only spoke with the individual members during the weekly status call. That call never went more than 20 minutes of the full hour. I kept my expectations low for the lessons learned meeting.

In preparation, I pulled together a powerpoint to use over web conference (we have multiple offices in 2 time zones). On each slide, I listed one of the project objectives: build CRM tool, set up enrollment telephone line, establish vendor relationship, etc. and under each one, I included space for successes and challenges.

During the meeting, we went through each item, and discussed it. I came into the meeting with pre-conceived notions about what the challenges were, so I could help lead the discussion when people got stuck. I didn’t have to do much leading other than moving on to our next topic. I also didn’t have to moderate interpersonal fights, because the failures in the project were mostly instigated by our developer quitting halfway through development. Forgive me for letting any interpersonal unpleasantness thrive, but if spleens were vented over the developer quitting, I didn’t stop them.

I was happily surprised to learn a couple of challenges from the project that I wasn’t even aware of, mostly around the vendor management. I thought I had my finger on the pulse of a fairly small project, but even then, there are things that surprised me.

I wrapped up the meeting with 5 minutes for each team member to say what they thought they did particularly well. No one said anything. Ahhh…my modest coworkers. So, I, as prepared, pulled out one success that each teammate had had, be it managing a relationship, getting IT to work on development, or providing feedback on documentation, and called each person out by name to compliment them.

After 16 weeks of working on this project with the same 6 people, I finally felt like I had a team on the last day, even if it was only as they were leaving. Now, even if it didn’t feel like a team, do I still get to count all of the hours leading up to that point as PM experience?

Advertisements

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!

%d bloggers like this: