Project Management Central

Please login or join to subscribe to this thread

Topics: Benefits Realization, Business Analysis, PMO
Which are the aspects would you consider to treat an initiative as a large project with several phases or treat it as a program?
Network:14



I'm a little confused about the circumstances in which is most useful to divide a initiative in several projects that belong to the same program or to treat it as a large project with several phases.
Sort By:
Page: 1 2 next>
Network:365



Aldo,
One way that I would consider useful is how dependent are the individual phases.

Consider for example, an effort that includes a research and development phase to develop new technology, a design phase that integrates that technology into one or more products, a production phase that starts an assembly line and establishes regular operations, an improvement phase which makes the product perform better and more profitable to produce, and a support phase.

Many of those phases have limited direct influence on the others. The technology may be one part of many technologies implemented in the products. The products may be developed independently with limited influence on one another. The production challenges may be unrelated to the underlying technology. The improvements may be a number of discrete unrelated changes. The support may involve logistics rather than technology or production. That is a clear program. Projects of finite duration and scope can be managed relatively independently.

Other long duration efforts rely on one dominant "thread" or critical path. A new technology development may involve a long testing phase that will highly influence the design using it. The production challenges may be building that technology so that it works repeatably. The support may be planned upgrades to the technology as it is implemented in phases, or the customers need to understand how to use it. That could be a program, but it is more like a project because if any one doesn't work, none of them work.
...
1 reply by Aldo González Escañuela
Dec 03, 2019 9:12 AM
Aldo González Escañuela
...
So before make a decision I need to realize the dependency level between the whole elements. Thanks for your answer Keith.
Network:1706



Aldo -

At its most basic, you manage something as a program if there is benefit in coordinated management at a higher level with distributed management at the lower levels. There are actually three choices:

1. Manage the projects as separate components and have each PM responsible for keeping an eye on the inter-dependencies with other projects. This is usually not advisable if there is a common, higher level outcome expected from the combination of all of these projects and if there are significant inter-dependencies between the projects.

2. Manage the projects as work-streams or sub-projects in a big project.

3. Manage the projects as integrated components within a program.

The distinction between #2 and #3 is often organizational-driven.

There is NO universal definition of the threshold or criteria at which a large project is treated as a program - some organizations will base it on a combination of factors such as size (e.g. cost, peak staffing), nature of the outcomes, degree of complexity.

Kiron
...
1 reply by Aldo González Escañuela
Dec 03, 2019 9:18 AM
Aldo González Escañuela
...
Probably I won't have a PM for each project and my organization just have a supportive PMO, so may be the more useful strategy could be the #2.
Thanks Kiron.
Network:2984



Dear Aldo
Interesting your question
Thanks for sharing

Which is more advantageous for the organization?

Manage as different phases of a project?

Manage the projects as integrated components within a program?

I absolutely agree with Kiron: "There is NO universal definition of the threshold or criteria in which a large project is treated as a program - some organizations will base it on a combination of factors such as size (eg cost, peak staffing) , nature of the outcomes, degree of complexity. "
...
1 reply by Aldo González Escañuela
Dec 03, 2019 9:25 AM
Aldo González Escañuela
...
The problem is that in deed I'm looking for arguments that help to my organization to realize about those advantages or disadvantages. The Keith argument is useful because it leads me to anaize the dependencies but the Kiron perspective is also good because we need to take in count our resourses and knowledge as restrictions to make a decistion.
Network:1939



You can apply the same principle than system analysis: creating modules with low coupling and high cohesion will help you to manage the program/projects.
...
1 reply by Aldo González Escañuela
Dec 03, 2019 9:27 AM
Aldo González Escañuela
...
I really don't know how to do it. Do you have a paper that recomend for this?
Network:31515



Agree with Sergio.
Network:14



Dec 02, 2019 8:56 PM
Replying to Keith Novak
...
Aldo,
One way that I would consider useful is how dependent are the individual phases.

Consider for example, an effort that includes a research and development phase to develop new technology, a design phase that integrates that technology into one or more products, a production phase that starts an assembly line and establishes regular operations, an improvement phase which makes the product perform better and more profitable to produce, and a support phase.

Many of those phases have limited direct influence on the others. The technology may be one part of many technologies implemented in the products. The products may be developed independently with limited influence on one another. The production challenges may be unrelated to the underlying technology. The improvements may be a number of discrete unrelated changes. The support may involve logistics rather than technology or production. That is a clear program. Projects of finite duration and scope can be managed relatively independently.

Other long duration efforts rely on one dominant "thread" or critical path. A new technology development may involve a long testing phase that will highly influence the design using it. The production challenges may be building that technology so that it works repeatably. The support may be planned upgrades to the technology as it is implemented in phases, or the customers need to understand how to use it. That could be a program, but it is more like a project because if any one doesn't work, none of them work.
So before make a decision I need to realize the dependency level between the whole elements. Thanks for your answer Keith.
Network:14



Dec 02, 2019 8:57 PM
Replying to Kiron Bondale
...
Aldo -

At its most basic, you manage something as a program if there is benefit in coordinated management at a higher level with distributed management at the lower levels. There are actually three choices:

1. Manage the projects as separate components and have each PM responsible for keeping an eye on the inter-dependencies with other projects. This is usually not advisable if there is a common, higher level outcome expected from the combination of all of these projects and if there are significant inter-dependencies between the projects.

2. Manage the projects as work-streams or sub-projects in a big project.

3. Manage the projects as integrated components within a program.

The distinction between #2 and #3 is often organizational-driven.

There is NO universal definition of the threshold or criteria at which a large project is treated as a program - some organizations will base it on a combination of factors such as size (e.g. cost, peak staffing), nature of the outcomes, degree of complexity.

Kiron
Probably I won't have a PM for each project and my organization just have a supportive PMO, so may be the more useful strategy could be the #2.
Thanks Kiron.
Network:14



Dec 03, 2019 4:24 AM
Replying to Luis Branco
...
Dear Aldo
Interesting your question
Thanks for sharing

Which is more advantageous for the organization?

Manage as different phases of a project?

Manage the projects as integrated components within a program?

I absolutely agree with Kiron: "There is NO universal definition of the threshold or criteria in which a large project is treated as a program - some organizations will base it on a combination of factors such as size (eg cost, peak staffing) , nature of the outcomes, degree of complexity. "
The problem is that in deed I'm looking for arguments that help to my organization to realize about those advantages or disadvantages. The Keith argument is useful because it leads me to anaize the dependencies but the Kiron perspective is also good because we need to take in count our resourses and knowledge as restrictions to make a decistion.
Network:14



Dec 03, 2019 4:27 AM
Replying to Sergio Luis Conte
...
You can apply the same principle than system analysis: creating modules with low coupling and high cohesion will help you to manage the program/projects.
I really don't know how to do it. Do you have a paper that recomend for this?
Network:1939



MIrá, hay varios lugares donde este tema es tratado. Asi al boleo, encontré esto: http://blog.koalite.com/2015/02/cohesion-y-acoplamiento/
Esto se usa hasta para el diseño de organizaciones.Yo como program manager he generado hasta el metodo de decision para la empresa donde trabajo hoy.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Don't go around saying the world owes you a living. The world owes you nothing. It was here first."

- Mark Twain

ADVERTISEMENT

Sponsors