# P4.express The minimalist program management system [image] This is a downloadable version of the online manual, generated on 2026‑07‑02. Check the website for newer versions. P4.express comes from OMIMO (https://omimo.org/en/), which is a family of open, minimalist modules. This manual can be used and distributed freely under the Creative Commons Attribution 4.0 International license. 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. OMIMO is co-funded by the European Union. Views and opinions expressed are however those of OMIMO only and do not necessarily reflect those of the European Union or EPOS VZW. Neither the European Union nor the granting authority can be held responsible for them. ## Activity list The following are the management activities and their activity groups in P4.express: - Program Initiation - A01 – Appoint the sponsor - A02 – Appoint the program manager - A03 – Appoint the solution ideation team members - A04 – Identify stakeholders - A05 – Identify the expected outcomes - A06 – Name the program - A07 – Ideate Scenarios - A08 – Have Program Initiation peer-reviewed - A09 – Make a go/no-go decision - A10 – Conduct a focused communication - Monthly Initiation - B01 – Revise all Scenarios and refine the target Scenario - B02 – Have the monthly cycle peer-reviewed - B03 – Make a go/no-go decision - B04 – Kick off the Monthly Cycle - B05 – Conduct a focused communication - Weekly Management - C01 – Kick off the Weekly Cycle - C02 – Conduct a focused communication - Daily Management - D01 – Manage follow-up items - D02 – Start, end, or cancel projects - D03 – Balance resources - Monthly Closure - E01 – Measure and report performance - E02 – Evaluate stakeholder satisfaction - E03 – Plan improvements - Program Closure - F01 – Double-check and hand over the outputs - F02 – Evaluate stakeholder satisfaction - F03 – Have Program Closure peer-reviewed - F04 – Archive the documents - F05 – Celebrate! - F06 – Conduct a focused communication ## Introduction 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 _____. ## A01 - Appoint the sponsor [image] ### What The first management activity is to appoint a senior manager as the program sponsor. The sponsor is the highest role in the program, and the program manager reports to the sponsor. The sponsor is - accountable for the justification, outcomes, and benefits of the program; - responsible for making high-level decisions for the program; - responsible for making sure the program is properly funded and resourced; and - charged with leading the sponsors of projects under the program. In small programs, the program sponsor can also be the sponsor of the projects defined under it. However, if more people are available to the program or if it’s a larger program, it’s better to have other people as project sponsors, working under the supervision of the program sponsor, so that the program sponsor can focus on the higher-level aspects without distraction. In such cases, these people will be appointed throughout the program, as new projects are defined in the Monthly Initiation activities of the program and not during the Program Initiation activities. ### Why Having a program manager is not enough, and the sponsor’s role is necessary because - program managers have to be focused on collaboration, facilitation, conflict resolution, and other day-to-day work, which don’t leave them enough time and attention to direct the high-level aspects of the program. - program managers may not have enough organizational power to be able to get resources for the program, or to have enough strategic information to make high-level decisions for the program. ### Who Since the sponsor is the highest role in the program, they should be appointed from a higher position outside the program, such as the portfolio management system. When P5.express is used for portfolio management, the program sponsor must be a member of the portfolio board. That way, the sponsor is aware of all the investments in the organization and, therefore, capable of making better high-level decisions for the program. ### How The program sponsor must be a high-level manager in the organization, such as a director. This is necessary because their organizational power is necessary for getting resources for the program. Moreover, their high position in the organization provides them with the strategic information they need for the high-level decisions of the program. The sponsor should have a special interest in the program so that they can champion it in the organization. Usually, the sponsor manages a department or business area that has the most to do with the outcomes of the program, and that’s why they want to champion it. However, the sponsor should not hesitate to cancel the program if it becomes unjustifiable. When possible, it’s a good idea not to have a single person as the sponsor for all programs and projects in the organization because a healthy level of competition among sponsors can be helpful to all. Sponsors don’t have to spend a lot of time on the program, but they still need to be involved and dedicate some portion of their time to the program. ## A02 - Appoint the program manager [image] ### What Next, the sponsor discusses the program with potential program managers, and comes to an agreement with one of them. It’s important to have a program manager who believes in the objectives and constraints of the program. ### Why Each program has a centralized, high-level coordination system for the projects underneath it. The program manager is in the center of this centralized coordination. Removing the coordination function from a program would defeat the purpose; the only alternatives are having multiple program managers or splitting the function among all or many of the team members. Having more than one program manager in a single program would cause accountability problems. Distributing the coordination function among team members can be an option in small projects; for example, that’s how micro.P3.express works. However, it’s not an effective option for larger projects or for the high level of complication inherent in programs. ### Who The program manager has a great impact on the success of the program, and the sponsor is responsible for the success of the program, so the sponsor should have the authority to select the program manager. If someone else were to involve themselves in selecting the program manager, the authority of the sponsor would be undermined, and the chances of success are lower for a program with a weak sponsor. ### How Usually, each sponsor trusts a few program managers in the organization most and knows who to go to for each type of program. They may also know a few freelancer program managers that they have worked with before and can hire for their new program. Remember that knowing who to go to for any concern or problem is a sign of strong leadership, as defined in the Leader’s Behavior Compass. When there’s no one with experience as a program manager, someone with enough experience as a project manager might be able to fulfill the role well. While program management and project management have common aspects, they differ a lot in how the manager’s attention should be divided. On average, programs are more abstract, exploratory, and strategic than projects and require stronger stakeholder management than projects. In general, it’s a good idea for the relatively experienced project managers to start managing small and simple programs first before moving to sensitive programs. Regardless of that, project management experience is necessary for program managers because it makes their expectations of the underlying projects more realistic. A program manager must be an expert in coordination, facilitation, conflict resolution, and other leadership skills as well as the program management method (in our case, P4.express). Expertise in the subject of the program (e.g., technical aspects) is not necessary. In small programs, the program manager can become the manager of the projects that will be defined under it. However, when possible, it’s better to have other people as project managers, working under the supervision of the program manager, so that the program manager can focus on the program. The project managers will not be appointed during Program Initiation because you can’t be sure which projects will be needed during initiation. Instead, they will be appointed when a new project is defined during the Monthly Initiation of the program. The same person should not hold both the sponsor and the program manager roles because they may subconsciously focus on the program management activities and forget about the abstract responsibilities of a sponsor. In large and complicated programs, the program manager may need help in managing the program. In such cases, a team can be formed in this activity or during the Monthly Initiations. The program manager should be careful and not consider themself as the boss of the solution ideation team or the team of project managers working under the program, but rather as a facilitator and enabler. Being a micromanager is also very harmful to the role. ## A03 - Appoint the solution ideation team members [image] ### What At this point, you form a team of all the experts needed for ideating solutions for achieving the expected outcomes of the program. The program is not approved yet, and it may never be executed, but these appointments should be done formally, and the team must be available to work on the program if it’s approved later on. ### Why One of the main purposes of the Program Initiation is to evaluate the viability of and justification for the program, which will guide the decision as to whether it’s a good idea to invest in the program. This information is based on ideating solutions and designing them at a high level, which requires experts in the solution ideation team. If not performed well, some beneficial programs may be rejected, and some unjustifiable programs may be selected. Some may consider it a waste of time to work on a program that might not be executed. The program manager should ensure that everyone understands that this is, however, an important investment for the organization because it allows them to select the best programs to invest in. Even if it’s decided not to execute the program, their efforts are not wasted, as they saved the organization from investing its resources in an unjustifiable program. Similar to P3.express and micro.P3.express, P4.express doesn’t accept the common approach of one team initiating the program or project and another team executing it, because a team that will be responsible for executing it will be more realistic in its initiation. ### Who In general, members of the solution ideation team have a profound impact on the success of the program, and, therefore, no one outside the program may set up the team. The sponsor should have near-absolute authority over it, and they should trust and delegate the selection of the team members to the program manager. ### How Deciding who has to be in the team is not easy and needs an understanding of what’s involved in the potential solutions. For that reason, the program manager should start with a few obvious choices and then, using their help, discover other people who are also needed for the program. This process can be repeated a few times with the new team members until the team becomes capable enough. Later on, during Program Initiation or Monthly Initiations, as solutions are ideated, the need for more experts may be identified, and they can be added as required. Many programs (for example, organizational change programs) depend largely on the acceptance and support of their stakeholders. In such cases, people who feel that their needs are not considered properly will resist. Therefore, for the interests of each group of people, there should be at least one team member who’s completely aware of them and shares the information with the team. When possible, it’s best to even have representatives from each group of key stakeholders in the team. Sometimes, you might appoint a few people to the team mainly because being a team member makes them supporters of the program, whereas being left outside the team might make them opposers. This approach can be helpful, but you also have to ensure that you don’t have negative team members with destructive behaviors, and that you’re not making the team unnecessarily big. ## A04 - Identify stakeholders [image] ### What Some people or organizations may think, correctly or incorrectly, that their interests might be affected by the program in a positive or negative way. They might therefore want to have an impact on the program to protect their interests. Some of them may not have any power to impact you, but you or someone else may want to advocate for them for ethical or other reasons. All people and organizations with a potential for direct or indirect impact on the program are called stakeholders, and they must be managed carefully throughout the program. The first step in managing stakeholders is to identify who they are, which is not always simple. ### Why You should proactively identify stakeholders and consider what they want, because if you proceed with the program without such a consideration, they may cause problems eventually, and adapting the program later on is usually more costly and time-consuming. Moreover, some considerations such as preventing loss of life, protecting the environment, and protecting cultural heritage are ethical responsibilities in every program that require careful, early stakeholder identification. ### Who Identifying stakeholders is the first step in discovering solutions and needs the knowledge and experience of the solution ideation team. While they carry out this activity, the program manager helps them by facilitating and problem solving. The program manager should also ensure that this activity is done properly and that there’s a strong, useful list of stakeholders. ### How The solution ideation team members use their experience in similar programs to identify the stakeholders. The archives of past programs in the organization may also be helpful. The team or the program manager may also interview external experts for ideas. The identified stakeholders are a great resource for finding the missing ones. For this reason, when possible you should interview the stakeholders to see whether they can think of any other stakeholders you might have missed. Finally, in some programs, you might be able to make an announcement asking the public for their opinions, and include direct or indirect questions that can help you find the missing stakeholders. Asking the public is a great option for public programs because, besides offering you great information, it also helps create trust in your stakeholders. Make sure what you prepare as the list of stakeholders is a meaningful discovery of your program’s environment rather than a generic list of high-level players that would apply to most projects. There’s a section in the Program Description for the list of stakeholders. Add the list there. ## A05 - Identify the expected outcomes [image] ### What Programs are run to create outcomes. In this activity, you should identify the expected outcomes and list them in the Program Description. ### Why There’s a difference between the goal and the path towards reaching that goal. Uncertain environments only make the path unclear, not the goal. Because of the high level of uncertainty in programs, you shouldn’t lock yourself into a solution that’s fully designed upfront. However, that’s only about the solution; the goal, which is the set of expected outcomes, must be made clear as soon as possible so that you can align your activities with them. You may decide to adjust the expected outcomes later on, but the intention must be to create a complete and clear list of expected outcomes in this activity and use that until the end of the program. Listing expected outcomes may sound simple, but in reality, it’s very difficult and, therefore, requires an explicit activity that the team has to spend considerable time on. ### Who The solution ideation team identifies the expected outcomes under the supervision of the program manager. The program manager ensures, among other things, that the text that describes the expected outcomes is clear and easy to understand. ### How For some stakeholders, such as the customer, you’d interview their representatives to understand their expectations. Limiting interviews to a single representative or even a few similar ones can be risky as their interpretation of the expectations would be biased because of their own perspective. For this reason, you should try to interview different types of people. For some stakeholders, such as regulatory organizations, you might refer to their published codes and regulations instead of interviewing them. You may still have doubts after that stage, in which case, you may be able to contact them and ask for more information. The expectations of some stakeholders can be defined indirectly based on their historical actions. In general, when possible, you should use more than one method of identifying expectations to make sure you’re not misled. A common problem with many people, especially customers, is that instead of telling you about their expected outcomes, they describe the lack of what they understand as the “obvious” solution. In such cases, you have to ask good questions and gradually go deeper with them to identify the underlying outcomes they desire. For example, - “Make it easier to find old documents” is good because it describes the expected outcome; however, - “Change the current manual document management system into an AI-based one” is not good because it describes a single solution for achieving an implied outcome instead of describing the outcome and allowing the optimum solution to be discovered. If the predefined solution is a must, then what you have in hand is a project and not a program. There’s a difference between what people need and what they want. Aiming for what they want would generate short-term success for you, while aiming for what they need creates long-term success. Ideally, you should have enough conversations with stakeholders to close the gap between what they need and what they want. In other words, what they think they need should match what they really need. Don’t forget that some stakeholders may be passive and not tell you about their expectations unless you go to them and discover them or ask about them. However, if you don’t, they will stay quiet until the change happens, and if it doesn’t match their expectations, they will cause problems, and solving those problems late in the program may be expensive and time-consuming. So, you need to make sure you have a complete list of stakeholders in the Program Description and that you pay full attention to it when identifying expectations. Finally, when the real expectations are identified, you will probably discover many inconsistencies among them, and this would be the time to resolve those conflicts and create a consistent list of expected outcomes. The final output of this activity is a list of one or more expected outcomes. Normally, the number of related outcomes in a program would be less than ten. So if you have more, you should check to see whether they can be merged into a smaller number, or maybe they should be split into multiple programs if they are not too dependent on each other. The list of expected outcomes is added to the Program Description. ## A06 - Name the program [image] ### What This activity sets the name of the program or adjusts the existing one if it was set before by someone else. The new name will be used from this point on to refer to the program throughout the organization and possibly beyond. ### Why The name of a program can have a large impact on it. Often, programs are named after the “obvious” solution they might use to create the expected outcomes. However, that’s wrong and must be avoided because it limits your options. ### Who The name will be set by the program manager with help from the solution ideation team. ### How In activity A05, you will have gone deep into the outcomes expected from the program, and you will have distanced yourself from the implied solutions that some stakeholders may consider obvious. You can use that information and select a name that’s neutral enough and only refers to the expected outcomes without implying any solutions. Sometimes, selecting a truly neutral name is difficult or impossible. In that case, you can select an abstract or arbitrary name; for example, “Docs26” for a program that’s supposed to change something related to the way people work with documents in the organization and has started in 2026. ## A07 - Ideate Scenarios [image] ### What Projects are run to create tangible outputs, whereas programs are run to create abstract outcomes. The outcomes of a program are created by the outputs of one or more projects. The set of projects and their outputs that can potentially create all the desired outcomes along with a rough timeline for their execution is called a solution. The combination of a complete solution and its assumptions, including the imaginary behavior of the environment toward that solution, is called a Scenario. Your program must come up with multiple viable Scenarios and select the most promising one. That’s the purpose of this activity. ### Why On average, programs are a lot more uncertain than projects. In fact, many of the highly uncertain initiatives that are called “projects” are in fact programs mistaken for projects. Because of the higher level of uncertainty in programs, your plans must be more creative and adaptable. Ideating Scenarios is a practical alternative to more deterministic forms of planning. Besides keeping the plans more adaptable, you also need to have more than one viable Scenario, because after you start executing the program, you may receive signals that your selected Scenario won’t work well or may even lead you to a dead end, in which case, you should be ready to quickly switch to another viable Scenario. A big mistake in some programs is that they are started without any viable Scenarios, relying on the idea that there are a few obvious implementation steps that should be taken first anyway. Doing so causes major problems: - The first few steps they take may not fit any viable Scenarios. It may - cause serious problems for the status quo, and - make it more difficult to fix the situation in future programs. - Even when there are undiscovered, unanalyzed viable Scenarios for those steps, options become limited to those compatible with the steps taken. Better viable Scenarios may have become unviable as a result of taking those steps. If you really believe that a few initial steps are necessary, you must, at least subconsciously, be thinking about a few Scenarios that share those first steps. When this is so, all you have to do is to write down those Scenarios and check to see whether you’re missing any other viable Scenarios before taking the steps. ### Who The solution ideation team creates the Scenarios under supervision of the program manager. The program manager ensures, among other things, that the text of the Scenarios is clear and easy to understand. ### How The expected outcomes are identified in A05. In this activity, the team decides what types of outputs can create those outcomes and how those outputs can be created by different projects. Some of those would enable the outcomes, and some would sustain them. For example, to make it easier to find documents in the company, one Scenario might be as follows: We believe that sophisticated document management software is not necessary, and we can make it easier to find documents in the company if they are stored in a well-formed hierarchy of directories in our internal network. Project 1: So, our first project would be designing the structure of the directories. It should be done by carefully checking the historical and current documents. Four weeks is probably enough for it. Project 2: We’ll have another project to define a set of rules that can be followed to simplify how we use our documents. For example, a few years after a project is finished, we won’t need its source files anymore, and the PDF reports of the source files would be enough. By removing the files that won’t be needed anymore, it will become much easier to find the files we need. Four weeks should be enough for this project, and it can be done in parallel to project 1. Project 3: When the previous projects are finished, we can start cleaning up and then moving the old files into the new structure. Given the large number of files we have, we will probably need about 10 weeks for that. People who need to access files occasionally would probably find it easier after this change, but those who access the files frequently may be used to the old structure and feel some friction for a while. We should identify those people and work with them to make sure they are as comfortable as possible with the change. Project 4: We’re now ready, and we can migrate the files of all ongoing projects at this point. To make sure it won’t cause too much trouble, we’ll do it on a weekend and an extra day before or after that. During those 3 days, no one should work so that there’s no conflict. Not many people work on weekends anyway, but we must communicate it long before the date, so that everyone’s ready. Project 5: The first day after project 4, we’ll have training for all employees, followed by 2 weeks of one-to-one mentorship. Some people may not be present for the main training, so we may need to have a second training as well. Also, some people may not be open to the mentoring program because they are busy or just not in favor of the program. We should identify them, and if there’s anyone like that, we should find a solution for them. Activity: After project 5, to make sure people don’t forget how to use the new system, we’ll have weekly audits for 6 months. After that, we’ll switch to monthly audits for a year. After that, the program will be closed. There could be other Scenarios for the example above; for example, those that use different types of automation, those that use external consultants or outsource different parts of work, etc. Ensure that the Scenario is not too detailed, because programs must be adaptable and allow the details to emerge gradually based on what you learn from the environment. Remember that no program shall be started without at least one viable Scenario, though normally, it’s expected to have more than one viable Scenario. When more than one viable Scenario is ideated, the one that seems the most promising should be selected as the target Scenario. The target can switch from one viable Scenario to another during the program, and, at any given time, there must be one and only one viable Scenario marked as the target. The solution ideation team should consider both convention and innovation, and they should avoid superficial trends: - Conventions are useful because they provide you with tested solutions for common problems. - Innovations are useful because - the problem may be new, without a conventional solution, or - you may find a new solution for the old problem that was overlooked by everyone else. - Superficial trends are harmful because they are based on short-term hypes formed by a few people who want to make quick money at the expense of others. The solution ideation team should carefully examine the nature of program and its environment to decide between conventional and innovative solutions. In some programs, some viable Scenarios may be innovative and some conventional. ## A08 - Have Program Initiation peer-reviewed [image] ### What At this point, initiation is almost done, and it’s time to ask another program manager in your organization to help you by peer-reviewing your management activities. ### Why Sometimes, you make simple mistakes that might shock you when you find them, but you don’t find them because you’re too close to the work and they are too familiar to you. Having a new person review what you’ve done helps reduce this problem. Besides that, you may also make some mistakes because you don’t have the knowledge or experience to understand the mistake, and in those cases, the peer reviewer may catch those mistakes and also teach you why. No matter how experienced and knowledgeable the peer reviewer is, when they see your work, they may learn new things from you as well. Those two reasons are why it’s a great idea to have peer reviews. ### Who The program manager is responsible for making the arrangements for the peer review. ### How You’ll ask another program manager in your organization to sit with you and go over the Scenarios and other documents prepared to initiate the program. You’ll have a conversation and discuss different aspects of it. The overall result of the review goes to the Health Register, and if you want to make any changes based on the discussions, you can create follow-up items for them and add them to the Follow-Up Register. If there’s no other program manager in your organization, try to find someone else with similar knowledge to be your peer reviewer, or if there’s no confidentiality problem, use an external person as the peer reviewer. Getting help from people internal to the program or from the projects under it is not a good idea because it may create a conflict of interest for them. If possible, each time you should use a new peer reviewer to maximize the two advantages of peer reviews as described above. ## A09 - Make a go/no-go decision [image] ### What At this point, you’ve spent enough time exploring the idea of the program, tried to understand the real outcomes people expect from it (without missing anyone out), and used that to create one or more Scenarios. Now, it’s time to decide whether to execute the program. ### Why You want to make sure the program is viable and justifiable before you invest in it. The obvious reason is that you don’t want to lose your time and money. However, there’s another reason as well, which might be more important in numerous instances: A failed program can make it more difficult to have a similar program in the future. In other words, when dealing with something critical and sensitive, not doing anything at all might be much better than attempting to run a poorly initiated program. ### Who The program manager sends the documents to the sponsor, and the sponsor should make the decision. Often, the sponsor will have to discuss it with other people, such as those in the portfolio management system, and decide together. However, that’s up to the sponsor, and the program manager shouldn’t be worried about who should be included in the decision making. From the program’s perspective, there’s only one high-level decision maker, and that’s the sponsor. ### How The Scenarios you’ve developed create a range of time and money needed for the program. There may be a Business Case for the program at higher levels, such as portfolio management. In that case, they will use the data to update the Business Case and use that to assess the justification of the program by comparing its estimated investment and benefit. They will also check the Scenarios to see how viable the program is and compare its level of risk with the level they are willing to accept for the goal of the program. Finally, the decision will be made, and only after the sponsor formally communicates the decision to the program manager in writing may the program manager proceed to the next steps. If the decision is to execute the program, the program manager proceeds to A10, and otherwise they would archive the documents and release the team. Everyone in the organization must understand that initiating a program or project and deciding not to run it is not a failure but rather a sign of good management. There may be many ideas worth exploring (initiating), but it would not make sense to pursue all of them at that moment. You may decide to return to an idea a few years later or permanently reject it. ## A10 - Conduct a focused communication [image] ### What It’s time to tell everyone in the organization and some of the other stakeholders that the program is approved and about to be executed. ### Why In many organizations, projects and programs start and end with no clear indication, and most employees (and even managers) don’t know the range of projects and programs happening in the organization. In this way, many of the potential conflicts will stay hidden until it’s too late. It also causes everyone to be focused on their specialist activities without having a sense of the program as a whole and without being able to align themselves with the goals and collaborate properly with everyone else. The focused communication is an opportunity to avoid some of these issues by creating commitment and encouraging collaboration. ### Who The program manager is responsible for the focused communication. ### How You need to tell people what the program is, why it’s important to do it, and what the solution of the target Scenario is. You should keep the message as short and clear as possible for it to stay effective. The communication can be done via email. Sometimes, especially in larger and more critical programs, you can even have an event to announce the program. ## B01 - Revise all Scenarios and refine the target Scenario [image] ### What Based on what you’ve learned from the environment, revise all Scenarios to make them more realistic and ready to be followed if needed. Then, spend extra time on the target Scenario and make it more refined for the next few cycles. ### Why First, any type of plan must be continually updated to remain useful, and your viable Scenarios are no exception to that. Because of the high level of uncertainty in programs, it’s not realistic to detail everything upfront, but you should start with a high-level Scenario and keep adding more details to the target Scenario once a month. Besides the target Scenario, you must keep other Scenarios up to date as well. That’s necessary because you may have to switch Scenarios, not only because the target Scenario is not as good as you thought it would be, but also because one of the other viable Scenarios has become much better than you thought it would be — so much so that you prefer to put your target Scenario aside and switch to it. Such an opportunity exists only when you keep all your Scenarios up to date in this activity. ### Who The solution ideation team revises and refines the Scenarios under supervision from the program manager. ### How The solution ideation team goes through each Scenario and adjusts it based on the new realities they are in. This includes - their increased understanding of the environment; and - changes to the environment because of - what’s done in the program following its target Scenario; and - any other external changes to the environment. The idea is that each Scenario should be ready to take over the program from the target Scenario. The performance information from the projects that are ongoing under the program is an important source of updates for the Scenarios. For the target Scenario, you should add details for the next cycle or the next few cycles. It should not be too detailed, though, because it’s up to the projects to make their part more detailed. The appropriate level of detail at the program level is one that helps the teams initiate projects and judge the viability and justification of the target Scenario. For projects that you’re supposed to initiate during the month, a Business Case should be prepared beforehand in this activity. You should also appoint the sponsor of the project in this activity. ## B02 - Have the monthly cycle peer-reviewed [image] ### What At this point, the plans are updated, and you’re ready to move on. But before that, you want to make sure there are no mistakes, using the help of a peer reviewer. ### Why Similar to the peer review during Program Initiation, it helps discover problems that might otherwise be hidden, and it’s also a great way for the program managers to learn from each other. ### Who The program manager selects the peer reviewer and goes through the process with them. ### How The two peers sit together, go through and discuss the Follow-Up Register, Scenarios, and other documents. At the end, the program manager saves the result of the review in the Health Register, and if some adjustments are necessary, they will open follow-up items for them in the Follow-Up Register. If possible, it’s best for the program manager to find a new peer reviewer each time, as this helps optimize the two advantages of peer reviews mentioned above. ## B03 - Make a go/no-go decision [image] ### What At this point, the sponsor has to decide whether to continue the program based on the updated Scenarios. ### Why A program that was justifiable at the beginning may lose its justification after a while. Instead of pouring more resources into it, the sponsor must stop it. ### Who This decision is the responsibility of the sponsor. Other people may be involved behind the scenes, but for the program, everything goes through the sponsor. ### How The program manager provides all the information to the sponsor and waits for their decision. When there’s a Business Case for the program at higher levels such as portfolio management, the sponsor would use the data related to the updated Scenarios, and especially the range of time and money needed for them, to update the Business Case. Having updated forecasts for investment and benefits, it’s possible to judge whether to continue the program. The sponsor may have to discuss the justification of the program with others, such as the portfolio management board. When the decision is made, the sponsor will inform the program manager. Sometimes, the program may be justifiable, but better opportunities may arise, and the organization may cancel the program to pursue them instead. That’s why it’s important for the go/no-go decisions to be led by a high-level entity such as the portfolio management board, which monitors and directs all programs and projects. If the decision is to stop the program, the Program Closure activities will be activated. ## B04 - Kick off the Monthly Cycle [image] ### What When you get the approval in B03, it’s time to have a kickoff meeting for the monthly cycle with the solution ideation team and sponsors and managers of the projects under the program. ### Why The audience for this activity will have already been informed of what’s going to happen in the upcoming month, but you’ll have a kickoff meeting to review it and make sure that everyone is aligned. This is especially important for the sponsors and managers of underlying projects who might become too focused on their project and forget that it’s there to serve a larger program. Besides exchanging information, this meeting can also be used for team building. Simple, indirect team building will make the communication and coordination of these people easier during the month. ### Who The kickoff meeting is organized and facilitated by the program manager. In large programs where there’s a team to help the program manager, those people will drive most of the tasks in this activity. ### How Bringing people together for an in-person kickoff meeting is ideal. If that’s not possible or easy, a carefully planned and organized online meeting can work. Review the target Scenario and the role different stakeholders will play in it. Don’t limit the kickoff to boring speeches and a review of the upcoming month, but instead, create a pleasant experience for everyone, as the team-building aspect of this meeting has priority. ## B05 - Conduct a focused communication [image] ### What Send a message to the relevant stakeholders and tell them about the expected achievements in the upcoming month and the risks involved. It’s important to let everyone know their role in the overall achievements of the program. ### Why The main goal is to make sure that people involved in the program remain aligned with the overall goals and do not limit their contributions to isolated specialist activities. ### Who The program manager is responsible for this focused communication. ### How Email is a suitable option for this focused communication. Keep the message short and clear to increase its effectiveness. Make sure you include a description of the target Scenario’s solutions that will be active in the upcoming month. The relevant stakeholders for this focused communication are the solution ideation team, the sponsors and managers of projects underneath the program, and key external stakeholders. ## C01 - Kick off the Weekly Cycle [image] ### What Have a workshop with the solution ideation team and the managers of projects under the program and review what’s going to happen in the upcoming week and the interfaces and potential conflicts among projects. ### Why Projects defined in a program are related, but their dependencies should be minimized. Nevertheless, there are always some dependencies, and it’s necessary to have frequent meetings like this to avoid conflicts and rework. ### Who The program manager is responsible for organizing and facilitating this kickoff meeting, and the solution ideation team members and project managers are responsible for active participation. ### How Each project manager explains what they are going to do in the upcoming week according to the target Scenario and the relatively detailed plans of their projects, and other participants ask questions if needed to discuss potential conflicts and misunderstandings. Since this meeting should take place once a week and project managers and other participants have many other weekly activities as well, it’s important to keep it short and to the point. Avoid discussing unrelated topics such as progress, and if a risk is identified in the discussions, record it in the Follow-Up Register and return to the main topic. ## C02 - Conduct a focused communication [image] ### What Send an email to all relevant stakeholders and explain what’s going to happen in the upcoming week. ### Why This focused communication has the same purpose as the weekly kickoff meeting but with a different method of communication and a potentially larger audience, so that you make sure that the interfaces are not overlooked and potential misunderstandings are discovered and resolved as soon as possible. ### Who The program manager is responsible for sending this focused communication. ### How Communicate what’s going to be done in the upcoming week based on the target Scenario and the relatively detailed plans of the ongoing projects. Make sure the communication is short and straightforward because it’s weekly and it shouldn’t take too much time from its audience. If there are too many weekly focused communications from the projects under the program, you can merge them into this activity and have a single communication instead. ## D01 - Manage follow-up items [image] ### What This activity is for the daily management of risks, issues, and other ad hoc sources of action at the program level: everything that has been captured in the Follow-Up Register. Each item’s custodian follows up on the item until it’s closed. ### Why The main goal is to respond to risks, issues, and other ad hoc sources of action proactively rather than letting them be resolved automatically. Doing so will give you control and the possibility of getting better results. Relying on your memory or on unstructured notes takes too much mental energy and runs the risk of forgetting items. That’s why it’s best to have a simple register and the self-discipline to record items as soon as they are identified. It takes too much time and energy to manage all the items, which is why you need to assign custodians. In addition to spreading the work, it also helps align everyone with the same goal. ### Who The program manager is responsible for creating new items in the Follow-Up Register, but everyone should help identify the items. Each item in the Follow-Up Register should have a custodian to follow up on it and update the item. The custodian must be one of the solution ideation team members or one of the project managers working in the program. The program manager supervises the process to ensure that custodians are fulfilling their responsibility well. Each item in the Follow-Up Register has zero or more actions. Each action can have one or more people responsible for doing it. Note that the custodian is only responsible for following up and reporting. ### How There’s a Follow-Up Register at the program level for items that impact more than one project. Each project has its own register as well, for items that only impact that project. Finally, if there’s a portfolio management system, they may have a register for items that impact more than one program or standalone project. Based on the scope of impact of the item you’ve discovered, you should record it in your own register or send it to the layer below or above. Potential dependencies among projects are examples of follow-up items that should be managed in an integrated way in this activity. The program manager should ensure that all project managers check the program’s and portfolio’s Follow-Up Registers alongside their local Follow-Up Register. You should record new items immediately to ensure you won’t forget about them. You don’t have to plan the item immediately after adding it to the register, though – you can come back to the register at appropriate intervals to plan the new items with the help of your team. Make sure the item explains the impact of the item on the target Scenario and other viable Scenarios, and gradually add actions to it to bring it under control. A key step in planning a new item is to assign one of the solution ideation team members or one of the project managers working in the program as its custodian. Then, the custodian will be responsible for continually adding comments to the item to reflect the new information. They should also follow up on the actions to make sure they are done. The following is an example of a simple follow-up item: Potential war between X and Y Custodian: Celes ------------------------------------------------------------------------ 2026-02-05, Description: There’s been a conflict between X and Y, and some predict that those two countries might start a war. If it happens, it would probably increase the price of most materials we have to buy for the project. Since we have a fixed-price contract, the customer won’t compensate us for that, and we might run into financial difficulties. 2026-02-08, Action: A good option for us is to buy all the material right now. Tiam will estimate how much we have to pay to buy all the materials and how much it will cost to store them safely for the duration of the project. Zia will check to see how quickly we can get the money from the procurement department to buy them. 2026-02-09, Comment: In our contract, we’ve charged the customer 1,200 units for the material. If we buy them in bulk, upfront, it would cost us 1,050, but we’ll have to pay about 250 for the safe storage of them. If we don’t do anything and the war starts, our cost would be between 1,200 and 3,000. We’re still waiting to get information about our budget. 2026-02-11, Comment + Action: The sponsor talked to the company, and the best they can do is to give us 400 units in the next few weeks! Let’s see if the customer can pay some of the contract price in advance to help us with this case. Casey will do that. 2026-02-15, Comment + Action: The customer agreed to pay the 650 units we need in advance, so Karabo can now start buying all the materials for us! 2026-02-27, Comment: The procurement is complete. It has cost us 1,100 to buy all the materials. We also set up local storage on the site which cost us 150 units. Item closed. You should use the expertise of the solution ideation team and the program’s project managers to design proactive actions for the follow-up items. The goal is to close each item as soon as possible. An item can be closed in one of the following ways: - Completed: It’s okay now; you either took care of it or it’s no longer applicable. - Canceled: You’ve realized that it’s not a real concern, and, therefore, you don’t have to do anything about it. - Transferred: At the end of the program, the item has been transferred to someone else to take care of. Normally, OMIMO’s Follow-Up Registers are created in flow boards (also known as Kanban boards). ## D02 - Start, end, or cancel projects [image] ### What Each program has multiple projects under it. Those projects start based on the target Scenario and hopefully end as expected. Rather than the normal ending, some projects may be canceled. These major events can happen any day during the cycle. The cyclic go/no-go decisions of projects will be indirectly responded to by this activity. ### Why The program’s projects are defined to help achieve the expected outcomes of the program and, therefore, should be completely aligned with the end goal. This is key, especially because programs have a high level of uncertainty and cannot be run by a plan that’s fully defined and frozen upfront. Instead, they should be closely monitored and adjusted as needed. ### Who The decision to start the project should be taken by the project sponsor, program sponsor, and program manager. The other decisions will be made by the project sponsor and program manager, and the program sponsor will be involved only if there are doubts or if the impact of the decision is too high. ### How Each project should be initiated by creating a simple team and a common understanding (usually a high-level plan). Toward the end of project initiation, there should be a go/no-go decision. After that, there should be frequent go/no-go decisions as well (e.g., every month). Finally, the last decision is to end the project when it’s complete. All these decisions will be made in this program activity. To make the decision, the Business Case of the project will be updated based on its latest forecasts of investment and benefit. The impact of the update will be evaluated according to the target Scenario. If the update is too different from the Scenario and difficult to evaluate, the monthly cycle will be run to replan everything. Don’t keep projects that are nearly done open for long, but try to conclude and close them as soon as possible. In general, it’s best to limit the number of projects that are run simultaneously in order to simplify their management and increase predictability. ## D03 - Balance resources [image] ### What This activity helps project sponsors obtain resources for their projects, especially when there’s competition among them. ### Why The program management system should offer this help to project sponsors from a holistic perspective to ensure that - they can get the resources required for their projects, and - if multiple projects are competing for similar resources, allocations are optimized for the overall goals of the program. ### Who The program manager is responsible for balancing resources within their program, but when there are doubts or when the impact is significant, they should escalate the decision to the program sponsor. ### How Resources should be balanced based on the priorities implied in the target Scenario as well as the practical concerns in each project. The program manager should listen to what the project sponsors have to say and then make the decision. The program manager should not be influenced by anything except optimization of the program, and, for example, not decide based on which sponsor is the loudest when requiring resources. ## E01 - Measure and report performance [image] ### What Evaluate how much closer you’ve come to achieving all the expected outcomes and what it takes to enable and sustain the remaining outcomes. Based on the data, prepare one or more types of reports for the sponsor and other stakeholders. ### Why There are two concerns that should be addressed here. First, you must confirm that the program is still viable and you can be reasonably certain that you can achieve the expected results. Second, you have to forecast the time and money needed to enable and sustain the remaining outcomes, because there’s a limit to the investment the stakeholder will accept for the outcomes. Reporting is key: Most stakeholders are more supportive when they are kept informed. Furthermore, there may be conflicts or overlooked opportunities, and timely reporting to stakeholders may help you identify those. ### Who The program manager is responsible for measuring and reporting the performance of the program. The measurement is based on the performance information provided by the project managers, and the program manager should ensure that the information is reliable. ### How First, the program manager receives the performance measurements of all projects from their managers. If projects don’t have a frequent measurement and reporting activity, it should be added to them. Next, the program manager uses that data and the target Scenario to forecast the time and money required to finish the program. The measurement method can depend on the type of program, and it’s not fully deterministic but should be adjusted by the opinion of the expert program manager. Consider the optimal level of accuracy and precision for the measurements, and don’t go above those levels so that your energy is not wasted and you don’t create the illusion of control. When forecasting the required investment, it’s important to consider the effort required for enabling the expected outcomes as well as the effort required for sustaining those outcomes. The latter is sometimes overlooked. You should be focused on measuring things that contribute to your forecasts. Wrong measurements waste your energy, but more importantly, they may be harmful, as people involved in the program align themselves with the measurements, and wrong measurements could mislead them. You may need to prepare more than one type of report for different types of stakeholders. The content and format of these reports vary; some might be sent every time this activity is run, while some would be sent less frequently (e.g., every fourth time this activity is run). In general, simpler reports are more effective. You should document the reporting requirements of stakeholders in the stakeholders list of the Program Description. ## E02 - Evaluate stakeholder satisfaction [image] ### What Send short anonymous questionnaires to relevant stakeholders to evaluate their satisfaction with the program during the month. ### Why It’s crucial to have frequent satisfaction evaluations to find out about problems and solve them as soon as possible, rather than waiting for undesirable results in the future, because it’s usually easier, faster, and cheaper to solve them sooner. It’s important to keep the evaluation anonymous, as otherwise, some people may not be comfortable expressing their true feelings about the program. ### Who It’s the responsibility of the program manager to evaluate stakeholder satisfaction. ### How The internal and key external stakeholders should be evaluated. The internal stakeholders are the solution ideation team and sponsors and project managers who work in the program. The key external stakeholders depend on the type of program and should be decided on a case-by-case basis. The decision on which stakeholders should be included in satisfaction evaluations should be documented in the stakeholders section of the Program Description. Usually, more than one type of evaluation is needed for different groups of stakeholders. You can use privacy-friendly, anonymous online forms for collecting the data. Make sure the forms are short and simple so that all or at least most stakeholders participate. The internal stakeholders must be evaluated in every cycle. However, it may be too frequent for some external stakeholders. If so, you can decide to evaluate some groups every two, three, or four times this activity is run. Document this decision in the stakeholders section of the Program Description. Compare the evaluated satisfactions with the satisfactions assumed in the Scenarios and make adjustments to Scenarios to make them more realistic if needed. Record the result of the satisfaction evaluations in the Health Register. ## E03 - Plan improvements [image] ### What In this activity, you use all the information and especially the satisfaction evaluations to decide how you can manage the program better in the next cycle. ### Why The way you use P4.express should match your environment. However, minimalist methodologies, such as P4.express, don’t need to be tailored upfront, but it’s best to tailor them gradually and based on feedback. This activity is where you gradually decide how to tailor the method. ### Who The program manager is responsible for carrying out this activity. ### How Have a workshop with the solution ideation team and project managers who work in the program. Provide them with the results of the satisfaction evaluation and performance measurements, and facilitate a session for them to come up with and suggest improvements. Record the improvement plans in the Follow-Up Register and appoint custodians to them. ## F01 - Double-check and hand over the outputs [image] ### What In this activity, you double check that all project outputs are as expected and all the follow-up items are closed, and then you’ll hand over the outputs to the internal or external customer. If the program is canceled, this activity may or may not be required. ### Why The goal is to have an official handover and approval, which is a prerequisite for complete closure of the program. Remember that having programs that are almost done but are frozen in their last stages is a waste of resources and complicates your portfolio management. It’s best to close things and move on to new endeavors. ### Who The program manager and custodians are responsible for making sure that all follow-up items are closed. The program manager is responsible for the handover of the outputs. ### How When a project inside the program is finished, its project manager will hand over its outputs to the program manager in D02. The program manager checks the scope and quality of the output with the help of specialists in the solution ideation team, and if everything is fine, approves and accepts the output. Some programs collect all the outputs and wait for the end of the program to transfer them to their final owners. However, in some programs, it may be necessary or beneficial to transfer some or all the outputs as soon as they are ready and not wait for the end of the program. The disadvantage of doing so is that it limits access to the output, which may cause friction for other projects in the program. The advantage is that it may allow the owners to start operating the output and generate benefits, as well as realistic feedback. To make sure all outputs are ready to be transferred, you should not have any open items in your Follow-Up Register. All items should be closed, which means they should be completed, canceled, or transferred. The “transferred” status is specifically for this activity: There may be a few remaining works, and waiting for them to finish may make the program too long. If possible, the remaining works will be listed and transferred to an operations team, and then the program can be closed. At the end, update the active Scenario to reflect the latest facts in it. In that way, it will be more useful as a source of inspiration for future programs. ## F02 - Evaluate stakeholder satisfaction [image] ### What Send short anonymous questionnaires to relevant stakeholders to evaluate their satisfaction with the whole program. ### Why At this time, not much can be done to improve stakeholder satisfaction, and the main purpose of the evaluation is to have it on record for further analysis of the program and to generate lessons learned for future use. ### Who It’s the responsibility of the program manager to evaluate stakeholder satisfaction. ### How Online forms are usually a practical option for sending the questionnaire, but depending on the audience, you can use paper-based questionnaires as well. You may need to have more than one type of questionnaire for different groups. In general, ensure you’re designing the questions very well so that you can make the best use of this opportunity. Keeping the questionnaire short usually helps, although, since it’s the end of the program, it can be longer than the monthly questionnaires. Store the result in the Health Register and make sure it’s reflected in the target Scenario as well. ## F03 - Have Program Closure peer-reviewed [image] ### What Ask another program manager or program management expert in your organization to review your management activities to make sure everything is OK. ### Why This peer review is done for two main reasons: - To make sure you’re ready to end this activity group and the program as a whole, and that there are no serious mistakes. - To generate useful information you can use to improve your organization-wide program management system as well as allowing the two program managers to learn from each other. ### Who It’s the responsibility of the program manager to find the peer reviewer, make the arrangements, and conduct the session. ### How The program manager and the peer spend some time together going through program documents and making sure everything is fine; e.g., the target Scenario is updated with the latest facts and there are no open items in the Follow-Up Register. Store the overall result in the Health Register. If there are any adjustments you want to make, create items for them in the Follow-Up Register. ## F04 - Archive the documents [image] ### What Now that you’re approaching the end of the program, it’s time to archive all program documents for the future. ### Why The program documents contain invaluable information that can be very helpful in future programs and projects, but only if the documents are accessible when needed. ### Who The program manager is responsible for archiving the documents. ### How Normally, files should be well structured, but if any files are misplaced or named incorrectly, they should be fixed. For files that use a proprietary format, it’s a good idea to also create a copy of them in an open or common format that is certain to be available in the future. If some data is hosted in a Web application, export it in an accessible format and save it in the program’s directory. Finally, make sure the files are made read-only and there’s an effective backup system to protect them. Ensure that only authorized people can access the files, especially if some files contain confidential information. A common problem with documents is that the text is not clear and only people who are actively working with the documents can understand them at the right time and in the right context. During the program, you should ensure that all documents are clear and simple, such that anyone who is unfamiliar with the exact context of the program can understand them. This strategy also helps you during long programs, as it’s very common for internal stakeholders to have difficulty understanding their own documents after a few months. ## F05 - Celebrate! [image] ### What Now, it’s time to have a celebration for the team members or for the whole organization. ### Why This is an investment for future programs, as it reminds people that they are all working toward the same goal. ### Who The program manager organizes and facilitates the event. ### How The celebration can range from a simple gathering of team members in the company with a cake all the way to a fancy event in a venue with great catering and family members and external stakeholders present. The choice depends on how large and important the program was and how much the organization wants to invest in its future. Regardless, make sure it’s a memorable and enjoyable event and not just a boring corporate event with long rambling speeches. ## F06 - Conduct a focused communication [image] ### What This is the time to send a message to everyone in the organization, letting them know that the program has finished. ### Why There are two purposes for this management activity: - It shows appreciation for the team members, which encourages them for future programs. - It lets everyone know that the program is finished, which is a reminder that they should know what’s going on in the organization and align themselves with it. ### Who Since this is the last activity of the program, it’s the responsibility of the sponsor to send this communication. That makes it possible for the sponsor to thank the program manager as well as the other people involved in the program. ### How Keep the message short and clear. If the program was canceled or if it wasn’t successful, make sure that your message is positive and encourages people to look forward to better programs in the future. The team will be released at the end of this activity.