• Authors

  • Calendar of Posts

    June 2017
    M T W T F S S
    « Dec    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 7 other followers

Project Management Best Practices for Production?

So, as I’ve described before, I work in a data processing unit for a health insurance company. But, more specifically, I work on the support team for the data processing group. The support team is made up of a manager, a team of a half-dozen business analysts, led by a senior business analyst, and two project manager. The BAs are responsible for maintaining various aspects of the production work (department communication, file processing, etc), as well as providing support on special initiatives. The implementation of the special initiatives are led by one of the two project managers (of which I am one).

I’ve been in discussions with my manager about how we can streamline work that is being done. One area we are looking at is how can we better utilize Project Management best practices in managing the work that is being done by the business analysts. While much of the work they do is routine, and therefore outside of the strict definition of a project, there are enough changes on a daily basis, and new tasks, that some features of project management would still apply.

If someone were to ask you what is the most valuable best practices from Project Management methodology (PMBOK, PRINCE II, etc), what would it be? Would it be the emphasis on planning? The change management? The need to include Monitoring and Controlling in every project? The invective to celebrate every project at it’s completion with a party?

Risk Management presentation

About 2 weeks ago, I attended a lunch put on by the Baltimore chapter of PMI. They run these lunch sessions on a monthly basis. They have a catered business lunch (hoo boy! Wraps!) and have a speaker from the chapter present on a topic.

The December topic was ‘Never cancel a risk meeting when the building is burning’, given by Chris Schaefer, PMP. I think my first question for the session, which of course I didn’t actually ask, was ‘what the hell’s a risk meeting?’. What I was able to glean from the presentation was essentially, ‘I’m probably running my project team meetings wrong.’ When I run a project meeting, I do what everyone does, or at least everyone inexperienced in project management. I focus on status. Where are we today?

What is a risk meeting? ‘Where will we be tomorrow, and what are the road blocks to getting there?’ If I can start to move in that direction, I can start to be more proactive about addressing risks before they blow up.

One area of general risk is the issue of expectation management. I wanted to share this image, since it captures expectation management pretty well (though, allegedly, it’s become a cliche now).

A couple of the other take aways:

  • Approximately 71% of projects fail. Obviously risk management is not an important enough focus on these projects.
    • The Standish Group published the CHAOS report in 2004, and republished it in 2009, looking at project success standards (it seems there are tons of disputes to the CHAOS report finding, so that may be a different blog post) (Also, sadly, the report is not available in the PMI online resource library. Anyone have a copy of it you wouldn’t mind lending me??).
  • One of the recommendations for taking over a project that is already in the red is to have a clear game plan. Mr. Shaefer’s suggestion:
    • Engineer Success
    • Bargain Fairly for time, Scope, and Resources
    • Never Cancel a Risk Meeting
    • Everyone is your customer (and he mean’s EVERYONE!)
    • No surprises- communicate clearly, effectively and often
    • It’s not about you: Seek first to understand, then be understood.
    • Project Management is the Service Business
    • Event+Response= Outcome
    • The world is your oyster
(notes from “Never Cancel a Risk Meeting, Chris Schaefer, PMP. Held In Columbia, MD, 12/5/12).

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?

Lessons learned notes

Lessons learned are a collection of things that went right, things that went wrong, and things that should be done differently. They can be collected at the end of each phase, and at the end of the project. (Mulcahy 32)

Lessons learned should include technical aspects of the project, tying them to reality. They should look at project management, including planning and risk prevention. And they should look at management, including communication. (Mulcahy 32) The documentation looks at the causes of the issues, the reasoning behind the corrective action (PMBOK 261).

Lessons learned should be shared throughout the organization, probably through a PMO, or whatever the existing structure for sharing this information is.

During the initiating phase, lessons learned from other projects should be reviewed as part of identifying risks. They should be certified during the Closing phase of the project, and stored.

I had identified back a few weeks ago that I would be conducting a lessons learned exercise for a CRM project I was working on. That exercise is finally scheduled for next week.  More to come.

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!

Project Lessons Learned Meeting

I guess I’m starting this blog at the end. I’ve been working on a small-scale project for the past 4.5 months to set up a new telephonic sales vendor for our department. The project has included script development, contracting the vendor (Protocol Global Services), coordinating the transfer of existing phone lines, and working with our IT department to create the data transfer system to manage the data capture from the vendor to our enrollment department.

The project officially went live Monday a week ago. We’ve been selling 20 plans per day, which we expect to explode in the next 3 weeks. We were officially 3 weeks late launching. Our web developer quit after the data transfer system was one week past due. We discovered that a second phone line existed after we had gone live.

Tomorrow, during my weekly implementation team call, I’m hosting a lessons learned meeting. This is actually the first time I’ve led a project where I’ve included a lessons learned meeting. I had to do some research on what to include.

I’ve had one article in reserve for this meeting, that helped guide me in creating the agenda. While this article was written for design firms, and I definitely do not work in a design firm, I thought the meeting structure idea makes a lot of sense. The second article focuses a lot more on being on the wrong side of a post-mortem meeting.

Here is the agenda I drafted. We’ll see how the meeting goes tomorrow.

Agenda:

  • Ground rules
  • Overview of Project
    • Review In-scope tasks
    • Review time frames/project constraints
    • Review expected roles
    • Execution- some questions for consideration:
      • Did we fulfill the in-scope tasks?
      • Was the project scope an accurate reflection of the work that was conducted?
        • If not, what additional work was completed?
  • Were there technical challenges?
    • What could we have done to expect them and prepare?
  • Did the team have the complete knowledge to complete the project?
    • Which areas did we not have adequate expert coverage to tackle?
  • Did the team scramble to fix issues that arose without triaging the problem? Did we do unnecessary work?
  • Were there areas that could have benefited from more communication?
  • Solve for problems
    • For the most glaring issues identified, if any, be prepared to brainstorm a couple of solutions to try the next time
    • Personal successes
      • Take a minute before the meeting to think if there are any areas that you think you handled particularly well.
%d bloggers like this: