Introduction

This is a draft of the manual for review. If you have any comments, please email them to info@omimo.org. Please check back for the final version.

P4.express is a minimalist, practical way of managing programs. It has a simple process, as shown in the diagram. It consists of 29 management activities in 6 activity groups. Click on any of the activities on the Web version of the diagram or use the table of contents in the downloaded versions to open its description. Alternatively, you can simply start with the first activity, A01, and read through all the activities in order.

Nature

P4.express is a step-by-step approach to managing programs, which is usually referred to as a method, methodology, or framework. It’s not a descriptive guide on how all or some organizations manage their programs but instead a description of a single way of doing that, called P4.express.

Compatibility

P4.express, like all other modules in the OMIMO family, is modular. This means that you can use it in any setup rather than being limited to using it with projects and portfolios that use OMIMO methods; for example, your projects may be run using P3.express, micro.P3.express, DSDM^®, Scrum, PRINCE2^®, or any other system without causing problems for P4.express.

P4.express can be used for any type of program: infrastructure, urban, organizational change, health, cultural, artistic, humanitarian, etc. While P4.express targets all industries, edge cases within these industries are not targeted because they would make the system too complicated for everyone.

When there’s structured portfolio management, P4.express expects it not to be directly involved in the projects within the program. The portfolio management should only direct the program as a whole and let the program direct its own projects.

Scale

P4.express can be used in a wide range of programs, from small to large. However, it’s designed for programs that only have projects and ad hoc activities under them; it’s not expected to have smaller programs under a P4.express program, as that’s not needed in most cases and would complicate the system.

External customers

Your organization may be undertaking the program for itself or for an external customer. When it’s for an external customer, it’s important to have a compatible contract because programs are, by nature, highly nondeterministic and exploratory, and fixed-price contracts are not suitable for them.

Remember that programs are the main driver for innovation, while projects are for implementing the innovations of the programs.

Projects without programs

Projects focus on creating tangible outputs, whereas programs focus on creating relatively-abstract outcomes. Programs run multiple projects and ad hoc activities to enable and sustain their outcomes.

There’s always a program behind a project, but it might be implicit and overlooked. For example, a project for building a hospital in a town is probably undertaken to help improve the healthcare in that town. Someone has to check whether building the hospital is the best option for improving healthcare in that town, and if so, what other things should be done to really enable that outcome. That describes the program behind the project, which may be done implicitly, without structure. Having a structured approach greatly benefits such programs, especially because it ensures (as part of the program) that outcomes are not left on their own, but are continued by being actively sustained.

Programs are not limited to medium or large cases such as the example above. Your learning of P4.express can be considered a project. You can think of the program behind it and make it explicit, along with its enabling and sustaining activities.

So, from a holistic standpoint, there’s always an implicit or explicit program behind every project. However, for a supplier who’s responsible for a project, the program may not be within their scope, and that’s when we can have standalone projects in organizations that conduct projects for external stakeholders.

Process

There are 29 activities in the P4.express process, divided into the following activity groups:

• Program Initiation is run at the beginning to create a foundation for the program and to decide whether it’s a good idea to run the program.
• Monthly Initiation is run at the beginning of each month to revise and refine the plans and to check whether it’s still a good idea to continue the program.
• Weekly Management is for synchronization.
• Daily Management is for daily activities such as follow-ups.
• Monthly Closure closes each month by evaluating the results.
• Program Closure closes the program when it has achieved its goals or when it’s canceled.

Programs that are very fast-paced can replace the monthly cycle with a weekly cycle and remove the normal Weekly Management activities.

A project is finished when its output is created, but that’s not the case with a program: After the expected outcomes are enabled, the program should continue for twice the number of cycles that it took to enable the outcomes (or any other duration that’s appropriate to the case) to sustain those outcomes. The first few cycles may be entirely focused on enabling outcomes, the next cycles on both enabling new outcomes and sustaining the old ones, and the remaining ones entirely on sustaining the outcomes. The existence of the enabling cycles removes the need for having a post-program cycle similar to that of other OMIMO modules.

Roles

The following are the primary roles in a P4.express program:

• Sponsor: The sponsor is the highest role and is ultimately responsible for the success of the program. This person is responsible for high-level decisions and for providing the program with resources. There can be a steering committee, a portfolio management system, and many other decision-making entities involved, but all of them must be represented in the program through a single sponsor.
• Program manager: The program manager reports to the sponsor and is responsible for coordination, facilitation, conflict resolution, etc.
• Solution ideation team: This is a team of experts who come up with different ideas on how the program can achieve its goal. They design the solution at a high level and see how it can be implemented by various projects.

In addition to the primary roles, the underlying projects should have the following roles, involved in the program as secondary roles:

• Someone responsible for coordination in the project: Normally, this role is called project manager. If the project is run by a method or framework that doesn’t have a project manager role, a role that’s more focused on coordination and facilitation should have this function and be involved in the program. Regardless of what the role is called in the project layer, we call it the “project manager” in the program layer.
• Someone to make high-level decisions in the project: Normally, this role is called project sponsor or project executive. In cases where they don’t have such a role, its function should be given to one of the existing roles. Project sponsors report to the program sponsor. Regardless of what the role is called in the project layer, we call it the “project sponsor” in the program layer.

In small programs, a single person may be the sponsor of the program as well as its projects, and a single person can be the program manager and project manager for all projects. However, combining the sponsor and program manager roles should be avoided wherever possible because one role is involved in abstract and one in concrete concerns, and a single person usually can’t handle both and overlooks one. Moreover, sometimes, having a single person taking both roles may be a conflict of interest.

Documents

The following are the P4.express documents and the main contents of each:

• Program Description
  • Expected outcomes
  • Expected duration and cost
  • List of stakeholders and their reporting requirements
• Scenarios
  • Solutions that can enable the expected outcomes
  • The ways the outcomes can be sustained
  • The imagined responses of the environment and other assumptions
• Follow-Up Register
  • A description of ad hoc sources of action, such as issues and risks, along with their comments, actions, results, etc.
• Health Register
  • Results of peer reviews
  • Results of satisfaction evaluations
• Business Cases for projects under the program
  • Why this project?
  • Alternative options
  • High-level requirements
  • Expected outputs and their outcomes
  • Estimated investment (time, cost, etc.)
  • Execution strategy (done internally, outsourced, etc.)
  • Major risks
  • Major stakeholders

Remember not to collect data you don’t need and to keep the documents simple and purposeful. Furthermore, you also don’t have to use complicated software — you should start with simple tools and switch to more sophisticated ones only if you have good reason to.

About Business Cases, note that in OMIMO the Business Case of a project or program isn’t created inside it, but in the layer above, because it needs a perspective broader than the project or program it’s describing. So, in P4.express, you will create Business Cases for projects under it, but the Business Case of the program itself will be outside it, managed by a higher-level entity such as portfolio management.

Tailoring

As with other minimalist systems, it’s best not to tailor P4.express upfront. Instead, you should implement and use it as described in the manual and then customize it gradually, mainly in activity E03, in response to feedback collected from the environment and using careful trial and error.

History

The first private draft of P4.express was created in September 2025. The second private draft was published in May 2026, followed by its public draft in _____, and the final version in _____.