Multi project management

Revision as of 00:26, 22 September 2015

A project management is difficult because of costs and schedules. A multi project management is even harder and if the different projects have different topics, then it becomes a challenge to ensure the planned schedules while complying with the costs. And the communication with the clients and the colleagues become pretty harsh. You have to be careful about information you can share or not while staying meaningful and accurate.

Multiple Project Management is composed of many projects related together. MPM is often understood as just many single projects that you have to achieve one by one reaching each deliverables planned. Actually, MPM is located between Program Management and Portfolio Management but it is different. That is more than a Program but less than a Portfolio.

In multiple project management, I will study the management of the schedules. Most of multiple projects are seen by the manager as a big project. What about a Program Management point of view? Schedules and costs? Program Management looks farther. This approach can solve problems which cannot be solved by a project point of view. The management of different critical paths will be different with benefits goals and not deliverables goals. With this point of view, a multiple project or a complex project will aim short term deliverables but also long term benefits.

Background

First, I have to explain the difference between program management and project management. The best way to explain it can be this sentence: Project managers manage projects and program managers manage a portfolio of projects. So with this difference, we understand that a Multiple Projects Management (MPM) can be approached with a Project Management point of view or with a Program Management point of view.If we consider a MPM just as a big project then it is a Project Management point of view. However, if a MPM is a portfolio of projects then it is the Program point of view.

In a MPM, actually, the managers just look about the schedules and the costs. Here, the aim is only to finish the MPM and do not look farther. It is all about the deliverables and they forget the benefits. Moreover, most of managers think of MPM simply as the management of a list of individual projects, rather than a complex entity. So there are 2 steps before reaching a Program Management point of view.

MPM being between Portfolio and Program Management, I have to explain the difference between Portfolio Management and a MPM. It exist a difference between multi-project management and project portfolio management. The former is geared towards operational and tactical decisions on capacity allocation and scheduling, and is the job of project or resource managers; the latter is concerned with project selection and prioritisation by executive and senior management, with a focus on strategic medium- and long-term decisions.

Figure 1: Project, Program and Portfolio Management

Finally, managers think about multi-project management and program management as the same. But it is a separate concept: program management is a special case of multi-project management that has a single goal or purpose (for instance putting a man on the moon), whereas multi-project management generally treats the case of multiple independent goals. A program can be seen as a family of related projects and MPM either.

With this description of MPM and Program Management, let’s see how it can be related and used to solve uncertainty of schedules and why a MPM has not just deliverables goals but benefits goals too.

Uncertainty of multiple project management

From early phases, MPM should be defined: planning, cost and time. But there is other information, unknown, which need to be recorded. Uncertainty can be defined as the difference between the information required to make a decision and the available information.

There are two concepts attached to uncertainty:

• Predictability, since the future is not known, and the past can be an invaluable guide.
• Complexity, since it is costly in terms of time, money and other resources.

Here, we can easily see the difficulty about scheduling because of MPM complexity. However, the predictability is the same for MPM or a single project.

Risk is the probability of the occurrence of a risk event given its risk source. To define risk, two definitions should be considered:

• Risk source, as an underlying state of affairs
• Risk event, as something given due to the underlying state of affairs

When the needs of the client and the manager are not met, a risk event can be created. In addition, modifying these need during the project, or having a weak communication between the parts, can create the risk event. Risks event can be solved by a Program Management approach (Planning in Program Management).

In risk situations, there are parameters controlled by probability, known by the decision maker. However, in uncertainty situations, parameters are uncertain and no information about probabilities is known. It is clear that a manager do not have precise information, especially when making long-term planning as in MPM. But it is possible to determine some parameters from experience or statistical data. The uniqueness of a MPM leads to a high degree of uncertainty especially in planning because of the interaction between all the projects. Therefore, project managers must lean on risk management to identify, analyse, monitor and report risks.

Figure 2: Overview of known unknows concept in Risk Management

The project risk management uses four basic concepts to help identify the type of risk:

• Known-knowns: the risks have been identified and a probability can be assigned.
• Known-unknowns: the risks have been identified but a probability cannot be assigned to them.
• Unknown-knowns: the risks are the ones identified by someone who associates probability to them, but decides to hide that information.
• Unknown-unknowns: the risks have not been identified.

This being said, the purpose of risk management is to help eliminate the unknown-unknowns and decrease uncertainty by having all risks known-knowns. This way, the complexity will be minimized and also the predictability, to some extent. For MPM, the complexity for the schedules will decrease even more than for a single project because the complexity is not linear. A small problem in one project can create one problem in each others projects then the level complexity becomes unsolvable for the schedules. Taking a Program Management point of view, we do not have multiple goals but we have one goal with multiple purposes and we will see how it can solve the risk problems.

Moreover uncertainty is more than just we talked about before. Risk Management is actually really developped and studied by companies to improve their efficiency and the reliability in it. The risk matrix is well-known in Risk Management because it ranked the risks depending on the probability and the impact on the Multi-Project.

Figure 3: Probability and Impact Matrix

The Risk Matrix is also popularly known as the Probability and Impact Matrix. The Risk Matrix is used during Risk Assessment and is born during Qualitative Risk Analysis in the Risk Management process. It is a very effective tool that could be used successfully with Senior Management to raise awareness and increase visibility of risks so that sound decisions on certain risks can be made in context.

A risk is “rated” for its Probability and Impact on a scale to see how important it is and if it can be enter into the Risk Management or not. Which Risks in the process move forward into the Risk Management process will depend on the industry, company, project and people. Some are by nature more risk tolerant than others. For example, we can have a Multi-Project where the team agrees that any risk that is in the orange or red cell can move forward in the Risk Management process. The rest remain in the watch list and are “accepted”. Another Multi-project could have different criteria by not taking the yellow cell.

If you are just taking a Project Management point of view for the risks, you are just taking care of your single project, but it may compromise the safety of the others projects. To ensure the safety for the MPM, you have to choose the Program Management having a global point of view of the MPM. It permits to target the risks for the MPM without favorize one project compared to the others. You have to choose the collborative Management and not the concurrential Management.

Multi-Project Manangement as Program Management to solve uncertainty

Now, we will stop to see a MPM just as a big project. MPM is a Program with one goal.

We can see the Multi Project Management is just between Program Management and Portfolio Management. And that’s right in the first part we saw about Program Management being a Multi Project Management with just one goal. All the projects are related so we can determine a final goal even if all projects have a different goal.

Figure 4: Place of MPM in Management

For example, when you are renovating a water-treatment plant, Civil engineering want to build the walls on time, the electricians want to finish their electrical installation on time. Each part during the construction process has its proper goal. But at the end, this multi-project has only one goal, increase the wastewater treatment.

We can even extend this MPM to a Portfolio Management because it is a long-term program for environment. If the manager of this MPM communicates about this idea, we approach a Portfolio point of view.

How Program Management can solve some uncertainty problem in a MPM?

We saw in the first part about risk event in Risk Management. If the manager of MPM and the client have a fight about the goals of the Multi-Project, then risk event are created and the schedules will be delayed and cost will increase dramastically. But with a Program Management, the manager will have a point of view in a long-term cycle. And the client has already a long-term point of view. Adopting a Program Management can solve the risk events which can occur about the difference objectives aimed.

With this Management, the communication will also be improved and communication is a key point in Management in general. Many managers consider MPM as an organizational-level environment in which multiple projects are managed concurrently. Without a Program Management, the communication will become fastly really bad because each manager of one project will not communicate with the others manager in order to be the best project inside the Multi-Project. But with the Program Management, the communication will be easy because each manager will not look about a limit date and will not in competition with the others managers but will aim the final objective of the program.

Moreover, Programs require a more complex governing structure than projets because they involve fundamental business change and expenditures with significant bottom-line impact. In fact, in some instances their outcomes determine whether the enterprise will survive as a viable commercial/governmental entity. So with the Program Management, it is not just about finishing the MPM but it is to ensure the survival of the company and in a MPM you have this "complex governing structure". Especially, the Risk Management is included in Program Management so the survival of the company is safer within a Program Management than within a Project Management.

By minimizing risks and maximizing opportunities to successfully manage a program, risk management strategies can be developed to mitigate potential risks that can adversely impact a capital program.

It takes a disciplined approach to manage and control projects carefully. The best way is to use a systematic and deliberate process that meets strategic objectives through the careful management of a project from inception to completion. As part of the risk management process, it is necessary to listen the client’s objectives and priorities, and then work to build consensus among project participants through the risk management process.

Whether a risk is strategic, technical or related to cost and schedule, a company can develop a customized risk register to help clients to identify risks; establish risk likelihood and consequence; and develop mitigation plans and ownership of required mitigation measures. Every step of the way, the company should be involved in the elements inherent in risk management, spanning from assessment and measurement of program progress to resetting of priorities based on the project’s status.

Whether it is finding solutions for program development and implementation to the overarching goals of delivering a quality program that meets the needs and satisfies political, economic, social and environmental objectives, the global professionals are dedicated to ensuring that the fundamentals of a successful program are achieved.

So, the main parts, that Program Management can improve, are the risk diminution, the communication improvement and a safer way to ensure the survival og the company.

Limitations of Program Management approach

• Inability to “stick” with the project scope:

Multiple Project Management, by definition, is unable to commit to the original project scope due to constant change requests. However, Program Management keeps its project scope before, during and after the MPM. This limitation causes a lot of problems, and is the reason why so many projects end up way over budget and many months/years late, sometimes even cancelled.

• Inability to fully align the project objectives with the business/organizational strategy:

By definition, Multi Project Managers manage projects, not their organization. Although projects are usually initiated by stakeholders/executives with a clear relation and full alignment with the overall corporate strategy, Project Managers cannot, by themselves, make sure that their projects are kept aligned with the company’s strategy. In order to solve this limitation in Project Management, Program Management was introduced as a higher layer of managerial control to guarantee and sustain alignment. So, to conciliate the Program and the Project point of view, you have to employ a Program Manager and a Project Manager and in reality it is really complicated because of the cost.

• Inability to manage projects with unspecified budget and/or schedule:

This is probably the biggest limitation in the traditional incarnation of Project Management. Project Management imposes a budget and a deadline on any project and thus creates a major problem: All projects finishing on time and on schedule (and they are very rare) have their quality compromised (when was the last time you saw perfection in any project?). This is the main problem of Program Management. You have one goal to reach but each project in the MPM has to reach their goals before to reach the objective of the Program. During this process, we saw that the project managers have to forget their goals and only concentrate on the ultimate goal. We have found a big contradiction between the 2 points of views and then it is really easy to understand the difficulty to apt a Program Management point of view for a MPM.

• Exclusive Methodology problems:

Following an exclusive methodology Project Management forces the Project Manager to choose and follow a methodology, be it the traditional (waterfall) methodology, or a newer methodology such as Agile. In Project Management, a project can only be managed using one methodology, and, in almost all cases, is not switched from one methodology to the other (usually methodology switching is not per project and is a decision made at the organization level), even when the other methodology is proven to be highly successful for that type of project. Being restricted by an exclusive, non-changeable methodology, either at the project level or the organizational level undermines and limits the potential of the project as well as the resources. In MPM this limitation is even harder because imagine one methodology for each project inside the MPM, at the end the different methodologies can be in conflict. Each projects will be limited by an exclusive methodology and will be also limited by the others projects.

References