Use These Six Tips to Feel Confident.as a Presenter

/in /by

Are You a Nervous Presenter?
Use These Six Tips to Feel Confident.

It is said that all people fear two things – death and public speaking. Having to present in front of others can be nerve-racking – even for experienced speakers. You are not going to find the answers in your project Communications Plan. Here are some tips to help you feel more confident.

1. Prepare

Nothing gives you as much confidence as being prepared. Of course, you need to know the content, but you should also understand the structure of your presentation and how you will move from point to point. You don’t need (or want) to memorize the presentation, but you don’t want to forget things either.

2. Rehearse

You should rehearse the presentation multiple times. This could be in front of a safe audience, or even saying the words to yourself. You don’t want to read content from a slide, but having the overall session framed by some slides with bullet points can keep you on topic and make the presentation more comfortable.

3. Relax

Get yourself mentally and physically prepared.

  • Get a good night’s sleep
  • Eat a healthy meal
  • Try to free your schedule, so you’re more relaxed
  • Before you present, spend 15 minutes going over your presentation one last time. You should have a copy of your presentation that you can review.
  • Relax

4. Get started

The hardest part of presenting is getting started. Talk slowly and breath. Smile. Once you get started, you will likely feel better and get into a groove.

5. Be confident

Much of your message is relayed through your body language.

  • Make eye contact with people
  • Appear confident using an open stance. Stand tall.
  • Smile and let your personality shine
  • Walk around a little
  • Vary your voice and use slow, open hand gestures.
  • Speak slowly and carefully, but passionately. If you’re enthusiastic about the topic, then your listeners will be as well.

6. Interact

Encourage interaction with others during your presentation. When others talk for a few seconds, it takes the focus off you and lets you clear your head and focus on the key points ahead. Interaction also keeps the audience engaged.

Public speaking is one of the hardest things to master. If you prepare carefully, have a great mindset and are enthusiastic, you will deliver a great presentation.

 

Three Steps to Identify and Address Poor Team Member Performance

/in /by

Three Steps to Identify and Address Poor
Team Member Performance

Project managers encounter team member performance problems all the time. In many cases you don’t feel like you have the authority to address these situations. However, usually you do have some options. You can at least better understand the nature of the performance problem. Depending on the severity of the problem you might also be able to address it.

Step 1. Gather the Facts – and examples

The first step is to collect facts that help you understand the nature of the performance problem. You should write down instances where the performance did not meet your expectations. You will need these examples to start a performance discussion. They should not be hard to gather. You would not be trying to resolve a performance problem if there were not specific instances to you can document.

Step 2. Have a preliminary discussion

Once the factual examples are ready, the second step is to have a preliminary performance discussion. This discussion will make the employee aware of the perceived performance problem. You will also get the employee’s feedback and response.

In many cases, the manager jumps to the conclusion that there is a performance problem, pure and simple.  However, there may be other reasons why the employee’s performance may not be up to expectations. For example, the performance problem may be the result of a skill gap. The problem could be caused by competing non-project work. The problem could be caused by a personality conflict. You need some insight into the nature of the problem before you can move head to resolution.

Step 3. Create an action plan for improvement

Once the projects manager and team member discuss the situation, he will be able to create the right action plan. Perhaps just bringing the performance perception to the team member’s attention will help to resolve the situation. The short-term plan may require work from both the manager and employee. The plan should also include a time to get back together again for a progress report. It is important to get back together to determine whether there has been any improvement in performance.  If there has been, then perhaps the situation just needs to be monitored from that point. 

As a project manager you have some ability to provide performance feedback when work is not up to your expectations. However, you do not have total control. If your preliminary three-step approach does not work, or if the team member is resistance to working with you, you will need to get the person’s functional manager involved and address the situation through a more formal performance management processes.

Three Ways to Ensure You Collect the Right Metrics

/in /by

Three Ways to Ensure You Collect the Right Metrics

Most companies want to collect more data to be used for fact-based decision making. However, companies struggle actually implementing a strong metrics program. There is a reason – it is really hard! However, there are things you can do to ensure you collect good metrics without going overboard.

1. Make Sure Your Metrics Add Value

Identifying, gathering and leveraging the right mix of metrics are ways to add value to an organization or a project. The value can be quantified in a number of areas including:

Improved performance of the overall project fulfillment and delivery process

Improved estimating for future projects

Validation of duration, cost, effort and quality objectives for the project

Identification and communication of best practices

Metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions and guesses.

2. Use the Metrics that You Collect

You don’t want to collect metrics just for the sake of collecting them. That is just a waste of time. If certain metrics are required by your organization, collect them. In addition, you should collect any other metrics that are needed by your particular project. However, if you don’t have a purpose for the metrics, or if your project is not long enough that you can really leverage the information, these customized project-specific metrics are not worth collecting for your project.

3. Compare the Cost of Collecting a Metric vs. the Benefit

There is a cost to collecting and managing a metrics process. In many cases, the cost to collect and leverage a certain type of metric is prohibitive. These metrics should not be pursued. Other metrics are interesting, but do not provide the type of information that can be leveraged for improvement. The bottom line is that the cost to gather each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that are required by the organization. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.

In summary, metrics collection and analysis is hard work. All organizations should make fact-based decisions based on supporting metrics. However, make sure the metrics provide value, are used effectively, and are not too costly to correct.

 

Eight Focus Areas that Lead to Project Success

/in /by

Eight Focus Areas that Lead to Project Success

There are many project management processes and techniques that can help you be successful. Here are eight areas to really focus. If you are successful in these ten areas there is a high probability that entire project will be successful.

    1. Requirements. Make sure that your customer defines their requirements in depth. You need to know exactly what must be delivered. Be specific, write them formally, and get them approved. This document will become one of the baselines upon which to validate your success.

      Deliver the agreed requirements.

 

  • Scope. Define scope well in terms of deliverables created and boundary statements (in-scope and out-of-scope). Get your sponsor approval for scope changes, making sure the sponsor understands any schedule, budget or other impact to the project.

    Deliver the agreed scope.

  • Stakeholders. Involve your stakeholders throughout the project. Get them involved in the analysis and planning, as well as execution. Gain their approval when needed and keep them informed when needed. The more you involve them, the greater their level of buy-in and the better you will manage their expectations.

    Keep stakeholders engaged.

  • Duration. Keep your delivery timeframes short and realistic. Split large projects into “mini-projects” if possible. Keep each mini-project to less than six months. This keeps everyone motivated and focused.

    Finish on tine.

  • Communication. Make sure you keep everyone informed by providing the right information at the right time. Produce status reports and run regular team meetings. Communication is all around managing expectations.

    Keep everyone informed. No surprises!

  • Risks. Risk management is a great proactive way to solve potential problems before they occur. Identify risks early in the project and continue to manage risks throughout the project.

    Solve potential problems before they occur.

  • Cost. Estimate costs as accurately as possible, and then manage costs proactively. Keep track of your costs as they are expended and the constantly reforecast the total projects cost as the project progress.

    Finish within budget.

  • Your team. Be a great people manager. Show them the project vision and how they can make it happen. Motivate them. Trust and believe in them.

    Value your team. They will work wonders.

 

 

Manage Project Risks Proactively with a Risk Register

/in /by

Manage Project Risks Proactively with a Risk Register

Risk refers to future conditions or circumstances that will have an adverse impact on the project if they occur. Whereas an issue is a current problem that must be dealt with today, a risk is a potential future problem that has not yet occurred. A reactive project manager addresses issues when they occur. A proactive project manager addresses potential problems before they occur. This is the art of risk management. (Risks can also have a positive impact on your project. These are called opportunity risks. This column focuses on the negative risks.)

There are many risk management templates. Three major documents are a Risk Management Plan, Risk Form and Risk Register. The Risk Register is used to track the state of all risks throughout the project. The Risk Register has the following information.

Date identified. The date the risk was identified and added to the Register.

Risk category. This is used to categorize risks into pre-defined buckets. This can be useful when you are analyzing the nature of risks to see the aspects of the project that are riskiest.

Risk. Describe the nature of the risk.

Probability. This shows the likelihood the risk will actually occur. All risks have probability greater than zero but less than 100%. This can be represented by a percentage or perhaps a scale that provides a subjective estimate – for instance a 1-3 scale that signifies low, medium and high risk.

Impact. This column shows the affect on the project if the risk occurs. This could be in terms of cost and schedule, or a subjective rating. For example, a subjective scale of 1 – 3 can be used. A “1” would signify a small impact. A “2” would signify a medium impact. A “3” would signify a large impact.

Risk Plan. This is where you would state what you are doing to manage the risk.

Assigned to. This column would show the person with ownership of resolving the risk.

Status. State whether the risk is open or closed. Risks are closed if the risk event actually occurs or if the timeframe has past and the risk did not occur.

The Risk Register should be reviewed on a weekly or bi-weekly basis. The current risks should be monitored to endure that the current risk plan for each risk is working. If the plan is not working, the plan should be revised. At each review, new risk should also be identified, analyzed and managed if they are significant.

Agile101 – Use the Product Backlog to Hold Work

/in /by

Agile101 – Use the Product Backlog to Hold Work

In an Agile project you don’t create large documents to hold user requirements. In fact you don’t need a traditional document at all. The Agile technique is to create a product backlog. The backlog is simply the prioritized collection of work that is remaining on a project. This could be a spreadsheet or table. It could also be a stack of index cards that each holds a unique item of work. It could also be in an Agile software tool.

The initial product backlog is generated at the start of an Agile project. It consists of all easily identified work that is known when the project starts. The following types of work are placed on the backlog.

User stories. User stories describe how stakeholders, or actors, interact to do something of value. These stories are a few sentences, or perhaps a paragraph. They are just detailed enough so that the product owner remembers what the scenario is, and can provide detailed requirements when the user story is worked on by the team.

Standalone deliverables. The product owner and Agile team may need standalone deliverables created on the project. For example, the product owner may need the team to create a user manual, training content, frequently asked questions, etc. The project team may need a disaster recovery manual and a records retention document. This work needs to be prioritized on the backlog and included in the appropriate iteration. You don’t need a user story to explain these types of deliverables – just put them on the backlog.

Defects and bug fixes. Many bugs that slip through testing are really more nuisances than severe errors. They need to be fixed but there is discretion as to the timing of the fixes. These types of fixes can be placed on the backlog and prioritized in a subsequent iteration. In some cases, the team will wait until the end of the project for one final cleanup of bugs and errors.

Non-functional requirements. User stories are great to describe processes, and how different actors interact to accomplish some work. However, other requirements may be more descriptive rather than process oriented. These are called non-functional requirements. For example, if your project is to build a chair, we would need information on weight, size, color, etc. You don’t need a user story to explain the color of the chair – just list it.

As each iteration begins, a planning meeting is held between the product owner and the project team. The product owner prioritizes work on the backlog. The team estimates the size of each element on the backlog, and pulls off only enough backlog elements that can be completed in the next iteration. This subset is referred to as an iteration backlog.

In a traditional project, changes to product backlog would be added using scope change management. In Agile, there are no formal scope change requests. The work in an iteration is fixed. The product owner can continue to add and prioritize new items in the full product backlog. This may result in additional iterations. It is also likely the some of the lower priority iterations will not be completed. The total number of iterations, and the timeline and budget needed to execute the iterations, is determined by this same product owner.

Apply These Three Techniques for Managing Scope

/in /by

Apply These Three Techniques for Managing Scope

Identifying and managing project scope is one of the most important elements for project success. Saying this another way, a lack of understanding and managing of project scope is one of the major reasons for project challenges. Here are three techniques that will help you be more successful managing scope.

Freeze Scope Change Requests Late in the Project

You might think that as long as the sponsor is willing to approve increases in budget and schedule to make a scope change, they should be able to do it. However, late scope changes tend to impact more than schedule and budget – they are a distraction. When a project team is focusing on implementation, it is time to freeze scope changes.

Depending on the nature of the project, this freeze is usually implemented as the team is getting ready for the “drive to implementation”. At this point, the team is focused on implementing the solution. Scope changes are not only costly, but they are also very disruptive. The team can lose focus and become mentally deflated.

This does not mean you cannot accept change requests after the freeze. However, the changes are held on a backlog and dealt with them later after the solution is implemented and stable.

Track all Scope Changes – Even Small Ones

One reason projects get into trouble is through scope creep. Scope creep refers to small incremental changes than are implemented without going through the scope change management process. This is for two reasons. In some cases the project manager does not recognize a scope change has occurred. In other cases, the project manager chooses not to go though the formal process because the change is small. If you only have a couple small changes, the impact to your project may not be noticeable. However, when these small changes occur frequently, the cumulative effect can be enough to impact the entire project schedule and budget.

The solution is to make sure you identify and track all changes – even small ones. Small changes can still be managed flexibly. For example, small changes may have a fast-track approval process. However, you want to make sure they are all tracked.

Do Not Use Estimating Contingency for Scope Changes

One of the steps in the estimating process is to add contingency hours, budget and schedule to reflect the level of uncertainty associated with the estimate. For instance, if the effort hours were estimated at 5,000 hours, you might add 500 hours for contingency, which reflects a 90% confidence factor and 10% uncertainty. Once the contingency is approved, there will be pressure on the project manager to use the contingency to absorb additional requirements. The sponsor might say, “Why do we need to invoke scope change management for this 100 hour enhancement. You have 500 hours of contingency built into your estimate!”

The project manager must resist the temptation and the pressure. The purpose of the estimating contingency is to reflect uncertainty in the estimates. There will be plenty of opportunities to utilize the contingency when activities take longer than expected. Do not use the estimating contingency to absorb extra work.

Quality Management Starts With Understanding the Customer’s Expectations

/in /by

Quality Management Starts With Understanding the Customer’s Expectations

There are two main aspects of managing quality

on a project. It all starts with understanding the customer’s expectations for quality. You then need to put a plan in place to meet the customer’s expectations.

You cannot formally manage quality on a project if you don’t know the customer’s expectations. The easiest way to understand expectations is simply to ask. Quality requirements can be gathered at the same time you are gathering the rest of the functional and non-functional product requirements. The quality requirements may not always be stated on their own. Often they need to be gathered through specific questions and inquiry.

It is hard to define product or service quality at a high-level because the term “quality” is vague and means different things to different people. You must take the time to define the lower-level characteristics of quality for each specific service or deliverable. Examples of quality characteristics include:

Product quality. The product is:

  • Reliable
  • Easy to use
  • Available when needed
  • Flexible for future needs
  • Intuitive / easy to understand
  • Minimally defective (doesn’t have to be perfect)
  • Responsive (good response time)

Service quality. The people are:

  • Responsive
  • Competent
  • Courteous
  • Credible
  • Knowledgeable of the customer
  • Reliable

These characteristics are still vague, but now you have some direction that you can use to probe further for more details.

Use These Techniques to Find Project Success

/in /by

Use These Techniques to Find Project Success

There are many techniques and processes to help you be successful on a project. Some of them, like stakeholder engagement and proactive communication, are pretty well understood. Here are some other ways to increase the likelihood of success on your project that are not so obvious.

  1. Understand both the big picture and the details

    If the devil is in the details, there is nothing more devilish than the complex and intertwining dependencies of a project. You need to be aware of the details, even if you don’t react to each detail each time. At the same time, it’s just as important to see the big picture. understanding the overall purpose and objectives of the project allows you to make decisions based on broader context. The big picture also allows you to see trends before problems emerge.

  2. Make decisions quickly

    Over analyzing and procrastination are the cause of many troubled projects. You need to use the best information you have available to make decisions quickly. Even if it’s not the BEST decision, a GOOD decision suffices in nearly all cases.

  3. Communication proactively and heavily

    You can never have enough communication. Wouldn’t it be great if your worst flaw on a project was that you over-communicated? Usually people complain about not knowing enough. Communicate heavily. Take a chance people will appreciate it.

  4. Manage risks proactively

    This one might fall into the more obvious category. But it is surprising to me how many projects do not formally manage risks. Some projects identify risks but don’t put a plan in place to manage them. Risk management does not take so much time. Do it.

  5. Manage expectations so there are no surprises

    Many project managers communicate, but not effectively. The do not realize how to communicate what is happening now and what is possible happening in the future. If you ever surprised a sponsor or customer, you probably were not managing expectations well.

  6. Make sure you get major documents approved

    Sometimes you think you are just too busy to get approvals for documents even if you know you need them. The result is often that the person tat should have approved the document ends up not approving the results, causing rework and confrontation.

  7. Involve stakeholders throughout the protect

    We should all know it is important to understand project stakeholders. But often we focus on stakeholders at the beginning and the end of the projects. To be really successful you need to engage key stakeholders all the way through the project.

  8. Cultivate good relationships with the Project Sponsor

    Stakeholder management is important, but one stakeholder is more important then the rest – the sponsor. Go out of your way to develop a good relationship with the sponsor. You will need to be comfortable with the sponsor (and vice-versa) as the project progresses.

Use all the obvious techniques for project success, plus these eight that are a little less obvious. You will have a much better chance for success.   

Validate Product Quality with a Deliverable Review 

/in /by

Validate Product Quality with a Deliverable Review 

Deliverable reviews, or walkthroughs, can be applied to many of the products produced by the project. For example, you can conduct a deliverable review for a project schedule, business requirements, IT program code, research papers, etc. The following process can be used to plan and conduct a formal deliverable review.

  1. Determine the appropriate review participants. The participants are typically peers with the person that created the deliverable, and have some expertise in the deliverable being reviewed. Managers can sit in on the review to understand the process, but they normally don’t have the detailed knowledge required to perform the actual review.

 

  • Define completeness and correctness criteria.

The team can define completeness and correctness criteria for the deliverable being reviewed. This C&C criteria may also be defined for all projects at the organization level.

  • Send out the review material prior to the meeting.

Where possible, the formal review will proceed more quickly if the team has a chance to review the deliverable ahead of time.

  • Conduct the review.

The person(s) that created the deliverable walks through the work in a logical manner and answers questions as they arise. The participants should keep the following meeting principles in mind:

 

 

      • Try and hold the review in one hour or less.
      • If any feedback becomes complicated, it should be taken offline.
      • When feedback is given, it should be clear whether it is an error that should be addressed or just a suggestion that might be followed.
      • Don’t make review comments personal. Stick to the deliverable.
      • Keep a list of action items during the review.

 

  • Check for “build” processes.

The deliverable review should focus on the completeness and correctness of the deliverable. However, the reviewers should also validate that standard processes were used to create the deliverable. The review will then validate that the deliverable is acceptable and that the process used to build the deliverable was acceptable. 

  • Conclude the review.

Use one of the following ratings:

 

 

      • Pass. The product meets all the completeness and correctness criteria set forth in the review and does not need further review.
      • Pass with minor updates. In some cases, minor changes are needed, but the deliverable does not have to be reviewed again.
      • More work needed. The product needs more work to meet the completion criteria required for the review. The product will typically need to be reviewed again with the same completion criteria once the necessary changes have been made.

 

  • Communicate the results.

Make sure that all interested parties are given the results of the review.

 

It may seem that this is a long process but it does not have to be. It is possible the reviewers can be identified an hour in advance, a short ad-hoc meeting is held, the deliverable is reviewed using known standards and (hopefully) passes the first time. You are done.