Starting this week and continuing into next week I will share with you the top 20 things I have learned about being a project manager. Here are Nos. 20 - 11;

#20 - It's not your project. Yes we want to take ownership and accountability but it is the company's project and you need to act that way.

#19 - The customer is not always right. The stakeholders may want a lot but your job is to deliver what they need, not what they want.

#18 - Project teams are made up of experts so you don't have to be. Leverage each team members expertise and knoweldge during the project.

#17 - Being under budget significantly is just as bad as being overbudget. Over estimating may keep other projects from getting funded.

#16 - Weekends are not contigency time. Always build contigency into the schedule. Weekends are for emergency work only.

#15 - There is no such thing as a "nice to have" requirement. A requirement is either needed or not needed.

#14 - A project manager's job is not done when the project is delivered. The close out phase is just as important as any other phase.

#13 - Status reports are less about status and more about getting support and action from the project stakeholders.

#12 - There is a point on a project where bringing in additional resources will have little positive impact and could have a negative impact

#11 - Per my favorite PM, Risks are issues waiting to happen. Address risks early and continually to prevent them from becoming issues.

Dealing with conflict is a regular part of managing a project. This week's tweets provided some tips on handling conflict.

Conflict on a project can occur in many ways. Between you and the team, between team members, between business owners etc.

• The first step in dealing with conflict is to understand where it is coming from. Is it from lack of communications, stress, project issues?
• The next step is to engage the parties involved in the conflict. Get both parties to define what their issue sand concerns are.
• Avoid dealing with conflicts in a group setting. Get the parties together privately to discuss the conflict and try to resolve it.
• If the conflict is between two other parties be dispationate in dealing with them. Their emotions are probably high so you need to be low.
• If you are one of the paries in the conflict check your emotions at the door. Be factual and concise in the discussions.
• When discussing conflict stay away from adjectives as much as possible. Phrases such as royally screwed up can inflame emotions
• Using a visual medium such as flip charts or white boards to describe both sides of the issues may help all parties see resolutions easier.
• Don't think you have to solve all of the conflict at once. Sometimes allowing a day or so between meetings may help.
• Do not use emails, chat sessions, or text messages to solve conflict. Meet in person or use the phone or even video conferencing.

Next week the tweets will discuss scope management on projects. Enjoy the weekend!

This past week the tweets looked at how to handle taking over a project that is at high risk of failing or has already failed. The first thing to realize when taking over a failing project is that the rules for managing a project from the start don't apply.Another point on taking over a failing project is that you do not have a lot of time to get a handle on it. Management wants quick action.

• The first step is to determine exactly what the state of the project is. This is more than status. You need to know every detail.
• Start by getting the team together to explain how you're going to start getting the project realigned and what help you need from them
• Next, schedule interviews with key team members and stakeholders to assess where the project is and what the major issues have been.
• As you interview people you want to listen for clues such as scope changes, stakeholder involevment, technical issues etc.
• As you interview people take good notes and keep a list of issues and risks.
• You also want to review all of the project artifacts including status reports, risk logs, plans, resources, requirements docs, charters etc.
• After the interviews and doc reviews you want to take the notes and lists you created to perform an analysis of the data.
• For each issue or risk give it a severity score of 1 low - 5 high and an impact score of 1 - 5. Multiply the 2 scores for a composite score.

Part 2 of this series starts tomorrow at @tprusk1. I'll post the complete series at the end of the week.

This week I had several meetings with clients to review their projects and discuss next steps. What was most interesting about this week is that all of the clients not only like having solid project plans but that they want to help create and manage them. Teaming up with your customers, either internal or external to define and manage the plan is a great way to get buy in and support for the project. Keep this in mind when you start your next project.

Sometime in your PM career you will be asked to take over a project already underway. This week's tweets looked at how to do this effectively.

There are many reasons why a PM is being replaced. Be sure you know why for the project you are taking on to understand what you are getting.

• One of the first tasks for taking over a project is to introduce yourself to the team. Do this both individually and in a team meeting.
• The next task is to conduct an assessment of the project. This is important regardless of the status of the project.
• The project assessment has 2 purposes. 1) confirms or disporoves stated status 2) Gives you a detailed view of the project.
• The project assessment includes a review of the project plan, schedule, risks, issues, budget, and resource plan.
• If the assessment indicates the project status is not green you need to create a plan to remediate the issues. Leverage the team on this.
• As soon as possible after you take over the project, schedule a meeting with the sponsor and business owner to review their expectations.
• If possible meet with the previous project manager to discuss the project and review project artifacts.
• If the previous project manager is staying with the project for a transition period work with him/her and create a formal transition plan.
• If the previous project manager is staying with the project for a transition period work with him/her and create a formal transition plan.

Next week we will take the scenario of taking over an in-flight project to the extreme, taking over a project at high risk to fai

Monday Monday

The start of a new week is a perfect time to review last week's accomplishments and challenges for the project. Keep a log of these to help in preparing status reports and other project updates.

Terry (May 2012)

The following is a compilation of this past week's tweets (@tprusk1) with thoughts on rebaselining a project.

.

Remember that the baseline plan is what is expected to happen. Once the project is underway there will be variances to the plan. Minor variances do not require the plan itself to change. Major variances however may require that the plan be rebaselined.

Projects should be rebaselined when the plan has been so impacted that tracking actuals against the original plan becomes meaningless. Sometimes projects need to be rebaselined because the approach must be changed. If you switch from a COTS to a custom solutiion for example.

Before rebaselining the project make sure you know exactly where the project stands. What tasks are done, still underway, or yet to do. When preparing the new baseline make sure to reevaluate the WBS and add or remove tasks to reflect the new plan and schedule. When projects are behind the tendency is to rush the replan. You want to do it quickly but also need to do it right. 1 replan is bad enough.

Make sure to save the original plan so that you can compare it to the replan as part of lessons learned. This can be useful for future work as it gives you a view into why the plan had to be changed.