Please login or join to subscribe to this thread
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.
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.
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. "
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.
Agree with Sergio.
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.
Please login or join to reply