If your project is going south, of course analysis and corrective action are the first things you think about. Some projects can be saved...some can't. But you always want to do whatever you can, right?
Let's consider situations where there was basically a project, but really no project management processes wrapped around it. And now someone has raised the red flag and they realize a project manager – and project management practices – would probably be a good idea. Is it too late? Maybe, but it's probably worth a try. I've been called in for such situations before.
What is the first thing you would do if called into take over a failing “project” that really wasn't defined as a project previously? Can project management fix your project in five easy steps when applied where it did not exist before? Well, yes it can, and I've seen it happen...but there are no guarantees. From my history and perspective, there are five action areas that need to be focused on... and these are: analyze, plan, meet, implement, and execute. Let’s look at each one of these...
Analyze. First, step in and analyze the situation. Gather as much information about the organization, the project, the customer, the team – or who is doing the work, and even the executive management you’re working with. That last one may not be very applicable if you’re not coming in as a consultant…but if you are you need to know whom you’re working with and how much control they are likely going to allow you. In my case it was pretty much total control. If any online project management software schedule exists – which is unlikely – figure out its origin, who’s been trying to manage it, and how badly it has all gone wrong.
Plan. Next, revise or create a draft web-based project management software schedule that you see as a road map to get you from the current mess to a final successful solution. This doesn’t have to be perfect because it will likely get a few revisions, but you need something that seems workable in your hands when you meet with the project customer or customers. Plan how you’re going to re-start each project, how PM will be rolled out, what templates to use for status meetings, status reporting and any planning documents you’re going to need to create like communication plans and risk management plans.
Meet. Step 3 involves actually meeting with the project customers who aren’t happy. Explain how we all got from nowhere to Steps 1, 2 and now 3. Do a somewhat formal presentation of how you’ll be using project management and present them with a nicely detailed project management software schedule to ensure tasks are manage and processed followed from this point forward. The key idea here is to gain or regain customer confidence.
Implement. Send the customer home, educate the organization on the PM processes you’ll be using and the meeting schedules you’ll be implementing. The processes you planned out in Step 2 and showed the customer in Step 3 now need to be rolled out to the organization you’re working for in order to make things happen.
Execute. Finally, put it all into action. Be rigid. The customer needs to see that you are in charge, that what you said in the meeting is really true, and that you are working on change in their best interest. Within two weeks these three customers I was handling were giving the projects and the new processes I implemented the thumbs up and the CIO who brought me in couldn’t have been happier. It wasn’t that hard…it was good PM best practices basically. They just needed someone to take charge so that the rest of the organization could go off and do what they do best…which wasn’t to manage projects.
Summary / call for input
The bottom line is this...if you're called in to “fix” a project the first thing to do is focus on best practices and try to get the engagement back on track...at least to the best of your ability. What would you recommend? Do you agree with this list? What would you add to it? What would you change about it? Please share your thoughts and discuss.