This post includes excerpts from a Case Study that we will be publishing later this year. The post is from Chapter 1. The Case Study, let us call it MLP, or ML Program for now.

Project or Program

The question of project or program (project management or program management) often confuses practitioners of project management. This case study is not about project management versus program management, therefore, we will only offer the definitions that we follow in SUKAD Group, which are the basis for all of our work and the context in this case study.

Project (Project Management)

Here are the general points we use to define a project:

• A project has a specific product (output), objectives (outcome), defined timeline (schedule), budget, and various other parameters (resources, quality, risks, etc.).
• It is an investment of time and money to deliver a product or service (output), and it must deliver the capabilities to enable the realization of benefits (outcome).
• The project owner can verify and accept the output at completion and close out but often cannot validate the outcome until months or years after completion of the project work.
• A project can be independent or part of a program.
• If the project is independent, then it must directly align to the organizational strategic direction.
• If it is part of a program, then it must align to the program objective, which in turn, must align to the organizational strategic direction.

Program (Program Management)

Here are the general guidelines that we follow to define a program:

• A program is a group of related projects and may include other operational work.
• The projects are related to a common business objective, often a strategic long-term objective that aligns with the organizational strategic direction, mission, and vision.
• While working on the program, the organization may adjust the projects such as accelerating or slowing one or more projects. The changes would be driven based on the organizational needs and various factors.
• The number of projects within a program could also increase or decrease. The change would be due to the organization collecting feedback from the ongoing work and completed projects. It is worth noting that some might call this Agile Program Management but we call it a good traditional project and program management.
• Finally, each project within the program must deliver some benefits. This would be in addition to the incremental or collective benefits of the entire program.

Figure 1 is a generic program life cycle, per the SUKAD Way™.

Please note that, in a program (an in the program life cycle), we do not pre-define the number of projects. This is why we use Project N before Close Program. Further, we treat the program set up as a project (Project 1).
Although this figure is showing sequential projects, with minor overlap, some of the projects could be progressed in parallel. The projects could also have significant overlaps.
Program control will be happening from beginning to end while project control will apply to each project.
Stay tuned for more info about this interesting program.
[contact-form][contact-field label=”Name” type=”name” required=”true” /][contact-field label=”Email” type=”email” required=”true” /][contact-field label=”Website” type=”url” /][contact-field label=”Message” type=”textarea” /][/contact-form]