# micro.P3.express minimalist project management for micro projects [image] This is a downloadable version of the online manual, generated on 2026‑07‑02. This is the old version of the manual and has been replaced by a new major version, which is available on the website. micro.P3.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. 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 - Project Initiation - A1 – Identify the high-level decision maker(s) - A2 – Understand and distribute the hats - A3 – Select tools and create a project repository - A4 – Create a common understanding - A5 – Have Project Initiation peer-reviewed - A6 – Make a go/no-go decision - A7 – Conduct a focused communication - Weekly Initiation - C1 – Revise and refine the common understanding - C2 – Have the Weekly Initiation peer-reviewed - C3 – Make a go/no-go decision - C4 – Conduct a focused communication - Daily Management - D1 – Manage follow-up items - D2 – Close completed deliverables - Weekly Closure - E1 – Measure and report performance - E2 – Evaluate stakeholder satisfaction - E3 – Capture lessons and plan for improvements - E4 – Consider swapping hats for the week - Project Closure - F1 – Double-check and hand over the final output - F2 – Evaluate stakeholder satisfaction - F3 – Have the Project Closure peer-reviewed - F4 – Consider swapping hats for Post-Project Management - F5 – Archive the project documents - F6 – Celebrate! - F7 – Conduct a focused communication - Post-Project Management - G1 – Evaluate the benefits - G2 – Generate new ideas - G3 – Conduct a focused communication ## Introduction micro.P3.express is a flavor of P3.express designed for micro-projects with approximately 1 to 7 team members, which can be run in various environments, from mega- to micro‑organizations (including single-person ones). Similar to P3.express, micro.P3.express is a minimalist project management system. The diagram shows the micro.P3.express process. Each node (A1, A2, …) is a management activity. Each activity belongs to one of 6 activity groups (Project Initiation, Weekly Initiation, …). Two of the activity groups are one-time linear ones, while the others are cyclic. In the case of stretched micro-projects, which last for a long time and only consume a small portion of the team members’ time, you can replace the weekly cycle with a monthly cycle. You can click on each activity on the online diagram to open its page and read about it. If it’s your first time learning micro.P3.express, it’s best to start at A1 and read all of them in order. To be successful in your projects, you need to understand and continuously follow the Nearly Universal Principles of Projects (NUPP). ## A1 - Identify the high-level decision maker(s) [image] This is the first management activity in the Project Initiation activity group, which is a group for creating a foundation for the project and deciding whether you will execute it. It must be made clear who will make the high-level decisions such as the go/no-go ones (A6 and C3). The choice depends on whether the organization is larger than the project team: - If there’s no larger organization (it’s a micro-organization), then the whole team, or a subset of it, would be responsible for the high-level decisions. Remember that it must be clear to everyone who these people are. - If there’s a larger organization, a single person who has high organizational power and is not one of the normal team members should be the project sponsor, responsible for making high-level decisions and providing resources for the project. When more than one person needs to be involved in high-level decisions, it is the responsibility of the sponsor to make the arrangements, and the team members will only work with the sponsor rather than all the decision makers. ## A2 - Understand and distribute the hats [image] You don’t want the project work to be done by sending each specialist task to a department and them assigning it to their experts on an ad hoc basis. Instead, the necessary experts must be officially appointed as project team members, preferably for the whole duration of the project. There are four sets of concerns in any project. To make sure none of them is neglected, we consider the following hats for the team members, each representing one set of concerns: Project Manager Hat Concerned with the way of work, coordinating, facilitating, problem-solving, etc. Investor Hat Concerned with the return on investment and opportunity cost Creator Hat Concerned with the viability of the project's output, applicable standards, etc. User Hat Concerned with the needs and expectations of the customer and the end users While multiple people may share some or all of the concerns in any of these groups, only one person wears the hat at any one time. The hats do not give them more authority in making decisions, but merely the responsibility for ensuring those concerns are addressed by the team. When necessary, a single person can wear multiple hats (e.g., if it’s a single-person project). In such cases, the person should switch hats constantly without neglecting any of them. These four hats should be distributed at Project Initiation by considering the team members’ skills before proceeding to the next management activity, A3. ## A3 - Select tools and create a project repository [image] At this point, we need to set up the tools and a well-formed repository for storing the management and production documents of the project. Creator Hat Which tools should we use for creating the project output? What type of repository is best for the team members who create the output? Project Manager Hat Which tools should we use for the managerial work of the project? What type of repository will best meet the managerial needs of the project? How can users access documents from multiple devices? How can we have automated backups? How should we organize and name our documents? The repository can be a directory on a cloud storage platform or a local network that is synchronized and made available offline on team members’ computers. Alternatively, computer-savvy people can use Git and similar technologies to set up their repositories. Project Manager Hat Are we sure we're not locking ourselves into a service? When using cloud services, it’s important to make sure you’re not locked into their services and that you can remain free to move to other platforms and use alternative tools to open and edit files. Depending on the project, there may be other concerns as well: Project Manager Hat How do we ensure the security of the repository? What can we do about versioning (keeping copies of the old versions of files)? If the team is not sure what to do in this activity, they should seek help from colleagues or friends, or hire a short-term consultant. ## A4 - Create a common understanding [image] The person wearing the Project Manager hat helps all the team members to collaborate and reach a common understanding of the project. This understanding will serve as the foundation of future efforts and as a high-level plan that guides the way. Investor Hat What's the reason for doing this project? What are the benefits and disbenefits of the project? Approximately how much money do we need to finish the project? What are the investment risks? User Hat What are the expected results from the project's output? What are the customer and end-user needs and expectations? What are the risks related to users and the customer? Creator Hat What will the project's output look like behind the scenes? Approximately how much time do we need to create the project's output? What are the production risks? Project Manager Hat Who can impact the project (stakeholders)? What are the risks related to how we work? Have all the hat-wearers been involved in creating a common understanding? A digital or physical Integrated Project Board should be created to record the information, with status columns such as “queued”, “on-hold”, “in-progress”, “to-review”, and “closed” for the deliverables and follow-up items (risks, issues, etc.). In addition to the said status columns, there should be a “project description” column with the following meta-cards: - Why this project? - Requirements and expectations - Targets and forecasts - Stakeholders - General acceptance criteria [optional] [image] You should identify all the high-level and medium-level deliverables at this point to create a better understanding of the project. However, if the project is exploratory, it’s better to limit this activity to key, high-level deliverables and break them down later. In complicated micro-projects, you can use a Deliverables Map to facilitate the identification of deliverables. To do so, you can use a mind map to break down the final output of the project into its major deliverables, then each of those into smaller ones, and so on for a few levels deeper until you reach an appropriate level of detail for your project. There’s another important concern as well: Project Manager Hat Are the documents clear and easy to understand? ## A5 - Have Project Initiation peer-reviewed [image] A good Project Manager should always have a critical perspective: Project Manager Hat Have we done a good job in Project Initiation, and are we ready to move on? There may be errors or shortcomings that you’re missing for various reasons, including your proximity to the work. It’s a good idea to ask someone with project management expertise from outside the project team to be your peer reviewer and check what you’ve done with a fresh pair of eyes before moving on. Besides helping solve potential problems, peer review is a great way of learning for both sides. If the organization is not larger than the project team or there’s no one in the organization capable of peer-reviewing the management aspects of the project, you should consider asking an outsider to help you. The results of the peer review and any related information should be recorded on a card on the Integrated Project Board and closed after the necessary adjustments that were identified during the review have been made. Besides the Project Manager hat, other hat-wearers may find it useful to have peer reviews as well: Creator Hat Do we need a production peer review? Investor Hat Do we need a business peer review? User Hat Do we need someone to peer review the user aspects? ## A6 - Make a go/no-go decision [image] At this point, we’re almost ready for the go/no-go decision. Before asking the responsible person or group to make the decision, each hat-wearer should express their concerns: Project Manager Hat Do we have a proper, consistent understanding of and foundation for the project? Creator Hat Are the targets and expectations realistic and achievable? User Hat Is the existing definition of the project's output suitable for end users? Investor Hat Is the project goal achievable? Is the project justifiable? Is the project the best investment for us at this time? After this, the person or group responsible for the go/no-go decisions (set in A1) makes a decision. If the decision is no-go, the project repository should be archived and the project stopped. You should make sure the archive remains accessible, though, because you may come up with a similar idea in the future, and checking the work you’ve done on this idea would be helpful then. You may have to initiate multiple projects to end up with a few justifiable ones you want to execute. For this reason, the initiation of later-rejected projects shouldn’t be seen as wasted time but rather as an investment for finding the best projects. When there’s an external customer, this activity is when the proposal will be sent to them, and the contract will be signed. ## A7 - Conduct a focused communication [image] This is the last management activity in the Project Initiation group, required when the organization is larger than the project team. Project Manager Hat Does the rest of the organization know we're going to start this project? Everyone in the organization should be aware of the project so that they can align themselves with it and support it as needed. It also helps identify potential conflicts and opportunities at the earliest possible time. In this activity, the person wearing the Project Manager hat sends a short message to everyone in the organization, letting them know the project is going to start and explaining its goal and desired outcomes. ## C1 - Revise and refine the common understanding [image] This is the first management activity in the Weekly Initiation group. Each card on the Integrated Project Board should have a single team member assigned to it as its custodian, to follow up on it and update it on the board. When multiple people work on a single card, only one of them can be appointed as the custodian. At this point, custodians present their cards, and based on that and the meta-cards of the “project description” column of the board, the team refines the project’s common understanding by updating the cards and their sequence, deciding what to do in the upcoming week, detailing the upcoming work, etc. If a card has to be canceled, instead of removing it from the board, it should be marked as “canceled” and move it to the “closed” column, so that the board contains a full history. User Hat What are the most useful things we can do next for the end users and the customer? Creator Hat What are the best things to do next from a creator point of view? Investor Hat What can we do next to bring us closest to the project goal? Project Manager Hat If we have deviations, what should we do differently to meet the targets? Have all hats been involved in revising and refining the common understanding? The old and new deliverables and follow-up items (risks, issues, etc.) should be listed and sequenced on the Integrated Project Board. Each card should be assigned to someone as its custodian to follow up on. The meta-cards in the “project description” column of the board should be updated if there are any changes to the targets or other basic information they contain. [image] It’s helpful to add some information about the acceptance criteria to each deliverable card on the board to align the work with the goals and make D2 more straightforward. If there are codes, standards, or special requirements you have to consider for a specific deliverable, that information should be added to the card on the board as well. If deliverables have similar criteria, a “general acceptance criteria” meta-card could be created in the “project description” column of the Integrated Project Board to record them there instead of repeating them on every deliverable card. If a version of the project’s output is already in operation, it should also be examined: User Hat What is the reaction of the users to the existing state of the project output? Creator Hat How is the output performing in the real world from a creator perspective? Investor Hat What benefits have been realized so far? Based on these considerations, new cards may be added to the board, or the existing ones may be changed. There is also the usual concern: Project Manager Hat Are the documents clear and easy to understand? ## C2 - Have the Weekly Initiation peer-reviewed [image] It’s important to always remain critical: Project Manager Hat Have we initiated the week properly so that we're ready to move on? A person external to the team who has the required project management skills should be asked to spend an hour or so peer-reviewing your work. That information can then be used to refine the plans. If you have access to enough people, you should ask a different person to peer-review your work each time. This increases the diversity of opinions and enhances learning opportunities for everyone. If there’s no qualified person for peer review in your organization, you should consider finding an outsider to help you. The results of the peer review should be recorded on a card on the Integrated Project Board, which is then closed after the necessary adjustments have been made. Peer reviews are necessary for the management aspects. Depending on the type of project, you may want to use it for other hats as well, using the best practices and norms of each hat: Creator Hat Do we need a production peer review? Investor Hat Do we need a business peer review? User Hat Do we need someone to peer-review the user aspects? ## C3 - Make a go/no-go decision [image] It’s time for the cyclic go/no-go decision. Before making the decision, each hat-wearer expresses their concerns: Creator Hat Are the targets and expectations still realistic and achievable? User Hat Is the existing understanding of the project still suitable for end users? Is it still possible to meet the requirements? Investor Hat Is the project goal still achievable? Is the project still justifiable? Is the project still the best investment of our resources at this time? After this, the person or group responsible for the go/no-go decision (set in A1) makes a decision. The decision and its related information are recorded on a card on the Integrated Project Board. When a project loses its justification and it doesn’t make sense to continue it anymore, a no-go decision will be expected, in which case the team should archive the documents, stop the project, and announce its cancellation. If a project has a dynamic scope and the latest output seems to be enough, a no-go option shouldn’t be used to stop it, but you should review and close the remaining deliverable cards on the Integrated Project Board as canceled ones and proceed normally to tie up the loose ends and close the project. ## C4 - Conduct a focused communication [image] This is the end of the Weekly Initiation activity group. If the organization is larger than the project team, a focused communication may be necessary. Project Manager Hat Do we need to communicate the weekly plan to a broader audience? Since this is a weekly activity, you should make sure that the frequency of the communications matches the expectations of the stakeholders, and if needed, send them every two or four cycles instead, and send it only to certain people rather than everyone in the organization. ## D1 - Manage follow-up items [image] All team members should be continuously looking for issues, risks, changes, and improvement ideas. Creator Hat Are there any new issues, risks, or improvement ideas for the project output? Investor Hat Are there any new business issues, risks, or changes? User Hat Are there any new issues, risks, or changes related to end users or the customer? Project Manager Hat Are there any new issues, risks, or improvement ideas related to the way we work? Are we all actively identifying new risks, issues, and improvement ideas? This information should be captured by adding new follow-up cards onto the Integrated Project Board, or adding comments to existing cards. Project Manager Hat Are we properly following up on the identified issues and risks? To make sure nothing is neglected, a person should be assigned to each card on the Integrated Project Board as its custodian. The custodians follow up on those cards and update them. When a card is completed or canceled, they add the new information to the card and move it to the “to-review” column of the board. Then, the whole team or a subset of it reviews the card before moving it to the “closed” column. Project Manager Hat Are the documents clear and easy to understand? ## D2 - Close completed deliverables [image] Custodians add comments to their deliverable cards on the Integrated Project Board, and eventually, move them to the “to-review” column when they are completed. Then, it’s time to make sure each deliverable is really complete before moving it to the “closed” column, because we can only reduce risks and create a comfortable environment if what we call complete is really so, and we’re sure that not many of them will require extra work in the future. Creator Hat Is creating the deliverable really completed? Investor Hat Is the deliverable compatible with our goals? User Hat Is the deliverable compatible with user needs and expectations? When it’s agreed that everything is fine with the deliverable, it should be moved to the “closed” column. [image] If the project has an internal or external customer, it’s a good idea to show them the completed deliverables for feedback and an unofficial, preliminary approval. This will make Project Closure a lot easier and reduces the risk of rework. Project Manager Hat Are we working on too many deliverables at the same time? Having too many in-progress deliverables increases the risk of rework. Instead, we should focus on completing deliverables before moving on to new ones. The Project Manager hat is responsible for encouraging everyone to do so. Don’t forget the usual concern: Project Manager Hat Are the documents clear and easy to understand? ## E1 - Measure and report performance [image] This is the first management activity in the Weekly Closure group. We rarely progress as planned, which is fine as long as we check to see what each deviation means to the project and what we have to do about it. Investor Hat Are we getting closer to achieving the project goal? Creator Hat What's our guess about the way the rest of the project output will be created? User Hat What's our guess about the user aspects in the future? Are we satisfying the project requirements? Project Manager Hat What's our forecast for the completion of the project? There’s no simple, universal way of forecasting, and the person wearing the Project Manager hat should ensure that an appropriate method is used: one that is good enough for replanning or changing the targets in C1. New forecasts should be added to the “targets and forecasts” meta-card in the “project description” column of the Integrated Project Board. Project Manager Hat Does anyone outside the team need to be aware of our progress? If necessary, you should communicate the project performance with people outside the team, such as the customer and higher organizational levels. The reports should be kept simple and straightforward, and reviewed to decide whether it’s a good idea to send them every cycle, every two cycles, or in any other frequency. ## E2 - Evaluate stakeholder satisfaction [image] We need to have an implicit or explicit evaluation of the satisfaction of team members and external stakeholders. Project Manager Hat Are the team members happy with the way we're working on the project? Are the external stakeholders (if any) happy with the way we're working? It’s usually best to have a simple, anonymous evaluation for the team members every cycle. For external stakeholders, it’s important to ensure the frequency of evaluations is suitable for the audience, and if weekly evaluation is too frequent, it should be done every two or four weeks instead. It’s best to have at least one evaluation every month so that the problems don’t pile up. Make sure the evaluation doesn’t take too much time from the stakeholders. ## E3 - Capture lessons and plan for improvements [image] It’s a good idea to pause, reflect on the previous week, and see what you’ve learned from it that can help you have a better project next week. Project Manager Hat What can we do better next week regarding the way we work? Creator Hat What can we do better next week for creating the project output? Investor Hat What can we do better next week to move faster towards the project goal? User Hat What can we do better next week to address user needs and expectations? The improvement plans should be added to the Integrated Project Board, the sequence of cards revised, and a custodian appointed to each new card. We don’t wait for the end of the project to capture lessons learned, but rather capture the relevant information on the Integrated Project Board as comments on the cards, and those cards act as lessons learned when they are closed. However, it’s a good idea to look for extra lessons in this activity. Project Manager Hat Which closed cards on the Integrated Project Board contain significant lessons? Have we learned anything new that is not yet reflected on the board? If there are any missing lessons, they should be captured either as comments on existing relevant cards or as closed, standalone cards on the Integrated Project Board. All recently closed cards that contain a significant lesson should be marked to make it easier to find them in the future. ## E4 - Consider swapping hats for the week [image] This is the end of the Weekly Closure activity group, and we have one more thing to do. Project Manager Hat Can we increase collaboration by swapping the hats for next week? It’s usually helpful to redistribute the hats to increase team members involvement and collaboration and improve everyone’s understanding of the project. However, it’s not always possible or desirable. You need to add the new hat assignments to the “stakeholders” meta-card in the “project description” column of the Integrated Project Board. ## F1 - Double-check and hand over the final output [image] The first thing we need to do in the Project Closure activity group is double-check to ensure the final output of the project is complete and matches the expectations. Project Manager Hat Are all the cards on the Integrated Project Board closed? Creator Hat Is everything working the way it should from a production point of view? Investor Hat Have we achieved the project goal? Have we satisfied the business expectations? User Hat Have we satisfied the requirements and the users' needs and expectations? If we need to do more before ending the project, you should return to C1, and otherwise, to F2. [image] Sometimes, a limited set of unfinished cards on the board might be closed by transferring them to a maintenance team. In these cases, they should be marked as “transferred” and moved to the “closed” column. Creator Hat Do we need to prepare any additional information for the maintenance team? When there’s a customer, the following considerations are important: Project Manager Hat Do we need approval or an official handover before ending the project? Have we properly documented the closing approvals and similar documents? When working with external customers, it’s a good idea to document key communications for future reference. ## F2 - Evaluate stakeholder satisfaction [image] E2 provides continual evaluation of stakeholder satisfaction, but each of those evaluations is mainly focused on one cycle of the project. Therefore, we need to have an evaluation at the end as well to understand the overall satisfaction and use the information to aid with future projects. Project Manager Hat How satisfied are the internal and external stakeholders? You may need an anonymous evaluation to ensure people respond comfortably. The result should be recorded in the “stakeholder” meta-card on the “project description” column of the Integrated Project Board. ## F3 - Have the Project Closure peer-reviewed [image] As usual, it’s important to remain open and critical: Project Manager Hat Have we done everything properly to allow for project closure? You should ask a person external to the project team who’s skilled in project management to be your peer reviewer. You should check everything together, make adjustments where necessary, and record this information on a card on the Integrated Project Board. ## F4 - Consider swapping hats for Post-Project Management [image] If the organization is larger than the project team, a different group of people (e.g., the portfolio management team) may be responsible for Post-Project Management. If that’s not the case, the team members will stay responsible for that cycle, and its hats should be assigned in this activity. Project Manager Hat Who are the best people to wear each of the hats for Post-Project Management? The hat assignments should be recorded on the “stakeholder” meta-card in the “project description” column of the Integrated Project Board. ## F5 - Archive the project documents [image] The management and production documents generated in the project will be helpful in similar projects you may have in the future. For this reason, it’s important to make sure they stay accessible. Project Manager Hat What's the best way of archiving the documents? Are the files made read-only? How do I ensure that only authorized people will have access to the documents? Will the file formats remain accessible and usable in the future? Sometimes, the documents are so cryptic that only the writer can understand them for a few weeks after writing. Such documents can’t be helpful in the future, and that’s why it’s important for the person(s) wearing the Project Manager hat to continuously ensure that documents are clear and understandable. ## F6 - Celebrate! [image] At this point, you’re done with the project and it’s closed, which is a good time to celebrate! Project Manager Hat What's the best way of celebrating the completion of the project? Celebrating important events such as the completion of a project is helpful because people will feel appreciated, and as a result will perform better in future projects. It’s also a reminder that projects are not just a collection of random tasks, but rather goal-oriented endeavors, and everyone should contribute to their successful completion. ## F7 - Conduct a focused communication [image] This is the last activity in Project Closure, required when the organization is larger than the project team. Project Manager Hat Does the rest of the organization know that we've closed the project? The person wearing the Project Manager hat sends a short message to everyone in the organization, letting them know the project is closed. ## G1 - Evaluate the benefits [image] The Post-Project cycle usually repeats every 1 to 6 months for 1 to 5 years, depending on the type of project. In this cycle, we evaluate the benefits of the project’s output to take action and examine our original expectations and learn more. User Hat How are the users using the project's output? Creator Hat How did the project output perform from a production point of view? Investor Hat Did we achieve the project goal? What happened to the expected benefits and disbenefits? Did we have any unexpected benefits or disbenefits? Project Manager Hat Have all the hats been involved in this evaluation? Have we documented the result of the evaluation properly? The result is shared with others in G2 and G3. ## G2 - Generate new ideas [image] Based on G1, you know how the project’s output has performed. Now you can act on that information. User Hat Can we make any adjustments to the output to make it more suitable to its users? Can we target any new users for the output? Creator Hat Should we make any adjustments to improve the performance of the output? Can we make any new, useful outputs based on what is already done? Investor Hat Can we make adjustments to the output to increase its benefits? Inspired by this project, can we think of other beneficial projects? The ideas will be evaluated later and a Project Initiation held for those that seem more worthy of receiving a better evaluation followed by an educated go/no-go decision. Small adjustments can be applied outside the project structure as maintenance efforts. However, when possible, it’s best to package them as one or more micro-projects with specific goals. It’s possible to merge the G2 activity of multiple projects into one to take a more holistic view. Project Manager Hat Are we using proper facilitation techniques for generating new ideas? It’s possible to use various techniques, such as Delphi, to help generate better ideas. ## G3 - Conduct a focused communication [image] If there are stakeholders other than the hats involved in the post-project management cycle, we need to inform them of the results. Project Manager Hat Who should be informed of the results of the benefits evaluation? When the organization is larger than the project team, everyone in that organization should be informed of the results of the evaluation within the limits of confidentiality. This is a reminder for everyone of why we do the projects, which is helpful for on-going and future projects.