PMIS in Project-Oriented Organizations

Enterprise PMIS

To distinguish PMIS at the project level from PMIS at the organizational level, the term “Enterprise PMIS (EPMIS)” is used to refer to PMIS within project-oriented organizations. Previous chapters presented the definition of PMIS and its processes for managing information within a single project. Just as managing a single project differs from managing multiple projects within a project-oriented organization, elevating information management to the organizational level increases both the parameters and the overall complexity. At this higher level, the management of information pertaining to programs and project portfolios is also added to the scope of PMIS.

Furthermore, the integration of PMIS to facilitate the use of shared resources across multiple projects and to support their concurrent management is another critical subject that must be addressed in an Enterprise PMIS. Projects—whether conducted independently or within a project-oriented organization—are unique, and this uniqueness is reflected in their respective information systems. Accordingly, just as each project requires its own distinct and specific planning, PMIS must likewise be planned and implemented uniquely for each project.

However, it is essential to note that just as project-oriented organizations accumulate the knowledge required for executing their projects throughout their lifecycle and establish specialised functional units to reduce cost and time, the organization’s PMIS knowledge should similarly evolve and mature during the organization’s lifetime, and this knowledge should be made accessible to both the organization and its projects. It must be emphasised that each organization’s PMIS knowledge is also unique and must be developed specifically for that organization. As discussed in Chapter One, information systems rely on three factors—people, organization, and technology—and since these factors vary among organizations, Enterprise PMIS must be implemented uniquely for each organization.

Enterprise PMIS necessitates the creation or provision of specialised systems designed for common use by all projects. It must establish information systems that enable each project to customise itself within them and maintain its uniqueness while simultaneously benefiting from the organization’s general rules and accumulated knowledge. This necessity arises because implementing information systems solely within a single project is both costly and time-consuming. In the absence of pre-existing organizational systems, transferring PMIS experience from one project to another becomes difficult, and each new deployment entails considerable additional cost and time. Furthermore, within Enterprise PMIS, projects are connected through the program and portfolio structure and utilise shared organizational resources.

Another dimension that becomes more prominent in Enterprise PMIS, compared with project-level PMIS, is its integration with other information systems within the organization. This interrelationship is elaborated upon in the following section.

4.2.1 Types of Information Systems and Automation in the Organization

From the perspective of PMIS, information systems in project-oriented organizations are divided into two general groups. One group consists of systems that deal with the management of project and product information and processes, and the second group consists of systems that manage the organization’s general and support information and processes. The fact that project-oriented organizations carry out part of their activities through their functional units, and on the other hand part of the management of processes and information in such organizations is also carried out in these units, indicates the importance of the relationship between project and non-project information and processes at the macro level of an organization. For example, in an EPC organization, engineering activities are usually carried out in the engineering unit, and procurement activities are carried out in the procurement unit. In this case, integration is required both at the process level and at the information level between the specialised information systems in the engineering and procurement units and the project. Likewise, the strategic management of organizations, based on portfolio management and its close relationship with programs and projects, further highlights the importance of organization-wide integration of all organizational activities.

With such an approach, the information systems and automation of a project-oriented organization can be classified into the following four groups:

Project management systems

Project product-related systems

General and project support systems

Information and process integration systems

Project Management Systems:

These are a set of tools and information systems that meet the project’s needs across the thirteen project and construction management knowledge areas introduced in Chapter One. It is important to note that it is not necessary to have a separate system for each knowledge area; in some cases, a single system may manage several knowledge areas. On the other hand, some knowledge areas may be fulfilled through the organization’s existing systems. For example, the human resource management system of a project may be provided through the organization’s own system, and the project may use the organization’s communication systems such as email, correspondence systems, portals, and so forth. It is also possible that in some organizations certain knowledge areas are less important or not applicable. For instance, in organizations that carry out research and academic projects, procurement management may not exist.

All the points discussed in Chapter Three regarding PMIS procurement processes are also valid in Enterprise PMIS (EPMIS), and attention to them makes the selection of appropriate tools possible. Providing a general solution for project management systems in all organizations is impossible, as this depends on many conditions. Although many ready-made tools are available on the market for each project management knowledge area, providing suitable tools and establishing integrated connections among them in accordance with the needs of the organization and its projects are among the most important PMIS activities within the organization, and these are carried out through the organization’s PMIS processes.

Project Product-Related Systems:

The provision of these systems is highly important and creates significant added value for organizations, because they directly affect the project’s product, and the absence of such systems may expose projects to challenges. In the opinion of the author of this book, the importance of these systems is greater than that of other systems, and therefore, in the implementation priorities of PMIS, they should be given higher priority. Moreover, due to their specialised nature, these systems require sufficient familiarity with product-related activities, and in their selection and provision, the opinions of experienced consultants and experts must be utilised.

General and Project Support Systems

Systems that are also used in other non-project organizations and are employed for the automation and provision of information for functional units, as well as for other general organizational requirements, are classified within this group. It is essential to note that some general systems are usable in projects. These include email systems, correspondence systems, and human resource systems, and some of these systems contain essential information required for use by projects.

For example, the organization’s financial system is the place where the financial information items of projects are maintained. All payments, receipts, contractor accounts, contract accounting records, and other items used in the management of project budget and cost are maintained within these systems.

PMIS must, by identifying these information items, establish appropriate solutions for linking such information with the project management and product systems within the organization. This is one of the important duties in Enterprise PMIS, which has been addressed as a process within the Enterprise PMIS processes. It is recommended that as long as a system is used in the organization as a general or support system and is usable in projects, another separate system should not be used for projects.

Information and Process Integration Systems

The information systems of an organization can be effective and efficient only when they have appropriate interaction and connection with one another. Today, this is one of the objectives of the organization’s information managers. However, it should not be assumed that the connection between information systems is limited only to data transfer. Organizational work processes are distributed across diverse software applications and information systems, each of which has been developed at a particular time and with specific technologies. Therefore, the automation of such processes depends on the interoperability of different organizational systems.

As mentioned in Chapter One, Section 1.3.6, the use of Service-Oriented Architecture (SOA) is the most complete solution for the integration of information systems and the automation of organizational processes. This technology has emerged within Business Process Management Systems (BPMS) and has provided a suite that enables the connection among all systems of an organization within a unified framework. This subject has been explained in Chapter One, Section 1.4.3.

The issue of connections between tools and information systems in organizations is an important and complex matter for which PMIS must provide a solution tailored to each organization, considering the type of tools and the organizational conditions. In some cases, the non-standard nature of certain tools or the inability to develop and implement services on some information systems makes it necessary to use other communication methods between them. In some situations, such connections may even be defined manually.

4.2.2- Enterprise PMIS Processes

One of the main reasons for the emergence of project-oriented organizations is the maximisation of benefits through the management of shared resources. The more an organization is able to execute a higher number of projects by using shared resources—such as shared human resources, shared equipment and machinery, shared infrastructure, and shared information systems—the greater the benefits and profitability it will achieve.

The processes presented in Chapter Three are those used for planning through to the full operationalisation of PMIS within a single project on its own. The impact of a project-oriented organization on PMIS leads to an increase in the number of processes for managing Enterprise PMIS (EPMIS). All PMIS processes remain valid within EPMIS, and the following processes are added to it in certain process groups. These processes include:

In the PMIS Planning Process Group:

Preparation of the EPMIS Charter

Preparation of the Enterprise PMIS Plan (EPMIS Plan)

Identification of Program stakeholders

Identification of the outputs of Program and Portfolio processes

In the PMIS Provisioning Process Group:

Identification of tools for the aggregation and integration of information and processes

In the figure on the following page, you observe an overall view of the Enterprise PMIS processes.

4.2.2.1 Preparation of the EPMIS Charter

Similar to the PMIS Charter process described in Section 3.1.1, this process seeks to outline the overarching conditions and high-level policies of the PMIS, but at the organizational level. In this process, through understanding the organization’s strategic plan and the organization’s enterprise-level ICT plans, becoming familiar with the place of projects in the organization, and gaining awareness of the PMIS knowledge domain, the PMIS conditions for the organization are analysed, and it is determined, at a high level, under which policies and strategies the PMIS will be implemented in the organization.

Examining the existing conditions of the organization from the viewpoints of ICT and the maturity of information systems in the organization, as well as examining the organization’s enterprise-level ICT plans from the viewpoint of meeting the PMIS requirements in the organization, are among the other activities that must be carried out in this process.

Preparation of the EPMIS Charter: Inputs

Organization’s Strategic Plan:

This is a high-level organizational document that states the organization’s vision and mission and describes the organization’s long-term high-level and detailed objectives. This document is used in this process in order to understand the conditions of the organization.

Organization’s Enterprise-level ICT Plans:

In order to gain awareness of the organization’s macro-level plans in the field of ICT, it is necessary to review any long-term planning in this domain and to determine the direction defined for the organization’s ICT, and whether these plans will fulfil the PMIS requirements in the organization or not.

Organizational Process Assets (OPA):

The organizational process assets that may affect this process include the following, but are not limited to:

Standardised processes for determining and delivering ICT services in the organization

Existing templates for the EPMIS Charter

Experience gained from implementing PMIS in previous projects or within the organization

Enterprise Environmental Factors (EEF):

The environmental factors affecting this process include:

Previously implemented information systems in the organization

Previous planning carried out regarding the organization’s ICT

ICT infrastructure documentation for the organization and its projects

Organizational maturity documentation, including OPM3, EFQM, CMMI, and similar models

Quality audit documentation of the organization or previous projects

Preparation of the EPMIS Charter: Tools and Techniques

Enterprise PMIS Governance Committee (or the organization’s ICT Committee):

In organizations, councils and committees at the senior organizational level are typically used in carrying out important and strategic matters. Determining PMIS policies— which, on the one hand, are related to the organization’s ICT, and, on the other hand, have a significant impact on projects— requires consultation and support from the senior levels of the organization. As noted in Section 3.1.1 regarding the role of the PMIS Governance Committee in projects, it is necessary that a council be established at the organizational level to address such matters.

At the organizational level, the PMIS Governance Committee may be the same as the committee responsible for project-level PMIS governance; or, if an ICT Committee already exists in the organization, the EPMIS Charter may be reviewed and approved within that committee. In any case, the existence of such a council for reviewing and approving PMIS policy-making in the organization is considered a strategic requirement of PMIS.

Individuals who may be proposed for membership in this council include the following:

The organization’s PMIS Manager

The organization’s ICT Manager

The Project Management Office (PMO) Manager, or the organization’s Deputy for Projects

A representative from the organization’s Strategy Committee

A representative of the organization’s Senior Executive

Other individuals, depending on the organization’s specific conditions

Preparation of the EPMIS Charter: Outputs

• EPMIS Charter: The EPMIS Charter is a strategic document for advancing PMIS objectives within the organization. In this document, the organization’s conditions are stated and explained, and the high-level objectives and high-level PMIS strategies at the organizational level are presented and approved by the organization’s Enterprise PMIS Governance Committee and senior management. The purpose of this document is to provide a high-level description of issues related to PMIS within the organization in such a way that, by presenting the key points requiring the approval of the organization’s senior management, it prepares the organization to enter the PMIS planning phase. Some of the items that may be addressed in this document include:

Description of the organization’s objectives and conditions, particularly with regard to the organization’s projects

The organization’s high-level requirements from the PMIS perspective

The high-level schedule of the enterprise PMIS

Identification of major PMIS risks and proposals for risk management approaches

Assessment of the organization’s infrastructure conditions

Assessment and description of the organization’s ICT status

Description of the ICT culture within the organization and its projects

Statement of PMIS objectives within the organization

Introduction of the position of PMIS within the organization and the overall structure of the PMIS team, including the responsibilities and levels of authority of each role

High-level presentation of the PMIS analysis within the organization

Presentation of the PMIS strategy within the organization

• Updating the organization’s enterprise-level ICT plans: Since, after reviewing the organization’s major ICT documents, certain changes may be required in these plans in order to align them with PMIS requirements, this updating activity is included among the outputs of this process.

4.2.2.2 Preparation of the Enterprise PMIS Plan

Following the approval of the EPMIS Charter, it is necessary to prepare the Enterprise PMIS Plan, which defines the high-level PMIS plan at the organizational level. This plan specifies the number of projects that must be defined within the framework of the enterprise PMIS, including the objectives of each project, the high-level schedule of the projects, and their financial estimates.

Preparation of the Enterprise PMIS Plan: Inputs

• EPMIS Charter: This is the output of the process of preparing the EPMIS Charter, which is described in Section 4.2.2.1.
• The organization’s enterprise-level ICT programs: In order to become aware of the organization’s ICT programs, all programs that are currently being implemented or are planned for implementation must be reviewed by this process and taken into consideration in the Enterprise PMIS Plan. It should be noted that the Enterprise PMIS Plan itself is considered a part of the organization’s enterprise-level ICT programs and must be aligned and integrated with all of these programs.
• Organizational Process Assets (OPA): The items of the Organizational Process Assets that are used in this process include:
• Existing templates related to the Enterprise PMIS Plan
• Guidelines or work instructions for preparing the Enterprise PMIS Plan
• Samples of PMIS plans for previous projects
• Knowledge bases containing lessons learned and historical information
• Enterprise Environmental Factors (EEF): The environmental factors that will influence this process include:
• The organization’s project information systems
• Information technology infrastructure
• Information technology culture within the organization and its projects

Preparation of the Enterprise PMIS Plan: Tools and Techniques

• Enterprise PMIS Governance Committee (or the organization’s ICT Committee): The points presented in the process of preparing the EPMIS Charter for this section are also valid here. In addition, in this process, this council plays the role of reviewing and approving the enterprise-level PMIS plan.

Preparation of the Enterprise PMIS Plan: Outputs

• Enterprise PMIS Plan (EPMIS Plan): The Enterprise PMIS Plan is, in fact, a high-level plan within the organization. This plan does not enter into the same level of detail as the PMIS plan of a project. The most important activity of this plan is to determine the number of projects that must be carried out within the portfolio of enterprise PMIS projects and to determine the order and sequence of these projects and the manner in which they will be managed, in such a way that the greatest effectiveness is achieved in the organization. Addressing the financial matters of the enterprise PMIS is also among the items that must be specified and approved.

4.2.2.3 Identification of Program Stakeholders

As stated in Section 3.1.3, the stakeholders of the project were identified. If the organization has programs for the simultaneous implementation of several projects, it is necessary that the direct stakeholders of the programs, who are not identified within the projects, be examined and identified.

Identification of Program Stakeholders: Inputs

• Program Charter: This is the key output in the Program initiation process within the set of Program management processes. This document specifies the objectives of the program, the major risks, introduces the Program manager and the Program team, and determines the level of their authorities.
• Procurement Documentation: If the programs have contracts that have been concluded outside the projects, the contracting parties will be key stakeholders. In addition, suppliers at the Program level must also be taken into consideration as part of the stakeholder list.
• Organizational Process Assets (OPA): The items usable in this process include the existing methods for identifying the stakeholders of projects and programs, as well as the methods used in other programs that have been examined in the EPMIS.
• Enterprise Environmental Factors (EEF): The position of Program management in the organization, the manner in which programs interact with projects, and their relationship with the organization’s project portfolio are among the factors that may influence this process.

Identification of Program Stakeholders: Tools and Techniques

• Stakeholder Analysis: As referred to in Section 3.1.3.
• Expert Judgement: As referred to in Section 3.1.3.

Identification of Program Stakeholders: Outputs

• Program Stakeholder List: These are the same items referred to in Section 3.1.3.

Method of Deploying EPMIS in Organizations

As noted in the first section of this chapter, one of the characteristics of project-oriented organizations is that one of the main organizational units, namely projects, is temporary and is dissolved after the completion of the project. In this case, the risk of organizational knowledge not being retained increases, and the organization is therefore compelled to provide a solution for preserving the lessons learned from projects and transferring them to subsequent projects.

In this situation, organizations usually use two solutions simultaneously. The establishment of specialized functional units for performing product-related processes, which leads to the creation of a knowledge domain in this area, and on the other hand the establishment of a Project Management Office (PMO) for the management of project management knowledge, which leads to the standardization of work procedures and project management within the organization.

By creating the knowledge domain of project management, the PMO transfers this knowledge to projects and increases the speed of the initiation and planning phases of projects, which require greater experience and knowledge.

EPMIS is considered a knowledge domain in project-oriented organizations, and it is necessary that a position be considered within the organization for preserving this knowledge. Regarding where this position should be located within the organization, different viewpoints exist, which are discussed in Section 2.5.

4.3.1 Stages of Deploying EPMIS in Organizations

This book presents a seven-stage solution for deploying EPMIS in project-oriented organizations. These stages, together with the scenarios presented in the next section, will help organizations determine the appropriate method for deploying EPMIS.

The stages of establishing EPMIS are as follows:

Establishing the organizational position of EPMIS: Considering the type and conditions of organizations, it is necessary first to determine the organizational position of EPMIS, and afterwards the EPMIS activities can be carried out. If the position of EPMIS in the organization is a project, there will be no need to perform the next stage.

Defining EPMIS projects and completing the organizational structure of EPMIS: EPMIS projects in an organization are regarded as a strategic activity. With this approach, it is necessary, according to the conditions of the organization, that EPMIS be defined in the form of a portfolio of projects and be carried out under the supervision of the organizational position of EPMIS. In an organization, it may be necessary that several EPMIS projects be defined and carried out simultaneously.

Planning, procurement, deployment, and operationalization of EPMIS: These activities are carried out using EPMIS processes and through the following two approaches:

• Deployment of product-related systems of the project in the relevant functional units
• Deployment of project management systems in the organization’s Project Management Office and the project offices

Establishing connections with the organization’s general and support systems: As pointed out in Section 4.2.1, connection with other organizational systems is carried out after identifying their type and the way they are connected. It is preferable that the connection of systems be considered during the planning of EPMIS. However, depending on the conditions of the organization, the execution and establishment of these connections may be carried out during the deployment operations of EPMIS, or may be operationalised after that.

Integration of project information and processes: Considering the importance of this issue, it is preferable that the architecture and design of system integration be determined during the planning of EPMIS. However, the implementation of integration may be carried out incrementally or may be implemented on a per-system basis.

Control and support of EPMIS throughout the life of the organization: As pointed out in Sections 3.4 and 3.5, the matter of control and support is among the activities that take shape from the beginning of EPMIS and begins with the launch of the first system.

Defining a new development project: Usually, the implementation of EPMIS in organizations is not carried out all at once and requires complementary activities. Each stage of EPMIS implementation is defined in the form of a project, and after the completion of each project it is necessary that the continuation of the path be defined in the form of a new project. These projects may be carried out either for completing EPMIS or for improving previous activities. The definition and implementation of EPMIS projects in the organization do not end and are regarded as a continuous improvement activity.

At first glance, it may appear that a stage-based approach means that after the completion of each stage, the next stage will be carried out. However, in practice it is observed that the stages have more complex prerequisite and post-requisite relationships. It is recommended that Stages 1 to 3 be carried out sequentially and in the order presented. Stage 3 will be repeated for each defined project. However, it is not necessary that Stages 4 to 7 be carried out in the presented order. In the organizational EPMIS planning section, it will be determined with what plan and sequence EPMIS will be implemented in the organization.

4.3.2- Types of Organizations from the Perspective of EPMIS

The deployment of EPMIS is not carried out in the same way in all organizations, and planning in this regard must be carried out according to the condition of the organization. From the perspective of EPMIS, project-oriented organizations are divided into several categories:

1. Newly established organizations, small organizations, or organizations that have no experience in deploying information systems.
2. Organizations that have general information systems but have not yet deployed project information systems.
3. Organizations that have general information systems and have had experience in deploying EPMIS in some projects, but these experiences have not been elevated to the organizational level.
4. Organizations that have support information systems and EPMIS at the organizational level, but adequate integration and interoperability have not been established between them, or the systems require further development.

It is necessary that EPMIS planning be carried out with consideration of the organization’s maturity in the domain of business and information systems. In the next section, different deployment scenarios are presented for each of the above organizations.

4.3.3- Deployment Scenarios

Based on the categorization of organizations and the stages of EPMIS deployment, four different scenarios for deploying EPMIS are presented here.

1. Deployment of EPMIS across the entire organization:

This scenario can be carried out in organizations that have suitable maturity in business and in the use of information systems. In this scenario, according to a defined plan, EPMIS will be implemented simultaneously across all organizational projects. Organizations that are in Groups 3 and 4 of the classifications in the previous section are suitable candidates for carrying out this scenario.

1. At the project level:

This is the second level in the organizational maturity of EPMIS. In this scenario, EPMIS is implemented in one of the organization’s projects that has a more suitable foundation compared with other projects and is also at the beginning of the project. Organizations in Groups 2 and 3 are suitable for implementing such a scenario.

1. As a pilot:

In this scenario, organizations that have no experience in deploying information systems or EPMIS can implement part of their activities using EPMIS processes. Usually, in this method, one of the products-oriented information systems is an appropriate choice for pilot implementation of EPMIS. In this scenario, a limited-scope project can be defined, and after its successful execution, EPMIS can be deployed at the level of a project or at the organizational level. Usually, organizations in Groups 1 and 2 can be the users of this scenario.

1. For familiarization:

Newly established organizations, or organizations that have the lowest maturity in the use of information systems, are advised to begin the execution of an initial project in part of a project so that the implementation team and the organization become familiar with the subject, and if the organization and the implementation team are ready, the subject of EPMIS can be raised at higher levels. It is possible that, for carrying out the familiarization project, the name EPMIS may not be mentioned, and the approach may be the deployment of one of the projects-related systems of the product-oriented or project-management type.

In Table 4.1, some of the characteristics of the different EPMIS deployment scenarios are presented.