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

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.
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.26.4

Frustration Culture
When Actions and Principles Don't Align


Believe it or not, there are many fine companies in the world that have great products and treat their employees well. There are also many companies that are just plain rotten. Of course, most companies fall somewhere in the middle.

One of the reasons that employees don’t like working at their companies is that their companies are not intellectually honest with them. They say one thing and do another thing. They have lofty ideals or principles on paper, but they do not follow through and actually implement policies and processes to back up their words.

“Frustration Culture”

In a broad sense, the term culture refers to “how we do things around here.” Culture refers to the formal and informal policies and procedures that define how you do your job. This includes how you relate to your managers, peers and clients.

The term “frustration culture” can be used to describe the way employees feel when a company’s actions don’t follow their words because frustration is the most common feeling that people have in those circumstances.

Here is an example to see how this happens. Company A is a consulting company with a fine Mission Statement that explains that their people are their number one asset and that they invest in their staff to ensure they are well trained and capable. However, in reality, it appears that people are their number one asset only while profits are strong. When profits fall, training and employee development are the first things to be cut.

Company A is an example of a place with a frustration culture. Their problem is that they say one thing and do another. Their literature talks about their commitment to employees, but that commitment is only an inch deep when company profits are on the line.

Good companies usually tell you up-front what is important to them and, in fact, try to follow through on those commitments. They tend to set and manage expectations very well.

Managers should honestly evaluate their company’s actions and words. This includes their own personal actions and words. If the words don’t match up with the actions, then lobby for change. Each manager has a limited ability to change the entire culture, but they can start be changing their own organization. Start the change now. Start in your own organization, then look for ways to move it outward.
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 351 guests and one member online

Got something to say?