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.

"I like to connect to people in the virtual world, exchanging thoughts and ideas, when in the physical world we might never have the opportunity to cross paths."  - Demi Moore


The quote above says a lot about how we interact with others because of today's technology. With social media allowing us to connect with others regardless of geography we are truly becoming a virtual society. This is also true for our working relationships. The virtual workforce is growing. Currently 25% of the US workforce works remote at least one day a week. Forrester estimates that by 2016 43% of the workforce will be virtual. Virtual teams are not new to project management but they do require special attention to work well.

Last year I moderated a panel on the virtual workforce. One of the questions asked of the panel is how do their organizations address team building of virtual teams? Some of the answers dealt with the use of technology such as video conferencing and chat rooms. Other answers focused on establishing regular meetings. governance, and cadence. However, one specific answer triggered my though process the most. One of the panelists mentioned that personal things such as acknowledging team members birthdays or holidays in different countries was important. This answer got me to realize that although the project team may be virtual it is still a team and the team dynamics needs to be managed.

When managing a virtual team encourage interaction among the team members. When a issue arises think about assigning it to two team members to work jointly. Encourage team members to reach out to each other with questions. Use team meetings to conduct peer reviews. The more the team interacts in this manner the less it seems like a virtual team and the more it functions as a well built team.

This week the tweets looked at at project estimation using the estimating by analogy method.

Estimating by analogy is done by comparing the effort for tasks / deliverables of the current project to past projects with similar traits.

So the first thing you need for estimating by analogy is data from past projects. Actual data is the best if you or others has tracked it. If you don't have a lot of past data you can still do the analogy method by using data from industry sources. Another way to get data for the is to estimate standard elements of the project such as web pages, interfaces etc. to develop base numbers

Once you have your baseline numbers you can now build the first draft estimate. Start by identifying elements to be built for the project. Then for each element identified categorize the complexity as high, the same, or low compared to the base element. Now you need to determine the time or effort change based on the complexity. E.G.the baseline web page takes 16 hrs to develop and unit test.

You can the say that a low complexity web page will take 12 hours and a high complexity will take 24 hours.

Do this for all the elements and then add up the numbers. Add in test, rework, and deployment time. This will give you your first draft estimate. It is best if the team helps with the estimates as the more expertise used the more accurate and complete the estimate will be. If you have multiple people estimating a particular element make sure to use the average numbers and not the best case or smallest. You want the estimates to be reasonable and doable.

"You're Outta Here!" - Managing Conflict on a Project

 I wrote this tip a couplf of years ago. With spring training around the corner I thought this would be a good opportunity to repeat it. Readers of the weekly tips and those people who know me are familiar with my love of baseball. Many however may not be aware that I have been a High School baseball umpire for 18 years. When people I work with discover this they look at me like I'm mad. "So you're telling me that after being yelled at all day as a project manager you willingly go to a ball field and get yelled at by coaches and parents?" The answer is yes, I love it! In baseball the umpire has the final say as he / she can eject a coach or player if their arguments become overzealous. I will admit that early in my umpiring career my arguments with coaches resembled those famous scenes of Leo Durocher kicking chalk on a major league umpire. As time has passed I have learned a lot about handling these situations better to avoid throwing coaches out whenever possible.

 As project managers we don't have the ability to throw somebody out. However, many of the techniques I have learned on the field can be applied to the everyday project world. So when dealing with conflict, keep the following in mind:

1.   Watch your body language. As umpires we are taught to stand erect with our hands at our side when talking to coaches. Crossing your arms, slouching etc will tell the other person you don't want to listen or don't care.

2.   Control your language and tone of your voice. If the other person raises their voice, don't raise yours. That will only escalate the argument. Pick your words carefully when responding.

3.   Acknowledge what the other person says to show you are listening. Look for common ground in the discussion. Make sure the other person has concluded their comments before you explain your position.

4.   If the conflict occurs during a meeting or in a public area, suggest that you meet in private to discuss the issue. If the discussion is heated, suggest meeting later to provide a cooling off period.

Leo Durocher once said, " I've never questioned the integrity of an umpire. Their eyesight , yes." Keep this in mind when dealing with conflict. You and the other person may not agree but you are both trying to accomplish the same thing, a successful project. If you treat others as professionals they will do likewise and you will both solve the issue together.

Project Estimation Techniques - Function Point Analysis

Function point analysis has been around since 1979. It uses 5 types of functions to categorize the software. The 5 functional types of function points are outputs, inquiries, inputs, internal files, and external interfaces.

There are many artcles and books on Function points. Here is a link to a primer bit.ly/43KWT4 by Alvin J. Alexander

To estimate the size of a software project you identify the type and complexity of each FP. Using a FP model an unadjusted score is derived. The UFP is then adjusted using the results of looking at 14 factors
Function points give you the size of the software effort which you can then put a cost to. You also need to add in costs for testing etc.

There are lots of resources for learning about function points. One place to start is the IFPUG, International Function Point User Group. One of the advantages of function point analysis is that fps give you a measurable value that can be used to provide other project metrics. Function points give you a measurable method to determine the size of a software effort. Function points also give you a measure of complexity for each function. This can be used to better plan testing and debugging costs

"When you wish upon a ....."

Requirement. Such a simple word, but one of the major causes of project stress. All projects have requirements. IT projects, houses, ships, marketing campaigns all have functionalrequirements that must be fulfilled. Yet on may projects the requirements are not fully documented or even missed. On other projects there are two many or too complicated requirements for the time, resources, or money available. How does this happen?

 

Project issues due to the requirements arise because important aspects of requirements gathering were not done. These aspects include:

·Understanding the current processes being used

·Making sure that each requirement is understood and agreed to

·Making sure each requirement is testable

·Associating a cost with each requirement

·Having a business owner for each requirement

·Tying each requirement back to a scope statement or goal

·Eliminating "wish list" requirements

On any project, the requirements to be delivered should be only those that are truly needed. There really are no nice to have requirements

Replanning a project that is failing

When a project is in trouble and the delivery date is clearly going to be missed, the project stakeholders immediately start asking for a new date. Usually the team's inclination is to answer the question with a revised date that is derived in one of three ways:

1.A new date two to three months out is selected out of thin air.

2.The team discusses options and selects a new date that they believe is aggressive but doable.

3.The team does a replanning exercise and comes up with a new date based on revised estimates.

All three of these methods can lead to only one final answer, disaster. Option 1 assumes that time was the only factor impacting the project and adding an extra month or two will magically fix the those issues. Option 2 is doomed because the stakeholder's inclination is to believe the team wasn't aggressive enough and will insist that they be more aggressive. Option 3 is always a non-starter because the stakeholders don't trust the new timeframe because the original one was obviously incorrect. In most cases the final result is that the stakeholders select a new date that borders on the realm of science fiction or a least a "B" horror film.

Why does this happen? Business stakeholders and senior executives see project work differently than those of us who deliver the project. The goal of the project is to deliver a result that provides strategic or tactical value to the company. When a project is delayed, the reward the stakeholders were counting on doesn't occur. Their number one driver is to get that reward as soon as possible. By providing a new date for delivery without  providing them additional information on why the new date is necessary, the stakeholders will generally react negatively. To avoid this, the stakeholders need to see three things from the replan:

1.That the project team balanced being aggressive with risks.

2.The project team looked at options for delivery and took into account business needs.

3.The team addressed the underlying issues that caused the project to get into trouble in the first place.

The following is from a set of tweets I sent on basic estimating techniques for projects.

The first estmate done for most projects is a Rough Order of Magnitude (ROM) estimate. This usually is done for approval and budget purposes. ROM estimates are usually done on major scope items and are based on past experience or similar other projects. For an auto insurer a project to add a new product to the billing app may have cost $250K. A new product project est. could start at $250K. Once you have a base ROM you can adjust it based on complexity, estimated delivery date etc

The first detailed estimate for a project is done once the initial requirements have been defined.

One trick I use with estimates is to estimate per requirement. This helps avoid scope creep and gold plating because you can see the cost. When estimating tasks get several people to give you an estimate. Use the average and then round up to even increments such as 8, 12, 16 hrs

Use past project metrics to help with estimates. Actual data from past tasks is one of the best measures of how long a task will take.

Next week I will look into more detailed estimating techniques such as function points.

This past week the tweets looked at the do's and don'ts for planning contigency time into the project. Here they are in case you missed one or two.We'll start with the do's for contigency time. Remember that contigency time is for unexpected events or delays andnot more requirements.

Do add buffer time after milestones. E.G: after requirements are done add 5 days for reviews and approvals to be used if more time is needed

Do look at the critical path schedule and add in additional time where appropriate.

Do use the higher end estimates for building the schedule. Don't use estimates based on using the most experienced people for the task.

Do get estimates for each task from several people and take the average. These estimates tens to be more accurate.

Do make sure that the contigency time is identified in the plan and why it was added.

Don't add extra time to each task. People may not realize that is contingency time and will tend to use it as the scheduled time

Don't assume weekends are contingency time. Weekends should always be treated as time of last resort. It's sort of a security blanket.

Don't use low end estimates for the schedule. Seldom do project's go faster than planned and this could eat into contigency time quickly.

Don't make estimates based on the time the best resources or yourself would take.

 Don't assume that you won't need contigency time. Almost all projects will experience some tasks taking longer that planned.

As Project Managers we often are assigned to complex projects that require substantial time and focus to deliver. This does not leave time for us to attend classes or seminars to develop our skills further. I have been managing projects for over 20 years and the one constant I know is that you have to be willing to learn and expand. The projects of today are not the same as they were 20 years ago. So how do you keep up to date when you have limited time? Here are some things I have found and done myself to keep up to date:

• Webinars: There are numerous webinars that are offered that take an hour or so. In any given week I get emails on 10 or more that deal with projects and PPM. If you can't attend the webinar live you can usually watch a replay later. I often do this at lunch time or in the evening at home.
• Lunch and learns: Many companies have or are wiling to sponsor lunch and learns. In my career I have been able to attend these on topics ranging from communications to conflict resolution. If your company doesn't do this ask your manager if you or they could work with HR or training on arranging one.
• White papers: There are two great opportunities here. One is to read whitepapers on topics of interest to you. Just by browsing the internet you can find 100s of whitepapers. The other opportunity is to author one yourself. I have written several and found that I learned a lot by researching my topic in preparing the white paper.
• Roundtable discussion with your peers: Try having a monthly breakfast or lunch with the other PMs in the organization to share experiences. These can be informal but I would suggest that you pick a topic for each meeting just to give everybody time to think and prepare.
• PMI chapter meetings: Most of these are in the evenings which make them easier to attend. PMI chapters do a great job of getting speakers on a variety of topics.
• Weekend camps or seminars: Just today I signed up for an informal seminar called "Analytics camp". This will have a bunch of people interested who have an interest in analytics etc get together to discuss these issues. Last year I attended "Cloud Camp" and found it very useful.

These are just a few ideas that I have used over the last several years to further develop my skills. Most of these are free or very low cost and can fit into a busy work and family schedule.

"Never for me the lowered banner, never the last endeavor"  - Sir Ernest Shackleton

In 1914 Sir Ernest Shackleton led an expedition to Antarctica that was intended to cross the entire continent through the South Pole. The pole itself had been conquered a few yeas earlier by Amundsen and his team. Shackleton being one of the great polar explorers hoped to increase the knowledge of the area. Unfortunately their ship, the Endurance became ice bound and eventually  crushed resulting in one of the greatest survival stories of all time. Ultimately, all hands were rescued after over 18 months lost on the ice. Many attribute this feat to Shackleton's leadership skills. He was able to manage a team of experts, motivate the crew, maintain discipline, communicate orders, and make critical decisions when needed so that every man would survive a terrible ordeal.

 For the past few weeks I have been discussing project leadership as the next progression of project management. The leadership skills that Shackleton used almost 100 years ago are the very same that project managers need today.

·         Ability to communicate not only status but direction to the team.

·         Discipline in making sure that tasks are assigned and executed per the schedule.
·         Motivation. Many project teams consist of people who do not directly report to the PM and / or work remotely. The PM must be able to motivate the team to contribute to the overall success of the project.
·         Manage a team of experts. PMs must be able to manage a group of experts who have different project roles and different skills.
·         Ability to get obtain input and make critical decisions in a timely manner.

 Today's projects require project managers to be true leaders that manage projects that help move their organizations forward. Take a lesson from Sir Ernest and take the mantle of leadership to heart.

This week's tweets continued looking at project initiation tasks and how to start a project to ensure success. Here are the ten tips:

• The project initiation phase can vary depending on the SDLC to be employed. Thus one of the first tasks should be to confirm the SDLC
• When confirming the SDLC to be used determine if the team will need training or extra support particularly if the SDLC is new.
• As part of project initiation the various plans you use to manage the project should be created.
• The first plan should be the project management plan. This defines how the project is executed, monitored, and controlled.
• The project management plan also helps to define how the other plans, communication, risk management, resource management etc. are created
• During initiation you should start determining how requirements will be gathered and documented. This also depends on the SDLC
• Initiation is a good time to schedule the requirements sessions or interviews. Getting those on people's calendars early is important.
• If the organization has a PMO, meet with them early during initiation to confirm what project management standards apply to the project.
• During initiation get the budget tracking mechanism's in place. If you wait it becomes harder to track expenses correctly.
• During initiation you should create the communications, resource, risk, and budget management plans. Check with the PMO for templates etc.

"Some key questions need to be asked continually throughout a project"

Many times we ask questions early in the project concerning both business and technical issues. If an application is being updated we might ask; "Do we need to load test the application?". If the answer is no the first time can we really assume that it will be no 3 months later? Questions like these need to be asked again because things may change on the project. A change request might occur that will increase the size of a transaction. A new server may be added to balance the load. Not asking the question again may lead to a surprise the night before implementation when you find out that the network team has concerns. Keep asking those questions!

This week my tweets @tprusk1 looked at two important project initiation steps, the kickoff meeting and the initial sponsor meeting. Here is a compilation of all of them in case you missed any.

The initial project sponsor meeting should be the first priority. This should be a one on one meeting between the PM and the sponsor. The number one goal of the sponsor meeting is to understand the sponsors expectations and success factors for the project. Additional topics for the sponsor mtg are: escalation method, freq of mtgs, participation in kickoff and other mtgs & Sponsor's key contact.

If planned well the initial sponsor meeting should take 30 minutes. Future meetings can be 15 - 30 min depending on subject discussed.

The project kick off meeting is your first opportunity to set the right tone and tenor for the project. Do not underestimate its importance. Although it is important to have the kickoff meeting early in the project don't rush it if you are not ready.The project kickoff meeting should be a formal meeting with an agenda and follow ups assigned. Send the agenda out in advance. The kickoff meeting is not the same as a regular status meeting so having a larger audience including business owners, SMEs, managers is ok. Have the sponsor attend and talk about the business value of the project. This sets a great target for the team.

Next week we will discuss additional project initiation tasks. 

"Stick with the basics."

Paul Richards, The Baltimore Orioles Manager from 1955 to 1961 once said about baseball:

"It's just throwing and catching and hitting and running. What's simpler than that?"

Baseball can be complex but the first thing that every player learns is to practice the basics. Projects too can be hard to manage particularly if they are large and complex. You can make your life easier by paying special attention to the basics such as :

·Good risk management

·Keep the stakeholders informed and engaged

·Regular team and stakeholder meetings

·Scope management

·Contingency planning

By paying attention to the basics, you will be in better position to deal with new issues and problems as they arise.

A new year and new projects. Here are things you can do to start a new project on the right track.

#1 - Understand the expectations for the project. This is not just scope but what the sponsor & users really expect.

#2  - Validate the scope. Charters are written to get projects approved. Verify that each scope item is still valid.

#3 - Verify the project is approved to start. This sounds silly but selection and approval to start are different.

#4 - Make sure the budget has been authorized and realeased for the project to start spending.

#5 - Create a two week inititiation plan that includes the kick off mtg, sponsor mtg etc. This could be a punch list

#6 - Identify and begin to fill key project roles. Tech lead, SMEs, QA lead, BA should be among first roles filled.

#7 - Meet with the project sponsor to discuss the project and his / her role throughout the project.

#8 - Do a sanity check on the technology and methodology to be used. Does it make sense? Is it new?

#9 - Identify major dependencies including other projects, technology purchases, and vendor delivery.

#10 - Plan the kick off meeting. Don't just hold the meeting. Have an agenda, key talking points, sponsor statement ready

These 10 steps are in addition to the normal initiation tasks. These are important because they address areas that often negatively impact the project.