This week we will look at creating project management tool and artifact templates for the organization:

In many organizations the project management templates are created and maintained by the PMO or the project management team. Regardless of which group owns this task there are some very important things to consider when creating the templates.

• The first thing is decide the artifacts/tools needed for small, medium, and large projects. Start by defining small, med, and large projects
• The next task is to design a generic template to define the look and feel of all the artifacts. Consistency is very important in these.
• When creating the templates for the project management artifacts use standard names such as project charter, risk matrix. Avoid "cute" names
• As you create the templates look at other templates available on the internet or other sources for ideas or even starter templates.
• Design your templates to be minimalistic. You don't need a 10 page risk management plan. Concise and accurate documents are more useful.
• Always use full words in the templates. Avoid abbreviations and acronyms so that documents created with the templates are easily understood.
• Use revision numbers and dates for the templates so you can easily issue updates and so that others know which versions are the current ones

  When creating templates make it easy to add or remove unneeded sections to account for project differences and project size.

Next week it is time for my annual rant on project status reports. Stay tuned!

This week the tweets covered the top tools and artifacts I like to use when managing a project. Next week will be part two of this series.

Tool # 1- Status Reports. Not just a report but also a call to action for executives and sponsors. Brings focus to milestones, budget, risks. Tip – There should be one and only one template for status reports used in the organization! Consistency is important for stakeholders.

Tool #2 - Risk Log and Management Plan Used to identify risks before they become issues and define strategies to deal with them. Tip - The Risk Log should be reviewed regularly and updated. I like to assign this to another team member to bring added focus to it.

Tool #3 - RequirementsTraceability Matrix. Provides a great way to ensure all requirements are covered throughout the project. Tip - The requirements traceability matrix should be organized by major functional area. Also include technical, security, and usability requirements.

Tool #4 - Scope Statements. Usually found in the charter. They serve as the anchor for the projects deliverables. Tip - I usually will copy the scope statements from the charter and put them on a seperate document to make it easier to socialize them to the team, stakeholders, and the organization.

Tool #5 - The Project Plan. Details how the project will be executed and managed. Contains the sub plans such as communication and QA plans. Tip - The project plan should only have the sub plans needed. Smaller projects do not need all of the sub plans that larger ones do.

So we are into the second half of the year. Q 3 is when a lot of project work is delivered in the IT world. Now is a good time to review the project plan and schedule for projects that have a Q 3 delivery date. Here are some key things to look for:

• Ensure that the critical path has not changed and that you are tracking to the schedule for the critical path tasks. If you are behind schedule prepare the remediation plan immediately.
• Make sure you have up to date vacation schedules from the team. The next two months are heavy vacation times.
• Review the requirements tracebility matrix to ensure all requirements are accounted for.
• Review the risk log and update it. Makes sure that risks that have been triggered are being addressed.
• Get the project team together and do a 90 day walkthrough to make sure all tasks have been accounted for.
• Check with the business areas to make sure they are well into their planning for the implementation.

Here is the second part from my series of tweets on the top 20 things I have learned as a project manager. Here are numbers 10 - 1.

#10 - When a project starts getting behind schedule you need to address it right away as the schedule slippage can snowball very quickly.

#9 - Escalation is not a four letter word. Escalating issues is part of the PM's job and if done well will help keep the project on track.

#8 - The most important skill to develop as a PM is communication. The better you can communicate to others the better you can manage.

#7 - Estimating tasks as a team will usually be more accurate than having individuals estimate tasks by themselves.

#6 - Trust but validate is your friend. Check with the team on the status of tasks ahead of their due date. Make sure they are not stuck

#5 - The only real failure is not learning. When things go awry document them for future reference.

#4 - Never hide issues. Be open and honest. It is better to say something is behind schedule than to tell them that the project has failed.

# 3 - Keep project documentation up to date, concise, and well written. Poorly written docs will cause unneeded rework and confusion.

# 2 - Do not try to create the prfect plan or schedule. There will be issues and changes. Plan ahead and be prepared.

# 1 - If you worry about getting fired you probably will be. Focus on the work, be confident and be positive.

 

 

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.