Many PMs like myself have other responsibilitiesthat put us on the road. This week I have some tips for managing projects on the run

#1 - When on the road try to schedule meetings so that you can have an hour at the ebginning or end of the day to check in

#2 - Take advantage of time differences.I live in eastern time so when in the midwest I can call people at 7 AM which is 8 AM back home

#3 - Before leaving for a trip assign project team members to cover various items for you in advance. This helps keep things moving forward

#4 - Set expectations for when the team should handle issues and when they must get a hold of you.

#5 - Don't cancel team or status meetings while you are gone. If you can't run the meeting remotely assign someone to conduct the meeting.

#6 - Let the team know how often you will be able to check voice mail and email so they have an idea of how quickly you can respond

#7 - Smart phones are a great way to get emails and documents on the run. Adding apps such as Docs to Go and evernote can really help.

#8 - Encourage the team to text you if necessary. You can often glance at a text in a meeting which lets you know if you need to call back

#9 - Prepare status reports and update the project plan before you leave. This will make sure the team has the latest ones.

#10 - Use dropbox or a memory stick to keep copies of the project plan and other artifacts with you so you can refer to them on the road

The following is my series of tweets on writing effective status reports in 30 minutes or less >

When writing a status report, decide when to publish it and be consistent. I like to send my reports out 24 hrs before my team meetings. The frst thing to remember about writing a good status report is who is the audience and what do they need to know. In other words, The real trick for writing a status report is to remember why you are writing it. The second thing to remember about status reports is that a good report is more than information, it can help you manage the project.

A status report should show: Where the project is at. Where it is headed. How much money is left and what people need to worry about. Start the status report with a 2 - 3 sentence summary of the current state of the project. Include major news such as completing a milestone. The next part of the report show the status of the project for schedule, budget, quality, and scope. Use stoplight colors if you want. If schedule, budget, quality, or scope are tracking yellow or red add a brief note of why and what action is needed or being taken.

The next section of the report should list milestones or deliverables that have been met. Also list any that are late. The next section should show upcoming milestones or deliverables and whether they will meet the schedule. The last section of the report should include things people need to worry about. New major issues or risks liekly to be triggered.

Always keep the status report concise. One page is best if possible. Also use clear language and avoid hyperbole. Finally the most important part of writing a status report is to be honest with yourself. If the project is.

Next week I will look at how the status report can help you manage the project

Yes it is time for my annual rant on status reports. I actually rant on these daily but only write about it once a year!

First off I do believe status reports are important to a project and its stakeholders. My concern is that they are always misused. Project status reports should be about: where the project is, where it is going, what we need to worry about, & is it on schedule and budget.

• My # 1 problem with status reports is the status itself. Many companies use stop light status but invariably don't define what they mean.
• The other problem with stop light status is that we want to make up colors to avoid being red or yellow. Grellow, really.
• My next big problem with status reports is that we want to include too much information. Do we really need to list all of the milestones?
• We also want to list every accomplishment for the previous week. Is this useful? Probably not.
• Another concern is that stakeholders want different views of the same data so we end up with a weekly, monthly, and executive reports. Yuck!
• Many PMOs have templates for status reports that include risks and issues. Don't we have logs for those?
• Another issue is that all too often PMs copy the status report from week to week and ony change a few items to save time.
• Which leads me to - Status reports should never take more than 30 minutes to write. We have projects to run, right?

Next week I will tweet about how to write effective status reports in 30 minutes or less

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.