Eight Focus Areas that Lead to Project Success

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

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

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

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

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

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 

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.  

Four Ways to Manage the “Project Grapevine”

Four Ways to Manage the “Project Grapevine”

Ever heard the song “I Heard it Through the Grapevine”? Were they talking about the project grapevine at your company?

The “grapevine” is a great metaphor for the way informal and unofficial news travels from person to person. Official news comes through official channels. Informal news, rumors and gossip travel though the grapevine.

In a project environment, the circulation of unofficial information and rumors can be disruptive and destructive. Your communication plan addresses the formal communication content and paths, but it can be hard to manage the grapevine. (Click here for a free Communication Management Plan

.) The following tips help stop the confusion and manage the grapevine effectively.

1 – Become Part of the Grapevine

People love talking about what goes on within their work environment. As a project manager, you cannot monitor and manage the grapevine unless you can be a part of it, or at least aware of what is being said. Sometimes it is hard for a manager to be a part of the staff grapevine – but try. Assume the projects you manage are one part of that conversation, insert yourself into it and ask people what they are hearing about your projects. Then be sure to add your own facts into the mix. A little bit of accurate information never hurt anyone.

Tip 2 – Combat Negative Messages

Negative communication sometimes gets spun into a mile-long email thread. Inaccurate information and intensity of emotion continue to escalate the longer the email thread grows. The best antidote to negative communication is to get the facts out as quickly as possible. Compose a thoughtful and precise message with a handful of relevant facts to get everyone in sync. Ask your team members to carry the message forward in their grapevine discussions.

Tip 3 – Stop the Bad Press

Much of the talk on the grapevine is harmless babble, primarily serving as an interesting diversion during a long day at work. However, sometimes the message can be very negative and detrimental to the project. In this situation try to track down the source, and discuss the situation with the person formally. The rebuttal is much more effective if the person that started the bad press is also the one to put out the correction. Even if you cannot find the source, put out a positive rebuttal to the people that can carry the message forward in the grapevine.

Tip 4 – Fill the Vacuum

You may have projects that aren’t impacted by negative communication. However, you may then have a vacuum of communication. It’s up to you to fill this void with positive and factual information about your project. Send out pertinent emails, give appropriate updates at company meetings, and have one-off conversations. That way, people will have something positive to talk about when your project gets tangled up in the grapevine.

The grapevine has been around since the time the 3rd person walked on this Earth. There’s nothing you can do to stop it from happening, so include it as part of your unofficial communication plan. You’ll notice a big difference with the buzz on your projects.

 

An Optimized Portfolio “Pivots” Quickly to Respond to Change

An Optimized Portfolio “Pivots” Quickly to Respond to Change

Agile portfolios are flexible and can respond quickly to changes in business needs. This ability to change directions quickly is referred to as the “pivot”. (“Pivoting” is also a basketball term. It refers to planting your foot (the pivot foot) and then quickly changing directions.)

How quickly could your organization react if there was a sudden change in your business direction? What you should do is to start approving new projects that support the new direction. How do you staff these new projects? One way is to steal resources from other projects to work on the new priorities. This stretches out the current projects but it allows you to start the new ones. You could also cancel projects to free up resources, but this has the disadvantage of losing the business benefits of the projects that are stopped.

The better approach is to maintain an active portfolio of projects that is staffed optimally to start and finish in as short a timeframe as possible. This may seem obvious but most portfolios have too many projects in-progress. This results in projects being resource constrained. Resource constrained means that a three-month project might take six months, and a five-month project takes ten months. Since projects are not ending frequently, sponsors don’t want to wait until resources are available. Instead they want their projects to start now. However, starting projects by stealing resources from other projects makes all the projects stretch out even further.

Optimizing the staffing in a portfolio starts with realizing one key point – you don’t obtain business benefit when a project starts – but when it is completed.

This is an important concept and I will repeat it again. The business benefit derived from projects is not based on when the project starts – but when it ends. This means you should determine which projects are most important (prioritization) and then staff the highest priority projects so that they complete as quickly as possible. Having too many active projects delays the completion of the most important projects since they are sharing resources with less important ones.

This brings us back full circle. Optimizing project staffing allows projects to complete more quickly. Having projects that are ending within any given timeframe allows you to “pivot” quickly. As new priorities arise, the new projects can start quickly because there are always current projects ending and resources available.

 

Eight Characteristics of a High-Performance Team

Eight Characteristics of a High-Performance Team

Have you ever been on a project team that had everything going right?  The team members all got along; they all had the right skills; they had the right processes; everyone worked hard and pulled together to get the project done.

Those are just some of the characteristics of a high-performing team.  High-performing teams can sometimes form by themselves, perhaps even in spite of a manager that gets in the way.  It is also possible that a manager can facilitate a team through a process that leads them to become high performing. The following actions can help the team’s growth. 

  • Set common objectives.  Teams will have a hard time performing at a high level unless they are all striving toward a common set of objectives.  Even if members of your team do different jobs, a set of objectives can usually be written that will encompass all of them. 
  • Establish good internal work processes. You cannot build consistently good products, or deliver good services, with poor work processes.  The high-performing team has a set of internal processes that guide how members act and react in particular circumstances. 
  • Instill good work ethic. High-performing teams find the challenges associated with their work and work hard to complete their assignments within expectations.  Members get more work done in a typical day than their counterparts.
  • Keep everyone focused.  Team members understand the work they have on their plate today, as well as what the remainder of their work is.  They don’t get sidetracked by rumors or politics.   
  • Maintain a high level of motivation. The high-performance team relies on both self-motivation as well as a reinforced motivation through the entire team.
  • Keep organized. Team members know where to find the things they need to do their job, and they know where to put things when they are done.
  • Strive toward a balanced set of key skills.  A high-performance team has the skills needed to complete the work on its plate. People understand their strengths and weaknesses, but they also are willing to work outside their comfort area when needed.  
  • Foster mutual respect. Team members have mutual respect for each other and trust that the others are working as hard as they are. 

In the right circumstances, a manager can take the lead to move a team toward high-performance status.  It takes time. If it were easy, every team would be high performing, instead of the one or two that you may have worked on in your entire career.    

Contact us today to discuss how we can help you strengthen your project, portfolio and PMO processes.