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 (1325)

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.
Thursday, 04 May 2017 19:49

The TenStep View of Processes and Templates

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

The TenStep View of Processes and Templates

I am not sure if it is obvious, but at TenStep we are "process people". We think that organizations that have good processes have a much better chance to be successful than the organization with weak processes. Of course, you have to have good processes and you also have to follow them.

Templates, on the other hand, are secondary and are a derivative of processes. Unlike my prior statement regarding organizations with good processes, I would not state that an organization that has good templates would have a better chance to be successful. In fact, if a manager bragged to me about their templates, I would assume that this meant that they probably have weak processes.

What is the value of a template? Templates are important as a way to document some aspect of a process. For example, part of a scope change process is the ability to track changes throughout the project. This requires a Scope Change Log. Similarly your project may require more sophisticated communication, which can be documented on a Communication Plan.

The important point about templates is that they don't drive a process - they are simply a result from a process. For example, a project manager in your organization might state "My sponsor wants to start this project but we can't until we complete a Project Charter." They may state this as a paperwork burden that must be overcome before they can start the real work on the project.

But is that really what is going on? You should understand the value that the Project Charter provides. It is not just a paperwork burden that must be checked off a list. The Charter represents the work done to define a project. The Charter contains the project objectives, scope, deliverables, risks, assumptions, organization, milestones, etc. If a project manager complains about a Project Charter, they are really saying that they want to start the project before they understand these things. Does that make sense? Do you really want to start a project before you know the deliverables and scope and risks? I don't think so. The Project Charter allows a project manager to understand these fundamental aspects of a project, and then to document this information to make sure that there is a common understanding with the sponsor and other project stakeholders.

Of course, templates need to be scalable. Small projects need small templates. Larger projects need more complex templates since the processes are more complex.

I know of organizations that have very weak processes and so they can only focus on templates as a proxy for some process that is not well defined. In these organizations, the mentality is that you just need to complete certain templates to move past some checkpoint. Then it seems like the template ends up running the process. This is not right.

Summary

When people complain about templates, remind them of the process that the template represents. If the process makes sense, then the template makes sense. If the process does not make sense, the associated template won't either. 
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.27.04

Was Your Project Successful - Within Tolerances?

Estimating the time and cost is an important part of project planning. If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted on your manager's shoulder and paraded around the company as a hero.

Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +10%. That is, if you deliver the project 10% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $23,000 and still have been considered successful.

Normally there is some room for tolerances with your deadline as well. In most cases, you can deliver a little late and still be considered successful. Of course, not all projects have that flexibility. Some projects do have a fixed end date that cannot be moved. But many projects have some flexibility.

Declaring Success From a Project Perspective

Once you understand your tolerances (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:

  1. The project is delivered within the estimated cost, plus or minus the tolerance.
  2. The project was delivered within its deadline, plus or minus the tolerance.
  3. All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
  4. The overall quality is acceptable. (It does not have to be perfect.)
Other factors may be important for specific projects. For instance in a construction project, safety might be a key success component.

Declaring Success from a Company Perspective

From a company perspective, success is also based on whether the company received the business value that was promised. There are many examples of projects that were completed successfully, yet are not delivering the value promised. It is possible that the return on investment calculations were faulty, or the marketplace was misjudged by the sponsor. Success against the project business value, as defined in the Business Case, is ultimately the responsibility of the sponsor - not the project team. 
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 302 guests and no members online

Got something to say?