ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs
Project Management Blog
Blogs

Blogs (1307)

Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.18.05
Use Special Techniques to Manage Virtual Teams

Many years ago, a project team almost always resided in one location. The reason is obvious: it was not easy to communicate and collaborate with people that were not in the same physical location. Today, it is becoming more and more common to have team members physically located in many different places. This may be because of pulling in resources from other company offices. In some cases, you may have team members that are teleworking from home. In other cases, you may be partnering with a third-party company - perhaps even internationally. When it is not easy to meet team members face-to-face, we saw that we are working as a virtual team.

Virtual teams are more common today because of advances in technology. People can access their company's computer network remotely with almost the same speed as if they were in the office. Software is available to share documents and make updates available real-time to the rest of the team. The team can get together as needed using audio conferencing. You can even see each other using video technology.

That is all good news. However, there are still challenges managing virtual team members. There is no technology that can take the place of reaching out and touching someone or talking to them face-to-face. That being said, there are techniques that can help you be successful. Consider the following ideas:

  • Make sure everyone has the right equipment. Make sure that your remote team members have the right hardware, software, and other equipment to get their work done. The virtual team members need to access the company network and need to be able to work as if they were in an office in your building. There are many products on the market that allow for much easier collaboration among people who are in different locations. Much of this is web-based. For instance, you can get products that allow everyone to participate in a common meeting on the web, including viewing and changing common documents.
  • Make sure people have the right attitude. Both the project manager and team members must be especially diligent and sensitive to collaboration and teamwork concerns when part of the team is remote. It is easy for a remote worker to fall into a mode where he is isolated from what is going on with the rest of the team. People who are working remotely must be proactive communicators and must be especially good at working independently and meeting their deadlines.
  • Establish good communication processes. The project manager needs to develop a proactive Communication Plan to ensure the dispersed team works well together. For instance, if possible there should be regularly scheduled meetings where the remote workers attend in person. If the team members are in different cities or different countries, look for common times when you can have a videoconference or audioconference.
  • Try to meet in person - even if only one time. You may not be able to easily meet face-to-face, but can you at least do it one time? You could get the team together for project planning and team-building. This can go a long way to help build team cohesion. If possible, try to meet periodically, but worst case try to at last meet once.
  • Plan the handoffs. Sometimes multiple people in different locations are working on the same, or related, deliverables. In these cases, the project manager may need to establish rules for handoffs, especially if different time zones are involved. Don't leave the handoffs to chance. Set up processes to ensure that work on shared deliverables transitions smoothly from one person (or team) to another person (or team).
The bottom line is that the project managers must recognize that there is inherent risk associated with remote team members. The risk gets larger if people also are many time zones away. However, a proactive project manager can work through the difficulties by looking holistically at the people concerns, process concerns, and technology concerns. 
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Thursday, 18 May 2017 00:27

Two Techniques for Qualitative Risk Analysis

Written by
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.17.5
Two Techniques for Qualitative Risk Analysis


After you identify project risks, you need to analyze them to see which ones are important enough to manage. The most common form of analysis is called qualitative risk analysis. This is referred to as “qualitative” since it is a quick approximation of the risk severity and does not reflect the rigor of a detailed, numerical analysis. The overall risk level can be as simple high, medium, or low (or even high/low), depending on the severity of impact and the probability of the event occurring.

There are many techniques for performing qualitative risk analysis using simple tables. Here are two examples that are fairly common.

High, Medium, Low Table

For example, you can use a table like the one below as a starting point. It helps identify high, medium and low level risks by looking at the probability of the occurrence and the overall impact to your project. For instance, a highly likely / high impact event is obviously a high risk. Likewise an event that has a low impact to your project, and has a low likelihood of occurrence anyway, is obviously a low risk. The other combinations fall somewhere within these two extremes.

Severity of Risk Impact / Probability of Risk Occurring

Overall Risk

High negative impact to project / Highly likely to occur

High

High negative impact to project / Medium likely to occur

High

High negative impact to project / Not likely to occur

Medium/Low

Medium negative impact to project / Highly likely to occur

Medium

Medium negative impact to project / Medium likely to occur

Medium/Low

Medium negative impact to project / Not likely to occur

Low

Low negative impact to project / Highly likely to occur

Low

Low negative impact to project / Medium likely to occur

Low

Low negative impact to project / Not likely to occur

Low

Ignore, Caution, Respond Chart

A second technique uses a simple table that provides guidance on whether you should respond to a risk.

Probability ->

Impact




Low




Medium




High

Low

Ignore

Ignore

Caution

Medium

Ignore

Respond

Response

High

Caution

Response

Response




The green boxes represent a combination of probability and impact that you may safely be able to ignore. The red boxes represent combinations that need to be managed. The yellow box represent risks that should be evaluated individually to determine if you should respond or not.

Summary

These are examples of techniques used to analyze project risks. There are many other techniques as well. The point is that qualitative risk analysis relies on subjectivity to determine whether a risk is worth managing or not. For the vast majority of projects this subjective decision is good enough.
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.11.05

Use These Seven Aspects of Basic Document Management

The larger the project, the more rigor and structure is needed to manage documents


. You can end up with a big mess trying to save and find documents if you do not think through a good document management plan ahead of time. The following areas should be considered part of an overall document management plan.
  • Determine where to store documents. The project team should have a common area, or repository, for storing documents. This could be in a file directory, SharePoint site, paper file cabinet, etc. The project manager should be sure that documents are not stored in multiple locations based on the preference of each team member.

  • Determine the types of documents to include. The team also needs to determine the types of documents that will be added to the document repository. It is possible that the repository can hold every document in every stage of completion, including drafts and documents in each team member’s work area. However, it is also common for each team member to have a work area for his own documents and for the document repository to only hold final, approved deliverables.

  • Define an organization structure. Once you know where you will store documents, you should also determine the directory or folder structure. This will provide guidance to team members on the specific locations to store documents and will likewise help the team find documents when they are needed.

  • Define naming standards. It can be hard to find documents even if you have a good organizational structure. A common document naming standard will make it easier. Although this exercise might seem tedious, having a common naming standard for related documents will be very valuable as your project team generates hundreds of documents over time.

  • Determine if some documents need versioning. The project manager should determine whether multiple versions of documents will be saved or if just the latest version will be saved. Many documents, such as the Project Charter, should have all approved versions saved. On the other hand, documents such as the Issue Log only have a current version.

  • Determine if (and how) you will track document approval status.When documents need to be approved, and especially if the approval process can be lengthy, it is important to signify the document approval status. For instance, it is important to know whether a deliverable you are reading is a final approved version or a draft. Having separate libraries for documents as they go through the approval process can do this. Typical document indicators are “draft”, “work in-progress” and “final”.

  • Define standard document formats. It is easier in the long run to read and create documents if they all follow a standard format such as font style and font size. In addition, the team can create standard headers and footers, cover pages and table of contents. This will give all the documentation a standard look and feel.

Think about document management ahead of time on large projects. It will save you a lot of extra work and aggravation one the project starts. 

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Wednesday, 10 May 2017 20:20

Projects, Programs, and Portfolios Explained

Written by
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.10.5

Projects, Programs, and Portfolios Explained

Many people hear the terms projects, programs and portfolio, but are not sure what they all mean and how they fit together. All three are structures that allow us to organize certain types of work. These three concepts need to be understood by project managers.

Projects

Projects, by their definition, have a defined start and end date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project. Projects also include a defined scope, finite budget and assigned resources. Another characteristic of a project is that they always build something. Projects are how we create new things. If you find that all you are doing is meeting, then you probably are not on a project. Projects always create one or more deliverables. Projects should be managed proactively using solid project management processes and techniques.

Programs

Some initiatives are so large that it makes sense to break them up into a set of smaller projects. These smaller projects are easier to plan, manage and finish successfully. However, the problem with breaking up work into smaller projects is that each project may start to make independent decisions that will be good for that project, but detrimental to the initiative as a whole.

The purpose of a program is to provide central management and control over a set of underlying projects that are all trying to deliver a common solution. The program allows the projects to achieve a common benefit that would be difficult for each project to achieve independently. Programs are managed much differently than large projects. It is important to understand when to create a program and how to manage programs effectively. 

Portfolios

Portfolios are collections of work. A portfolio typically contains projects, but they can also include support, operations and other types of work as well. Portfolio management is generally performed by your manager staff. Projects are initiated, approved and prioritized at the portfolio level. The projects in the "active portfolio" are then staffed, governed, monitored and supported at the portfolio level.

Programs and projects are proposed, selected and executed at the portfolio level.

Summary

Just remember the key points. Projects are temporary endeavors to build one or more deliverables. Program are very large initiatives that are broken up into a set of smaller projects and then coordinated centrally. The projects in a program are related. Portfolios are collections of work - usually projects - and are a way to approve and monitor the projects from an organization perspective. The projects may or may not be related.
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.06.05

Start Risk Identification with Inherent Risk Factors

Would you agree that large projects are generally riskier than small projects? Would you agree that having an inexperienced project team is riskier than having an experienced project team? Would you agree that using new technology on your project introduces some additional risk over a project that uses current technology.

Notice I did not give you any other information about the project. I did not tell you the type of project, the deliverables, the organization or any other project description. These are example of "inherent" risks. They are risks that are inherent in the nature of your project. In other words, these types of risks are applicable to any project.

When you are identifying project risks, you can start with a checklist describing inherent risks, since they tend to hold true for all projects. Of course, the checklist needs to be customized for each organization to describe the risk level and risk tolerance for your organization.

Examples include:

Characteristic

High Risk

Low Risk

Duration

Longer than 12 months

Less than 3 months

Team size

Over 25 members

Fewer than 5

Project scope / deliverables

Poorly-defined

Well-defined

Project team and customer business knowledge

Neither the project team nor the customer have solid business knowledge

Both the project team and the customer  have solid business knowledge

Requirements

Very complex, hard for customer to define

Easy for customer to define

Organization structures

Large amount of change

Little or no change

Physical location of team

Team is dispersed at several sites

Team is located together

Use of formal methodology

No formal methods or processes

Standard methods in use

Technology

New technology is being used for critical components

No new technology required





In the table above, medium-level risks would fall somewhere in the middle of the high and low risk.

Checking for inherent risks is the starting point for risk identification - but it is not the end. After you check for inherent risks, you still need to identify risks that are specific to your project. The combination of inherent risks and project specific risks will make up the totality of risks you take to risk analysis. 
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 469 guests and no members online

Got something to say?