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.

 

 

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.

This week the tweets looked at using a baseline plan and the tracking actuals against that plan. The following is a compliation of the week's series.

A baseline project plan is the estimated schedule, costs, tasks, and deliverables for a project. In essence it is what is expected to happen. The baseline plan should be approved by management and thus sets the schedule, cost, and deliverable goals for the project. Remember that the baseline plan is still an estimate and there will be changes to the scope, schedule, tasks, and budget along the way.

So why do a baseline plan? The baseline sets the stage to start the project and allows others to plan to be ready to support the project. As the project progresses you will use the baseline plan in two ways. 1) To manage the project 2) To track actual against the project.

Although the project plan itself will change throughout the project the baseline itself should not be altered unless there is a major change. What you want to do with the baseline is for each task capture actual start and finish dates as well as actual work. The actual numbers will help spot potential areas where the project can be at risk pof schedule or cost overruns. Actual project data is very useful for future projects, Having data from past projects helps provide future projects with better estimates.

Tracking actual data will also help you better manage resources and be able to make adjustments to assignments as needed.

Next week we will continue looking at baseline plans and how to deal with scope and major schedule changes plus when to rebaseline a plan. You can follow the weets themselves at @tprusk1.

"Superhuman effort isn't worth a damn unless it achieves results." - Sir Ernest Shackleton

Recently I wrote about project leadership vs. project management and how our role as project managers also puts us in a leadership role in many organizations. I was sent a job description for a PM that indicated that companies are seeing PMs as leaders as well as managers. The following is a portion of that job description.

·    Project team leadership skills including:

·    Estimating and setting project goals and milestones
·    Building team(s), motivating and leading team members to reach project milestones
·    Working closely with customers and vendors on project teams.
·    Keeping all team members involved, productive and challenged.
·    Sharing project information freely and on a timely basis
·    Using other resources and teams in a productive manner
·    Communicating and working with other Information Technology departments
·    Coaching and mentoring staff.

What is important to note here is that as PMs we need to understand that our role is to be a leader and a project manager. As a leader we set the tone for the team on how to get the project done. As a manager we coordinate the tasks and resources to execute the project.

Seems like a big task but as Shackleton alluded to if we achieve the results then the effort is worth it.

When putting together a project plan make sure to add in time for revieiwng the plan with others. This step is very important in communicating and acheiving buy in for the plan. Good project planning is a team excercise.

.

The following is a compilation of tweets on people change management during a project

The main reasons company take on projects is to address a business issue or problem. This introduces change to the organization. Change within an organization must be managed very carefull. Otherwise the change may have a negative impact on the organization.

• The first step in people change management is to identify those who will be impacted by the change.
• When identifying those who will be impacted make sure to look at both internal and external groups
• After identifying those impacted by the change the next step is to measure or quantify the level of the impact.
• One way to help asses the impact is to document the current process and map it against the proposed process to identify the gaps.
• Once the gaps have been identified you can now develop a cvhange management plan to address them.
• The change management plan should include items such as training, communication, and socialization around the changes.
• The change management plan should also include metrics for measuring usage. Metrics can include # transactions/hr, accuracy, or log in time.
• Also consider using follow up surveys or interviews to get feedback from the users. This can be helpful for future updates to the app.

Keep in mind when building the change management plan that yours is just one project and there may be other projects in the organization that impact the same group of people. If possible coordinate your activities with the other projects. One example of this is training. If your project requires 2 hours of training in a class room and another project requires two hours of training can the two classes be held on the same morning to minimize taking the users away from their work place?

This weeks tweets looked at tracking actuals, revising estimates during the project, and using estimates to complete to measure progress. There are 3 great reasons for tracking actual hours and costs on a project.
#1 is that actuals help track overall progress against the plan
#2 reason to track actuals is that they give you information you can use to make adjustments to the plan during the project.
#3 reason to track actuals is they give you data to plan future projects. The more actuals you have the better future estimates can be.

If you use a project scheduling tool such as MS Project or Workbench make sure to baseline the plan before you start entering actual hours. As you track and record actual work hours against tasks you can start to see trends and get info that can be used to revise the plan. Actual data lets you revise estimates for future tasks.E.G. If the 1st 3 web pages took 10% longer you can update the other page estimates.

Revising estimates is not a bad thing. Having this data can help you make decisions so the final delivery date can still be met. Another metric that can help you manage the plan is estimates to complete or ETCs. ETCs are the hours estimated to complete a started task.

Every week have resources with open tasks give you their ETC. This does 2 things. 1) It lets you determine if the task will be done on time. The second use of ETCs is to give you a heads up that a task needs more time. Getting this data early lets you make proactive adjustments. For example if a task is taking twice as long you can look to see if it is too complex or if you need to get other resources to do other tasks to keep the schedule on track.

This tip is a compilation of tweets that look at how to fine tune project estimates and turn them into a work plan.

After the first draft estimate is done, take a few days to have the team, stakeholders, IT, and business resources review and comment. Once the team and others have provided comments go ahead and make adjustments to the estimates. Make sure all deliverables have estimates.

After making adjustments now look at the estimate versus the budget. You wait till now to avoid building the estimate to fit the budget. If the estimate is within 10% of the budget, high or low, you are probably ok to create the workplan. Double check with mgmt to make sure.

The first step to build the workplan is to group the tasks you estimated into logical groupings, Start at a high level such as coding. The next step is to further group the tasks into functional or like groups. E.G.you can group web screen coding or new policy tasks. The next step is to identify the dependencies between tasks.

Once the dependencies are listed you can identify the critical path. This will be those tasks that are dependent that take the most time. The reason for the critical path is the CP will tell you if the project can meet the expected delivery date or to set a delivery date. If the CP date is ok then you can complete the plan and begin to communicate it to the team and stakeholders.