When we have all the key roles in place, we start populating the PMIS, which is a form of high-level planning. At the end of this activity, we will know if the project is feasible and worth investing. This study can be done on one option (usually when the project belongs to external customers), or using multiple options (usually for internal projects) that ends with selecting the best one.

The Project Manager leads and facilitated planning, and gets a lot of help from everyone else. It’s best to do it in a workshop with all key team members available, instead of interviewing them separately.

This is how you can populate the PMIS:

1. Prepare the Configuration Map: this is a hierarchical breakdown of the building blocks of the project, prepared as a mind-map. The Project Manager or PM Support conducts a facilitated workshop with all or enough team members, and they create the mind-map together. It might be required to bring in informed external people to help with this (e.g. other Project Managers from similar projects).
2. Create the Project Files Directory: the Project Files Directory structure is the same as the Configuration Map, possibly with fewer levels. It can be a series of nested folders in a file system, or container structure in a document management system. This structure will be used to store all the technical and administrative files in the project.
3. Update and reformat the Project Summary: the Project Summary is first created by the Sponsor, with limited pieces of information. In this point, the Project Manager uses the template to rebuild the document, and also adds the extra information.
4. Identify risks and store them in the RIC Register: in this stage, you can focus only on high-level risks (both threats and opportunities). This should be done in a facilitated workshop similar to the one used for preparing the Configuration Map.
5. Plan responses to risks and capture them in the RIC Register: plan the identified risks, as it might change the path of the project. This can be done in another facilitated workshops.
6. Prepare a high-level Schedule Model: use a facilitated workshop with all team members to identify high-level activities, their dependencies, and duration.
7. Add planned values to the Progress Register: first baseline the Schedule Model in the planning software, and then copy the high-level planned values to the Progress Register.
8. Prepare the Business Case: the Sponsor should be involved in preparing the Business Case, while everyone else collaborates by providing the necessary information.

You may need to repeat some of these steps; e.g. identify more risks when you’ve scheduled the project.

If a feasibility study has not been done before, it will be entirely covered using the steps discussed in this activity. The main element that helps you check the feasibility is the Business Case. However, you may need to check multiple options before finalizing your decision about the feasibility of the project.

Normally, we expect alternative options to be evaluated in the program or portfolio management system and only the selected solution be considered here. However, if you’re still considering multiple solutions, you need to plan them separately using the steps here, and then use the generated information (specially the Business Case) to see which option is the best.

Configuration Map

The Configuration Map is a hierarchical breakdown of the product, created as a mind-map. It helps you understand what the project is supposed to produce, and will also help you prepare the Schedule Model and organize the Project Files Directory.

The highest level of the mind-map is the final product of the project. Then you break it down into its main functional parts, and each part into smaller building elements. You also need to add acceptance criteria of each node as a comment.

Notes:

• The Configuration is almost the same as a well-formed WBS (Work Breakdown Structure), or a Product Breakdown Structure.
• You may have the temptation to ignore creating a mind-map of the configuration and directly create it as a WBS in the scheduling software. This is unacceptable in P3.express, as using the scheduling software for this purpose will generate an activity-based point of view.
• All elements of the Configuration Map must have a unique name.
• Use product-based names for the Configuration Map elements, rather than activity-based names (e.g. “Doors on the second floor”, instead of “Installing doors on the second floor”).
• In case of external projects, remember that this is only the configuration of your responsibilities in the project, rather than everything the customer needs for the project. They may ask for your help to create a wider configuration for the whole project, but that’s their concept and is not part of the management documents in your PMIS.
• All nodes in the Configuration Map have some information about their acceptance criteria. This information can be added to the elements gradually, instead of at this point.
• It’s helpful if you add comments to the items in the lowest level of the Configuration Map, and explain their scope.

Project Files Directory

The project files should be organized, to make sure everyone is using the latest version of all files, the history of revisions is not lost, it’s easy to search for and find specific files or groups of files (e.g. the latest version of all structural designs in the project), and finally, that you can use them as references in your future projects.

There are two major ways of organizing the project files, and creating the “Project Files Directory”:

• In a file system, on the cloud (Google Drive, Dropbox, OneDrive, etc.), or in your own intranet/server
• In a document management system hosted on the cloud, or in your own servers

We discourage using personal computers for saving the Project Files Directory, as they won’t be accessible to everyone. Most cloud-based file systems (e.g. Google Drive) allow you to have a synchronized copy on your computer, while there’s also a centralized copy.

No matter how you manage your files, they MUST be organized based on the Configuration Map of the project. In case of using a simple file system, you should create a hierarchy of folders based on the Configuration Map, and use it to store files. There’s always one folder for the whole project, using the name of the project. Then there are two folders, one called “Project Management”, that contains the rest of the PMIS elements, and a “Product” folder that will contain the Configuration Map elements.

RIC Register

The RIC Register is a list of all notable risks, issues, and change requests you’ve identified in the project, with their planned responses, and historical information. The goal is to document each item as soon as it’s identified, and follow up on it until it is closed, with a proactive approach.

Schedule Model

The Schedule Model is simulated model of how your project activities can be executed, based on their dependencies. There’s only one Schedule Model for the project, while more detail is added to it every Cycle.

The WBS of the Schedule Model is based on the Configuration Map. More detailed activities are added gradually, at each Cycle, instead of all at the beginning.

There are two main purposes for having a Schedule Model:

• It tells you what to do next, based on dependencies, to maximize the chances of meeting the project targets
• It helps you evaluate the current state of your project, measure deviations, and then plan for recovering them and consequently, deliver the project on time and budget (or as close as possible)

Scheduling rules:

• Activities should have unique names, to prevent problem and confusion.
• Activity names should have a verb (or a similar element); for example “install doors in the second floor” instead of “second floor doors”.
• Each activity should have at least one FS or SS predecessor, to let its start be affected by the network. The starting activity/milestone is an exception.
• Each activity should have at least one FS or FF successor, to let its finish affect the network. The ending activity/milestone is an exception.
• At least 90% of the dependencies should be FS, as it’s the closest model to the real world dependencies.
• Avoid SF relationships as much as possible, as there’s usually no real-world example of it.
• Don’t use dependency lags and leads longer than 50% of the duration of the predecessor and successor
• Date constraints that prevent activities from moving to later dates should not be used, as they destroy the dynamic nature of the model.
• Check activities with long floats for missing dependencies.

Note:

• The Schedule Model is a dynamic concept based on the dependencies among elements, rather than a static list of dates that are never updates. The planned dates always change in a Schedule Model, to reflect the reality. The static concept used for comparing with the actual performance is called a Baseline.
• Schedule Models are usually too detailed, and too complex, which is not effective as the rest of the project management system is not as mature as it: the chain is only as strong as its weakest link. Keep the Schedule Model as simple as possible, and spend your extra effort on managing the RIC Register instead.
• Use a project scheduling software such as Microsoft Project.
• It’s OK to send the Gantt Charts to stakeholders, but try to limit is and help them focus on the Progress Register’s Dashboard instead. The Gantt Chart is mainly a technical tool for the PM Support, and sometimes for the Project Manager.
• In case of external projects, remember that the Schedule Model mentioned here is only about your responsibilities in the project, rather than the wider Schedule Model for the whole project defined in the customer side. They might ask you for help to compose their own Schedule Model, but that’s not part of the management documents in your PMIS. The Activities in your Schedule Model may have external dependencies to activities of other suppliers working in parallel with you.

Progress Register

We measure progress to understand deviations, and try to reach the goal by recovering from those deviations.

Progress is measured based on the following two main variables:

• Cost: based on a simple form of Earned Value Management
• Time: based on a simple form of Earned Schedule Management

Other variables, such as quality, are expected to be reflected in the two primary variables mentioned before.

Progress Register captures the following sub-elements:

• A summary of planned values, based on the baselines
• The aggregate of the performance data, analyzed by the scheduling software
• Forecasts, that are calculated based on the previous two sets of data, and are the main progress measurements
• Limits, including the Plan Limits, used to see when it’s required to escalate the deviation and replan the Cycle.
• Dashboard, which is a simple, visual representation of the performance, used instead of common reports.

Note:

• Most projects spend too much time on scheduling and measuring performance, which is mostly wasted, as the rest of the project management system is not as mature as that domain; a chain is only as strong as its weakest link. Keep your scheduling and measurements simple, and rough: that’s enough for your project. If you have enough time and energy, spend it on managing RIC Register instead.
• There’s a small overlap between what we have in parts of the Progress Register, and what is usually stored in the Schedule Model (depending on the scheduling software). Don’t worry about the duplicate, as managing the information in the scheduling software is usually complex, and it’s more product-based to do it using the Progress Register.
• We don’t use common, long, boring reports in P3.express. Instead, almost-realtime dashboards are available for all stakeholders to stay informed of the progress of the project. The dashboard doesn’t provide all the possible information, but that’s exactly the point: you should direct the stakeholders to stay focused on the big-picture, rather than details. You, as the Project Manager, will need more details for controlling the project, which can be generated on an ad hoc basis with the help of PM Support (project planners).
• We strongly discourage you from using any measures other than the two mentioned here, as they are usually activity-based and mislead you.
• It’s best to use the template, instead of building your own.
• In case of external projects, remember that the progress information mentioned here is only about the scope and Configuration Map of your responsibilities in the project, rather than the wider scope of project defined in the customer side. They may ask you for help to measure the wider scope, but that’s not part of the management documents in your PMIS.

Business Case

The Business Case explains the justification of the project for your company.

The Business Case has three main purposes:

• Continuously checking the justification of the project, and stop the project if it’s not working for you
• Use it to make better high-level decisions that help you achieve the benefits, and the goal mentioned in the Project Summary
• It’s also used for tracking the benefits after the project is finished, which generates invaluable information for future projects, and also recovers benefits with simple actions.

Notes:

• All benefits are just rough estimates, and that’s enough for us. Don’t try to make them precise, as it’s not possible, and will waste your energy.
• In case of external projects, remember that the Business Case mentioned here is about the justification of the project for your company, rather than the customer. They have their own Business Case, and may ask you for help to prepare it, but that Business Case belongs to them, and is not part of the management documents in your PMIS.