2. PMIS Framework and Overall
PMIS, the abbreviation for Project Management Information System, has been used for many years across domains related to project management. Despite its long-standing presence, however, a clear and shared understanding of PMIS has not been well established within the project management community, nor has a comprehensive and authoritative definition been offered. The fact that no independent book dedicated specifically to this subject has yet been published worldwide also reflects this situation.
Many individuals equate PMIS with project management software. Some traditional project managers, who hold sceptical or exaggerated views toward computer-based services, believe that all the problems in their projects stem from the absence of such a system. Others imagine PMIS as a tool capable of resolving all project issues with the press of a single button. Still others consider it unnecessary or ineffective.
A simple online search for the term PMIS reveals that a considerable portion of the results originates from websites offering project management software products, where PMIS is merely used as a search keyword, with no accompanying explanation or conceptual definition. Even the limited references to PMIS in the PMBOK® Guide display a degree of inconsistency in the authors’ understanding of the concept. Moreover, the changes made across different editions of the Guide in relation to this subject indicate, on the one hand, limited familiarity of the authors with the domain and, on the other hand, the breadth, evolution, and complexity of PMIS, particularly as information technology has become deeply integrated into the daily operations of organisations and individuals.
Project information management is one of the most important objectives of PMIS. Although PMIS has traditionally been recognised as an information system—as also reflected in the PMBOK® Guide—the concept extends far beyond a simple information system. In fact, project information systems represent only one component of project information management, which is a much broader and deeper domain.
As noted in the previous section, the term ERP—which refers to a type of integrated organisational system—can be misleading if interpreted strictly according to its literal meaning, Enterprise Resource Planning. Nevertheless, despite significant evolution over time—from early MRP systems to today’s comprehensive organisational platforms—the term ERP has remained in use. A similar situation applies to PMIS. The needs of organisations and project management teams extend far beyond those of a mere information system. Increasingly, the project management community requires a modern management framework within projects and organisations.
This modern framework is enabled through the use of integrated project management tools, allowing project management teams to manage projects more effectively by ensuring systematic project information management and the appropriate use of tools. Implementing such a framework requires changes in the competencies of project management teams, improvement in the information technology literacy of both organisations and project teams, and adjustments to organisational procedures and structures.
In summary, PMIS should not be regarded merely as a project management information system. Rather, it represents a management framework within projects—one that, through effective project information management and appropriate utilisation of tools, enables more efficient and effective project management.
2.1 Definition of PMIS in the PMBOK® Guide
From the earliest editions, the authors of the PMBOK® Guide have acknowledged the relevance of information technology, project management software, and project information systems. Nevertheless, their treatment of these subjects has been presented in a cautious and conservative manner, a tendency reflected in the variation of terminology and emphasis across successive editions. This section therefore reviews the perspectives found in the second, third, and fourth editions.
The second edition, published in 2000, introduced the well‑known definition of PMIS that remained essentially unchanged through the fourth edition. Within the chapter text, however, the term “project management software” was used more frequently than PMIS, indicating a narrow and tool‑oriented interpretation. In total, this edition contained nine references to PMIS and information technology, without establishing any connection to broader organisational concepts such as Enterprise Environmental Factors (EEF) or Organizational Process Assets (OPA).
The third edition, published in 2004, includes twenty‑two references to PMIS—the highest frequency among the examined editions. It is in this edition that the concept of Enterprise Environmental Factors (EEF), formally defined in the PMBOK® Guide, is introduced. PMIS is explicitly identified as one of the elements within this category, marking a shift towards situating PMIS within a broader organisational context. References to project management software become less prominent, and the role of PMIS in project integration is strongly emphasised, with PMIS listed as a supporting tool across all integration processes.
The fourth edition, published in 2008, contains at least sixteen references to PMIS. The strong emphasis on the role of PMIS in integration processes—clearly evident in the third edition—is significantly reduced here, with only a single integration‑related reference remaining. Instead, greater attention is directed towards PMIS as part of the Enterprise Environmental Factors (EEF). While this edition continues to acknowledge PMIS, its perspective remains predominantly tool‑oriented and does not substantially expand the conceptualisation of PMIS beyond this orientation.
A comparative summary of these three editions is provided in the accompanying table, presenting the PMIS‑related topics mentioned across all editions together with their corresponding chapter references.
The most prominent references to PMIS in the PMBOK® Guide can be categorised into the following thematic areas:
• PMIS as a Component of the Enterprise Environmental Factors (EEF).
In the introduction to the fourth edition, PMIS is identified as one of the Enterprise Environmental Factors—environmental conditions, both internal and external to the organisation, that influence project success and serve as inputs to many planning processes. Similar wording appears in other sections where EEFs are listed among process inputs. These sources describe PMIS as a component of the EEFs that provides access to automated tools such as scheduling software, configuration management systems, information collection and distribution systems, or web‑based interfaces that interact with other automated online systems used in the Direct and Manage Project Execution process.
• PMIS within Integration‑Related Tools.
All editions of the PMBOK® Guide—particularly the 2004 edition—explicitly emphasise the role of PMIS as one of the tools supporting project integration.
• PMIS as a Schedule and Cost Control Tool.
Across all editions, PMIS is consistently referenced as a tool used in schedule control and cost control processes.
• PMIS as a Tool for Information Planning, Distribution, and Reporting.
Each edition also acknowledges PMIS as a mechanism used in planning project information, distributing it, and supporting reporting activities.
• PMIS Defined as a Comprehensive Information System.
A broader definition, presented across all three editions and included in the glossaries of the 2004 and 2008 editions, defines PMIS as an information system comprising a collection of tools and techniques applied within project management processes. This definition states: “PMIS is an information system that uses tools and techniques to collect, integrate, and disseminate the outputs of project management processes. PMIS supports all aspects of the project from initiation to closure and may include both manual and automated systems.”
Summary of the PMBOK® Perspective on PMIS
Based on the definitions presented above, the PMBOK® perspective on PMIS may be summarised as follows:
• PMIS is not a single tool; it is a collection of established tools and methods.
• PMIS performs an integrating role across all elements of the project.
• Collecting and disseminating project information are among its core functions.
• PMIS may be used across all areas of the project.
• PMIS is regarded as an enterprise‑level environmental factor.
• PMIS is not necessarily automated and may incorporate manual components.
• PMIS is a supporting instrument for the project team and is not intended to perform project management.
• PMIS is one of the control‑related tools within the project.
2.2 What PMIS Is Not
Before presenting a formal definition of PMIS, it is essential to address several common misconceptions and clarify what PMIS is not:
• PMIS is not synonymous with project management software.
• PMIS is not merely the automation or digitisation of project activities.
• PMIS is not a substitute for the project manager.
• PMIS is not a system that manages projects on behalf of the team.
• PMIS is not necessarily a set of large or complex systems; in some cases, even a simple set of manual procedures for maintaining project information may constitute a PMIS.
• PMIS is not exclusively a fully automated or mechanised system.
• PMIS cannot produce accurate outputs without the entry of correct and reliable data.
• PMIS is not the root cause of major project management challenges.
• PMIS is not merely an information system.
• PMIS is not designed to carry out all project tasks; these tasks are to be performed by the project team.
• PMIS is not a luxury or ornamental system.
2.3 The PMIS Knowledge Aria
Engagement with the field of PMIS requires establishing a well‑defined alignment between the domains of Information and Communication Technology (ICT) and project management. Without adequate expertise in both domains—both conceptually and operationally—and without considering local and application‑specific requirements, the provision, development, and effective utilisation of project management tools will inevitably encounter challenges.
As previously noted, PMIS represents a modern, information‑based managerial system. Within this system, project management activities are supported through the effective use of automated tools while concurrently addressing the information requirements of projects. As illustrated in the figure below, the Gap between the ICT knowledge domain and the project management knowledge domain has presented significant challenges to establishing an effective linkage between these two areas.

This gap represents an interdisciplinary knowledge area that encompasses a body of knowledge and experience concerning the provision, development, and appropriate use of ICT tools within project management, as well as contemporary project management approaches enabled through these tools.
Accordingly, the PMIS knowledge domain is an interdisciplinary field that draws upon project management knowledge, ICT expertise, and related foundational disciplines on the one hand, and accumulated practical experience from the development and deployment of information systems in projects on the other. It pursues the following objectives:
• Identifying and addressing the information requirements of projects
• Developing or procuring appropriate tools and software to establish and integrate the project or organisational information system
• Implementing and operationalising PMIS within projects or organisations
• Monitoring, maintaining, and improving the existing PMIS
• Optimising Organizational Process Assets (OPA) through a PMIS‑oriented approach to strengthen a PMIS culture and support tool‑enabled project management
• Enhancing the competencies of the project management team in the effective use of project management tools and aligning these tools with project management processes
Without familiarity with this knowledge domain, neither an appropriate PMIS will be developed nor will an existing system be used effectively. PMIS knowledge must be developed or acquired for each type of project or organisation, and without applying this knowledge even ready‑made tools will not be effective. Likewise, the procurement or development of project management tools and software will inevitably lack efficiency and proper functionality in the absence of this foundational knowledge.
2.4 Definition of PMIS
PMIS is the application of knowledge, skills, tools, and techniques related to the knowledge area of ICT, project management, and other dependent knowledge areas, for the purpose of planning in the appropriate, timely, complete, and valid provision of the information required by project stakeholders and the outputs of project processes to designated persons during or, if appropriate, after the project life cycle, in such a way that it facilitates project decision-making and increases project efficiency.
PMIS is performed through the appropriate application of 30 PMIS processes that are grouped into 5 process groups. These 5 process groups are:
- PMIS Planning Process Group
- PMIS Acquisition Process Group
- PMIS Implementation and Operationalization Process Group
- PMIS Control and Optimization Process Group
- PMIS Support Process Group
These processes will be presented for the management of information of a project, but in Chapter Four, the application and the manner of functioning of these processes in project-oriented organizations or a set of projects will be addressed.
2.5 PMIS Positioning in the Organization
As introduced, PMIS is considered a knowledge area. This knowledge area, on the one hand, is strongly affected by the organizational environmental factors and is also affected by the type of domain. This means that it is affected both by organizational culture and relationships, and by the type of product or service that is produced or provided in the project. For example, PMIS in EPC companies in the oil and gas domain is different from PMIS in the same companies in the power plant domain. Even the extent of organizational maturity of these companies will affect the type of their PMIS knowledge.
Every knowledge domain within an organisation requires a suitable institutional locus for the accumulation and consolidation of knowledge. For instance, engineering knowledge typically develops within the engineering department, and one of the primary objectives of establishing a Project Management Office (PMO) in project‑based organisations is to retain project management knowledge within the organisation and transfer it across projects.
Similarly, organisations must define an appropriate organisational position for acquiring, maintaining, and developing PMIS knowledge. However, defining this position presents challenges because PMIS is an interdisciplinary domain—closely linked to Information Technology on the one hand and to Project Management on the other. If PMIS is positioned solely within the organisation’s IT Department, the influence and contribution of project management may diminish; conversely, if located exclusively under the project management function, effective coordination with the IT Department and other Functional Units may become difficult.
Given my experience in the setup and implementation of PMIS in a large number of medium-sized and large companies, it appears that several solutions can be proposed for this position, each of which may be selected according to the type of conditions and organization. The point that is common in all these proposals is that PMIS requires a position in the organization, and without the existence of such a position, it will certainly face failure. On the other hand, the issue of at what level PMIS is intended to be implemented also affects the manner of the position of PMIS. The types of organizations from the perspective of PMIS and the methods of implementing PMIS in organizations have been described in Chapter Four. Another issue that needs to be mentioned here is that the position of PMIS may be different during the initial setup and implementation from the support phase. Also, a roadmap can be considered for upgrading the position of PMIS in the organization according to the development of these systems.
The following organisational positioning options for PMIS are proposed:
• PMIS as part of the IT Department
In this model, PMIS is established as a section within the organisation’s IT Department. This option may be suitable for organisations that have not yet reached adequate maturity in the IT field. The main challenge in this model lies in maintaining effective interaction with projects and project‑related units. If the IT Department occupies a well‑recognised and influential position, this challenge can be addressed more effectively.
• PMIS as part of the Project Management Office (PMO)
This option is effective when the organisation exhibits high organisational project management maturity and the PMO holds a strong organisational standing. The PMIS’s proximity to projects enhances communication with project teams, while mechanisms must be established to ensure seamless coordination with the IT Department and other Functional Units.
• PMIS as a project
This approach is generally the most suitable for the initial establishment and deployment of PMIS within an organisation or project environment. PMIS is conceived and managed as a Strategic Project, defining specific mechanisms for interaction with both the IT Department and project teams, and overseeing PMIS process implementation across the organisation. From an organisational governance perspective, this project may report directly to senior management, thus ensuring the authority and support required for successful institutionalisation.
• PMIS as an independent Functional Unit
This arrangement is recommended for organisations that have previously launched and deployed PMIS and aim to expand it organisation‑wide. This option requires adequate IT maturity and a well‑developed organisational mindset toward PMIS—typically cultivated through prior successful experiences. However, this configuration is not recommended as an initial model for organisations beginning their PMIS adoption journey.
2.5.1 Developing a Roadmap for the Organisational Position of PMIS
It is important to emphasise that as the organisational position of PMIS advances within the organisation, the expansion of its activities and the further development of its capabilities become easier to achieve. However, elevating this position requires time and a consistent track record of successive successes. When an organisation observes the tangible impact of PMIS on the effectiveness of project activities and on overall organisational performance, it will naturally become inclined to strengthen and elevate its organisational position.
Possible PMIS deployment patterns include:
- IT Department – PMIS Project – Independent Functional Unit
In this pathway, the core PMIS capability is initially established within the IT Department. By defining PMIS as a dedicated project, the system is granted the operational autonomy required for its development and implementation. After the partial deployment of PMIS within the organisation, the PMIS function is elevated to an Independent Functional Unit.
- IT Department – Independent Functional Unit
In this approach, PMIS is first established within the IT Department and partially deployed across the organisation. Its organisational position is then directly elevated to an Independent Functional Unit.
- Project Management Office (PMO) – PMIS Project – Independent Functional Unit
This pathway follows the same logic as the first option, with the difference that the initial establishment and development of PMIS take place under the auspices of the Project Management Office (PMO).
- Project Management Office (PMO) – Independent Functional Unit
This pathway mirrors the second option, with the PMO serving as the initial organisational host before PMIS transitions into an Independent Functional Unit.
- PMIS Project – Independent Functional Unit
In the author’s view, this may be the most effective pathway for establishing PMIS within organisations that possess appropriate Maturity Levels in their information systems. In this model, PMIS is initially developed as a dedicated project and, following the successful implementation of PMIS processes, it is elevated to an Independent Functional Unit.
- Independent Functional Unit
This approach may not be acceptable for many organisations at the outset. Unless an organisation has previously experienced PMIS through one of the aforementioned pathways, it typically lacks the organisational readiness and acceptance required to establish a fully independent PMIS unit from the beginning.

2.6 Organisational Structure of PMIS
Regardless of how PMIS is established within an organisation or at the project level, it necessitates an appropriate organisational structure for its effective management. This section defines the key components and responsibilities required for the proper functioning of PMIS and outlines the duties associated with each role. These responsibilities are applied according to the organisational position assigned to PMIS.
2.6.1 PMIS Council
The PMIS Council consists of influential members of the organisation and serves as the highest policy‑making and supporting body for PMIS. This council includes key stakeholders from both the project and the organisation, as well as individuals associated with IT‑related domains. It plays the primary role in defining policies related to PMIS.
Another important benefit of this Council is that it provides institutional backing for the PMIS team when changes in work processes become necessary. The PMIS Manager—at either the organisational or project level—is a core member of this Council.
Individuals who may be proposed for membership in this Council include:
• PMIS Manager or PMIS Project Manager
• Project Manager
• Head of the IT Department
• Key Project Managers
• A representative from the organisation’s senior management
2.6.2 PMIS Manager
The PMIS Manager is the head of the PMIS Unit. If an independent PMIS unit is established within the organisation, the PMIS Manager assumes ultimate responsibility for the establishment and support of PMIS across the organisation. Core duties of this role include recruiting and managing the required PMIS personnel—such as PMIS administrators and developers—and liaising with external PMIS providers.
Management of PMIS‑related projects, when PMIS implementation is carried out through a project‑based approach, is also conducted under this unit. All general responsibilities expected of a functional manager also apply to the PMIS Manager, including planning, organising, communication, control, and oversight of all PMIS activities.
2.6.3 PMIS Project Manager
When PMIS is implemented through a formal project within the organisation, the role of the PMIS Project Manager becomes one of the key responsibilities associated with PMIS. Such projects may operate independently under the direct supervision of the organisation’s senior management, or they may function as projects positioned under a specific organisational unit.
The lower the organisational level at which the project is placed, the more challenging communication with other units becomes, and consequently the execution of PMIS‑related activities will face greater difficulty.
The PMIS Project Manager is responsible for defining the PMIS project within the organisation in accordance with PMIS processes. This manager assumes all responsibilities previously described for the PMIS Manager, with the distinction that the project will be formally closed once its predefined objectives have been achieved, and the responsibility of the PMIS Project Manager will end at that point.
2.6.4 PMIS Team
All individuals working under the organisational authority of the PMIS Manager or the PMIS Project Manager collectively form the PMIS Team. Depending on the size of PMIS, this team may range from a single individual to several dozen members. Typical roles within the PMIS Team include:
• PMIS System Administrators
Individuals with sufficient experience and knowledge in information technology and software systems who maintain communication with PMIS users as the primary point of contact. They are responsible for supporting, monitoring, and ensuring the proper operation of PMIS systems.
• Developers
A group of individuals involved—depending on the scale of the project—in the development and production of PMIS systems. This group includes programmers, designers, software architects, and other roles associated with software system development that may be utilised within PMIS when required.
• PMIS Analysts
Although analysts are typically considered part of a broader software development team, this role is treated as an independent function within PMIS. This is because when software development is carried out outside the organisation, PMIS still requires individuals experienced in business analysis and software systems analysis.
2.6.5 Technical Committees
Given the extensive and continuous interaction that PMIS maintains with both the project environment and the broader organisation, the establishment of specialised committees is essential to provide technical and operational support for PMIS activities.
These committees, functioning as the technical arm of PMIS across various knowledge domains, may be established as subcommittees operating under the PMIS Governance Committee. Each committee comprises expert specialists and consultants in the specific domains relevant to PMIS operations.
Beyond defining and validating organisational requirements within their respective fields, these committees are also responsible for reviewing and formally accepting the corresponding PMIS systems.
The establishment and active engagement of these committees effectively distribute technical responsibilities and significantly reduce the technical workload imposed on the core PMIS structure.
