Skip to ContentGo to accessibility pageKeyboard shortcuts menu
OpenStax Logo
Foundations of Information Systems

9.1 Foundations of Information Systems Project Management

Foundations of Information Systems9.1 Foundations of Information Systems Project Management

Learning Objectives

By the end of this section, you will be able to:

  • Identify concepts, skills, and techniques associated with project management
  • Distinguish between project management, program management, and portfolio management
  • Apply project management, program management, and portfolio management skills

Project management is a fast-growing field. Businesses are complex and intricate systems that aim to provide products and services to their clients or customers. Project management is an aspect of business systems that provides specific tools and best practices to manage and lead the business. Project management focuses on people, assets, money, and time, and project managers use people, assets, money, and time to lead and manage initiatives that provide the products and services a business sells to its customers. In project management, an initiative, task, or activity is categorized as a project regardless of its complexity and who might oversee its implementation. For example, a task as simple as purchasing new phones or computers for employees can be categorized as a project because phones and computers are critical components of modern-day business and the process of purchasing has a time limit. Without these items, the business would probably not operate.

Concepts and Methodologies of Project Management

The Project Management Institute (PMI) is the main accrediting body for the project management process and certifies project managers, program managers, and portfolio managers. The PMI promotes the use of a structured, process-based approach to managing projects. The Project Management Body of Knowledge (PMBOK), developed by PMI, is a guide for handling projects using a systematic methodology and proven processes for initiating, planning, executing, managing, monitoring, and closing a project. PMBOK will be the basis for much of the project management foundations covered here.

Overall project management describes the use of specific knowledge, skills, tools, and techniques to provide guidance through each stage of a project. Project management involves planning, organizing, and controlling resources—such as people and materials—to achieve specific goals or objectives within a defined timeline. The person responsible for leading the efforts to plan, organize, and control the resources using various tools and techniques to initiate, plan, execute, monitor, control, and close projects is called a project manager (PM). A project is a temporary initiative or endeavor to create a product, service, or result that has beginning and end dates. “Temporary” in this sense only means that a project must have a beginning and an end; it does not refer to the length of the project Figure 9.2. Expanding sales into a new market segment, developing an information system to manage an internal process, opening a new branch of the enterprise, and implementing disaster recovery after a system or security failure—these are all examples of projects.

Graphic showing Start (hand with an idea), Project (computer displaying people icons), and End (clock over a calendar with last two date boxes colored red).
Figure 9.2 A project must have a start date and an end date. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license; credit left: modification of work “Hands collection - star on hand - The Noun Project” by “icon4yu”/Wikimedia Commons, CC BY 3.0; credit left: modification of work “Idea/report icon” by “hidayat, ID, from The Noun Project”/Wikimedia Commons, CC BY 3.0; credit middle: modification of work “Online meeting (the Noun Project 1029565)” by Ismael Ruiz, from The Noun Project/Wikimedia Commons, CC BY 3.0; credit right: modification of work “Countdown (50361) - The Noun Project” by “Icons8”/Wikimedia Commons, CC0 1.0)

A project can follow any timeline, lasting a week, a month, or many years, for example, as long as it meets the definition of a project. A project is considered completed once the scope or requirements have been met or once the objectives of the project have been achieved in accordance with the customer, sponsor of the project, or internal champion of the project. Projects can vary depending on the industry or the environment in which the projects are conducted. For example, a research institution might conduct research projects on new ways to upskill its workforce, while a pharmaceutical company might conduct a project on a new drug to cure Alzheimer’s. In the IS field, most projects involve technology and thus are considered technical in nature. An IS project manager might be involved in integrating a new technology into a university’s student information system or producing a new process to build electronic vehicles for a car manufacturer.

Project management is used in some form in many organizations. It crosses over many disciplines like construction, business, health care, manufacturing, and other industries where businesses initiate projects that need to be managed by an expert (project manager) who can ensure the project stays within budget, scope, and schedule. A project manager is a key employee with skills in leadership, management, project management, human resources, finance, procurement, contracts, and operations.

Differences Between Project Management, Program Management, and Portfolio Management

Program management and portfolio management can be thought of as managing groups of projects. The coordinated organization, direction, and implementation of a group of related projects is called program management. This related group of projects seeks to achieve outcomes and realize benefits that are strategically important to the business. Being coordinated means there are common rules to manage each project, such as when to escalate an issue or that all documentation for each project is similarly organized to group the projects together within the business. A portfolio is simply a collection of projects or programs that are grouped together but may not be interdependent of each other. Usually, these projects are grouped together to more effectively manage the projects based on the business objectives. Therefore, portfolio management is the centralized management of a set of projects grouped together to identify, prioritize, authorize, and control the related work Figure 9.3.

Hierarchy chart with Portfolio at top and three levels underneath labeled with various Portfolios, Projects, Programs, and Other Work.
Figure 9.3 In portfolio management, programs or projects are grouped together to realize more efficiency between those programs or projects. Program management groups related projects together to realize a similar outcome for the business. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Understanding project management begins with understanding the underlying principles of the various methodologies used to manage projects. The PMI developed the PMBOK framework and certifies Agile and PRINCE2 frameworks. Each of these frameworks and their supporting methodologies have certain principles that impact how projects are managed. The one thing they have in common is that they all come with documentation, best practices, and processes for managing teams, assets, and deliverables, and they have a very prescribed way to measure the success of each component.

Project management has many different components, complexities, and concepts to support the organization and success of projects. In most IS project management organizations, there is a hierarchical organization of the project management profession, similar to the various management and leadership levels found in health care, marketing, technology, finance, and higher education. Even though the structure is hierarchical, the team supporting the managers and leaders does not always report to the manager or leader of that department.

Project Management Using Project Management Body of Knowledge

The PMBOK is a waterfall approach, which means that each step is followed by the next step, which is followed by the next, and so on. While the sequential design of project steps is central to PMBOK, newer versions of the methodology emphasize that some concepts, such as risk, are more iterative (or repeated), and they must be revisited or monitored frequently.

In PMBOK, the development, monitoring, and control of a project is called the project life cycle (PLC) (Figure 9.4). The PLC is a sequence of phases that a project encounters as it progresses from start to finish. The phases include the following:

  • Feasibility: In this phase, it is determined whether the organization has the capability to deliver the product.
  • Design: This is the planning and analysis phase.
  • Building: This phase covers the actual implementation of the project and its project plan.
  • Testing: After building the project, the processes must be tested. In this phase, a quality review and inspection of the deliverables are conducted.
  • Deployment: With the other phases in the process complete, the project can be deployed. This is when all deliverables are finalized and transitioned to sustainability.
  • Closing: In this phase, all the knowledge and artifacts related to the project are archived, and the team members are released.
Project Life Cycle with circular arrows showing: Feasibility, Design, Building, Testing, Deployment, Closing, and back to Feasibility to start over.
Figure 9.4 The project life cycle is a series of phases that a project goes through from start to finish. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The PMBOK also defines eight domains that guide project managers through the PLC (Figure 9.5). The domains are defined as what the project manager must focus on in each stage to complete that stage. These eight domains ensure successful delivery of the project:

  • Stakeholders: Anyone involved or impacted by the delivery of the projects is a stakeholder.
  • Team: People who are stakeholders but also invested in the project deliverables are part of the team.
  • Development approach: This is the manner in which the phases of the project are planned.
  • Planning: The focus of planning is the organization of the project and how it is going to be implemented.
  • Project work: The project work includes the necessary items and processes of each deliverable in the project.
  • Delivery: This is the actual transition of the project deliverables to the stakeholders.
  • Measurement: Measurement includes determining whether the performance of the project and the people are delivering within an expected quality level.
  • Uncertainty: The focus of this domain is management of the risks associated with the project.
Eight domains of a Project: Stakeholders, Team, Planning, Project work, Delivery, Measurement, Uncertainty, and Development approach.
Figure 9.5 The eight domains of performance are what the project manager must focus on in each stage to complete that stage. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Let’s look briefly at some domains—stakeholders, team, development approach, and planning—to understand what it means to deliver a project on time within scope, on budget, within acceptable quality levels, and with minimal risk.

Stakeholders’ Domain

The stakeholders’ domain is a lot about communication and ensuring a good relationship is established with all the individuals associated with a project. Stakeholders include individuals, groups, or organizations that may affect, be affected by, or perceive themselves to be affected by a decision, activity, or outcome related to a project, program, or portfolio. A project’s stakeholders could include members of the organization’s leadership team, customers, clients, coworkers on the project team, middle management, vendors, regulatory bodies, steering committees—the list goes on and on. Communication and relationships with all stakeholders throughout the project are important to the success of the project. The stakeholders on a given project may shift over time, so keeping up with the list of individuals and groups can be challenging.

In the stakeholders’ domain, three desired outcomes should be pursued:

  • maintaining a productive relationship throughout the project
  • making sure stakeholders are in agreement with the project objectives
  • ensuring that stakeholders, who are beneficiaries, are supportive of the project and do not negatively impact project outcomes, such as trying to change the scope of the project or vetoing budget items important to the project

It is important to manage the stakeholders and their expectations both positively and negatively. For example, you could have a stakeholder who has not clearly understood the scope of the project and has additional requirements that are not included in the scope. As the project is developed and the project does not include these items, the stakeholder then believes the requirements have not been met. These expectations and beliefs must be identified as soon as possible.

One way to manage stakeholders is to perform a stakeholder analysis. A stakeholder analysis is a review and evaluation of each stakeholder, their background, expertise, and impact on the project. It involves a systematic gathering of quantitative and qualitative data to determine whose interests in the project should be a priority. The stakeholder or group of stakeholders whose interests are a priority are likely to have more power and authority over the project than other stakeholders. These stakeholders are the ones to assure, so it’s also important to make sure they are informed and satisfied throughout the project.

Team Domain

The team consists of the individuals who are responsible for building or producing project deliverables. If team members don’t work well together, it reflects poorly on the project manager. In fact, it is the project manager’s job to create a work environment in which team members work to ensure that deliverables are of high quality and are delivered on time and within budget, with minimal risk. The successful outcome of the project is dependent on the project team and its performance. The need for communication and relationship building among diverse team members is one of the reasons a project manager must be a good leader and communicator in addition to knowing when to push and when to let the team manage its own accomplishments. Establishing a shared-team mindset when it comes to deliverables, quality, and timelines is the goal of the project manager.

Development Approach and Life Cycle Domain

There are many different approaches to project development, which is the process of planning a project and ensuring it has the resources necessary to successfully achieve its goals and objectives. The approaches to the PLC highlighted by PMBOK are predictive, adaptive, and incremental development (Figure 9.6).

Predictive approach: Business/System requirements, Design, Construction, Testing, Delivery, Maintenance; Adaptive approach: Project/Cycle planning, Task initiation, Client feedback, (repeat), Final output; Incremental approach: Planning, Requirements, Analysis/design, Implementation, Testing, Evaluation, (repeat if needed), Deployment.
Figure 9.6 The predictive, adaptive, and incremental approaches to project development provide frameworks to develop different types of projects depending on an organization’s culture and specific project needs. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The predictive development approach is generally used for projects that have specific requirements with well-defined goals and objectives. The entire project is planned from start to finish before the project begins, and once the project is implemented, the plan is followed carefully. This includes adhering to the scope of work and project deadlines to meet requirements, design, construct, test, and deliver outputs according to plan.

When a project needs more flexibility, the adaptive development approach provides a framework that enables project team members to repeat the processes of cycle planning and task initiation as needed. This provides an opportunity to respond to client feedback and make changes in the project requirements as part of the ongoing processes. As they repeat the processes, team members are expected to learn by doing and then apply their new knowledge to improve the final project outputs.

The incremental development approach enables a project to be divided into parts, or increments, that work together and build on each other to accomplish the overall project. Dividing a project into smaller parts makes each part more manageable. Typically, as each part of the project is done, the project team delivers the outputs for that part, providing an opportunity for feedback on the project’s progress. This allows for changes to be made as each part of the project is completed, ensuring that the final product meets the overall project goals and objectives.

Each approach selected depends on the type of project, company culture, organizational structure, organizational capabilities, size of the team, and the location of the team. The workplace culture of the company or your stakeholders’ characteristics may dictate the development approach. When it comes to project management, there is never a one-size-fits-all approach. There are many factors to consider, and the approach and PLC can vary from project to project.

Depending on the needs of the project and the culture of the organization, an iterative approach could involve a hybrid method with modifications as needed to fit the project. Another consideration when deciding which approach to use is the degree of innovation involved in a project. This refers to how much change a project introduces. Some projects are minimally innovative, offering incremental changes, while others are more radical, offering changes that are disruptive and even transformative to operations or products.

For example, you may have a project that is very lengthy in duration with lots of interdependencies where the product must be delivered before the next process or components can be built. Say you are leading a project to build a space shuttle. There would be several components that would need to be developed prior to others, but there are some parts that can be delivered in conjunction with each other, like the engines and the capsule for the payload. You can develop the engines while you are developing the capsule because they are not necessarily dependent on each other. The engines are dependent on the weight of the payload, and the capsules can be developed to deliver up to the maximum payload. You could use a predictive approach or even an incremental approach for delivery.

Planning Domain and Project Work

The planning domain lasts throughout the length of the project and is associated with organizing, collaborating, and elaborating on the project and the project deliverables. The project work domain is about the execution of the project. It involves ensuring that the performance of the team and the product or service and the outcomes maintain the appropriate quality and map to the desired outcomes of the project. Each project requires the project manager to plan, coordinate, and manage the project in a holistic approach. No two projects are ever alike.

As a project progresses, there is always a certain amount of feedback and information that needs to be assessed for its impact on the project and its outcomes. Each project will evolve over time. The process of determining the appropriate information to provide to the team needs to be handled and managed to achieve the desired outcomes. The time spent planning for a project and the desired outcomes should be appropriate to the project. Project planning and the project management documentation should always be sufficient to manage stakeholder expectations. There are several project management tools and documents that project managers use in the planning process, such as a vision statement, project charter, business case, initial project plan, or RACI (responsible, accountable, consulted, and informed) charts.

Agile Project Management

The Agile project management methodology involves taking an iterative and incremental approach to delivering projects (refer to 4.1 Systems Analysis and Design for Application Development for more about Agile methodologies). This means that instead of trying to plan and execute an entire project up front, the project manager breaks the project down into smaller, manageable tasks. Project management teams using the Agile method seek to deliver value incrementally and iteratively by delivering products frequently and engaging with customers to gather feedback. This feedback is then incorporated into the project’s direction and objectives immediately. The Agile approach ensures that the final product aligns closely with customer needs and provides maximum value, meaning that the product delivers on the customer’s requirements and vision. This approach is particularly good for projects where the client can’t agree on the entire scope of the project up front.

Each chunk of work in an Agile project is broken into smaller components called user stories. User stories represent specific features or functionality required by the customer. Agile teams review and prioritize these functions and features. These tasks are then delivered in short iterations called sprints, which typically last from one to four weeks. A sprint typically involves a number of user stories being developed and completed at the same time. A meeting to discuss the user stories and divide the work is called a scrum meeting.

In Agile project management, there are several frameworks to support the iterative and collaborative approach central to this methodology, including scrum, Kanban, and extreme programming.

A scrum is an Agile framework that focuses on delivering value through small, cross-functional teams working in sprints, and the product backlog contains a prioritized list of user stories or features. [0]Prior to the start of the sprint session, items from the backlog to be completed are planned out and chosen by team members. During each sprint, the team members select items from the backlog to complete. Scrum meetings, often referred to as stand-up meetings, backlog refinement, sprint planning, sprint review, and retrospective sessions, usually happen daily, which enables the team to adapt and improve continuously. The leader of the scrum meeting is called the scrum master and usually has a certification from PMI or other certifying bodies.

An Agile framework that helps managers visualize and optimize the flow of work. Kanban is a visual representation of tasks and how they flow through the project (Figure 9.7). A Kanban board typically consists of columns representing different stages of work, such as to do, in progress, or done. Each work item is represented by a card, and team members move the cards across the board as work progresses. As work is completed, team members start on the next task. The cards can be set up on a digital Kanban board (via tools such as Asana, Jira, or Smartsheet) or simply with sticky notes on a wall or whiteboard. The Kanban framework emphasizes limiting work in progress to maintain a smooth workflow while maintaining a continuous delivery schedule. This framework helps teams identify bottlenecks, optimize their processes, and respond quickly to changing priorities.

Kanban Board: columns for Stories, To Do, In Progress, Testing, Done.
Figure 9.7 Referred to as a Kanban board, this type of Agile framework identifies the position of each component of work as the project progresses. (credit: modification of work “Abstract Kanban Board” by Jennifer Falco/Wikimedia Commons, CC BY 4.0)

Primarily used in the software engineering industry, extreme programming (XP) is an Agile methodology that emphasizes the use of software engineering practices to improve quality and responsiveness. Extreme programming also emphasizes customer involvement, short development cycles, and continuous integration and deployment. It incorporates practices like pair programming, test-driven development, frequent releases, and collective code ownership. By prioritizing customer value, XP teams can respond effectively to changing requirements and deliver high-quality software.

The advantage of an Agile approach is that it allows for flexibility and adaptability throughout a project’s term, as teams can adjust their plans and incorporate feedback at the end of each sprint. The disadvantages are that the client must be willing to put in significant time since Agile requires many reviews and evaluations of work as the work continues. Many clients or companies do not have the time for their employees to be dedicated to a project in this manner. Overall, the Agile methodology works well for small- to medium-sized projects and in certain industries where flexibility and adaptability are crucial. For example, it might be suitable for a project that is highly regulated where standards may change frequently while you are building the deliverables, such as hospital information systems, or a new technology such as an AI application system where the capabilities grow daily.

PRINCE2 Methodology

PRINCE2 (Projects in Controlled Environments) is a project management methodology and certification that is widely recognized around the world. PRINCE2, much like PMBOK, uses a structured, process-based approach to managing projects, but it is designed to be scalable and adaptable, making it suitable for projects of various sizes and complexities. The PRINCE2 certification is often sought after by project managers, team members, and individuals involved in project management roles around the world because it provides individuals with a robust framework and a common language for managing projects effectively, as well as ensuring consistency and the use of best practices in project management processes. PRINCE2 is built on seven principles that guide its project management practices (Figure 9.8).

Project management principles: 1. Continually justify project; 2. Learn from experience; 3. Define roles/responsibilities; 4. Manage by stages; 5. Manage by exception; 6. Focus on products; 7. Tailor to project environment.
Figure 9.8 The PRINCE2 methodology is composed of seven guiding principles of project management. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Principle One: Continually Justify Project

A PRINCE2 project must have a reason to be started, and that reason must make sense from a business point of view; therefore, business justification is essential. The reason for the project, the funding and resources needed, and the predicted return on investment (ROI) must all be identified. If the ROI is greater than the cost of the project, then the project should be initiated. Each company typically has its own method of determining a minimum ROI threshold before a project is started. In some cases, due to regulations or changing technologies, companies must invest in projects to remain compliant with laws or stay competitive, which should be taken into consideration. The business justification should be revisited throughout the project to ensure that the ROI and reason for the project remain aligned or, at very least, the ROI does not drop below expected levels.

Principle Two: Learn from Experience

This principle involves collecting data on lessons learned from previous projects to avoid repeating risky and costly mistakes. In PRINCE2, project teams are constantly looking at the outcomes of the project to assess how well it is progressing and to determine whether any lessons learned can be identified and used immediately as the project continues. Each project can be unique and have its own set of challenges. These challenges can create risks or unknowns. Project teams need to understand the nature of change and risk and adapt to new situations. One example of learning from experience is discussing with other project managers with different experiences how they might respond to the challenge you are facing.

Principle Three: Define Roles and Responsibilities

Determining the roles and responsibilities of stakeholders in a project is critical. In PRINCE2 methodology, there is a process for identifying stakeholders that involves sorting them into three categories:

  • Business sponsors: Stakeholders who make sure the project delivers value for money.
  • Users: Stakeholders who are usually the people who will use the products once they have been created. They benefit from completion of the project.
  • Suppliers: Stakeholders who provide the resources and expertise needed by the project to produce the products.

Not all companies or organizations have a dedicated team of project managers and other employees focused just on delivering projects. Project teams can be made up of people from various departments and companies, and therefore, defining each team member’s roles and responsibilities with respect to the project is key to running it successfully and smoothly.

Principle Four: Manage by Stages

Like Agile project management, the PRINCE2 methodology aims to manage a project—and keep the project team flexible and responsive—by breaking the project up into chunks or smaller tasks that it refers to as stages. The three stages in PRINCE2 are planning, monitoring, and controlling, and they take place sequentially one stage at a time. The stages are separated by decision points, sometimes called control points. The need for continuous monitoring of the ROI is one of the reasons there are stages in PRINCE2. At the end of each stage, the team conducts a performance assessment of the last stage to decide whether the project should continue and, if it does continue, to determine any adjustments that need to be made.

This is also a point at which lessons learned can be assessed and applied for the next stage of the project. Like in the Agile methodology where there are points along the way when customer or client feedback is called for, the decision points of PRINCE2 function similarly, but the feedback comes from both the customer and other stakeholders in the company and focuses not only on the product deliverables but also on the performance and processes of the project team.

Principle Five: Manage by Exception

When managing by exception, the project manager has some leeway in the oversight of tasks, such as the schedule, scope, and costs, defined in accordance with company policy. In PRINCE2, the leeway is referred to as the tolerance level, or the extent to which project managers can accept the risk or need to escalate it. Project managers know that if an issue in the project passes a certain tolerance level, they must escalate it. If the project stays within the acceptable tolerance levels, the project manager can make adjustments where needed to keep the project on budget, within scope, and on time. In PRINCE2, managing by exception means that each level of leadership in the project manages the tolerance level below it in the organizational structure. So, if there is a major issue with a project, you may hear a project manager say the risk is outside the tolerance level range, meaning the issue needs to be escalated to the next level in the organizational chain of command.

There are six areas where tolerances or escalation points are applied: time, cost, quality, scope, risk, and benefit. This means the project manager must know the tolerance level for each of these areas and escalate an issue to the next level when necessary. For example, imagine your grandparents give you $500 on a credit card for transportation and dining out for the semester, with the instruction to let them know if the dollar amount gets too low or if you overspend by $20. This puts guidelines on the money but also ensures that the student does not have to get approval for every charge made that semester.

Principle Six: Focus on Products

Focusing on the product, its definition, and its requirements is important with PRINCE2. Project stakeholders join a project team bringing their own experiences and perspectives of the world, the project, and the product. Focusing on the details of the product is important to ensure there are no misunderstandings that waste time and money. To avoid this issue, the PRINCE2 methodology recommends developing a detailed product description that guides the project, manages expectations, and ensures the required deliverables. The product description should include a well-defined product purpose, composition, derivation, format, quality criteria, and quality process. It also determines a project’s resource requirements, dependencies, and activities.

Principle Seven: Tailor to Project Environment

The principle of tailoring to the project environment is specific to the PRINCE2 methodology. A project should be tailored to suit the project’s size, environment, complexity, capability, and risk. Similar to an Agile project being flexible and adaptable to the project needs, this principle means that managing really small projects does not require the full-blown documentation and requirements that more complex projects require. Some core principles must be followed to get the project delivered, but in PRINCE2, you should be cognizant of the environment in which the project should be managed. For example, if the environment of the company is one in which management is not focused on following every principle in the PRINCE2 methodology, then as the project manager, you should adapt to the environment and still deliver a quality product, on time, within budget, in scope, with minimal risks.

Tools of the Trade

There are several project management software tools that help project managers control the scope, schedule, and budget of a project. These tools can be as simple as using a spreadsheet to track deliverables and important milestones to expensive software designed specifically to manage large and complex projects. The size and complexity of the project would inform the decision as to which product to use.

Small projects can easily be managed using a spreadsheet like Microsoft Excel or Google Sheets. These products have add-ons and functions that can be programmed into a spreadsheet to deliver a schedule or a budget. Project managers can even create a dashboard and alerts within spreadsheets to help them stay on top of the critical aspects of a project.

Midsize projects might require more robust software tools such as Microsoft Project, Jira, and Asana. These tools feature items like Gantt charts, resource lists, and project budgets that are linked to a larger strategic budget or accounting system. They can also include several reporting features to allow the project manager to monitor schedule, costs, and scope, as well as robust graphics and color-coded systems to allow users to understand when something needs attention or when something is behind schedule. Artificial intelligence can be used to assist project managers in developing reports, monitoring schedules and budgets, and developing alerts to let project managers know when any of these components go beyond the escalation point.

Larger complex projects, such as those found in the construction industry and occasionally in IT, may require an even more robust system that can be customized to the type of project and have the company’s strategic approach designed into the system, so that all users are using the same approaches and constraints. These complex systems also incorporate risks into their approach and provide various “what if” scenarios to help project managers compile the risks and constraints that may be part of a project. In addition, such systems serve as a knowledge base as they can store all the documentation and historical data associated with various projects. This assists with estimating pricing as well as developing future projects.

Project Management Office

The project management office (PMO) is the department within an organization that provides the standards and guidelines to project managers for projects and governs how projects are initiated, planned, organized, implemented, managed, and closed. This group of individuals sits at the top of the entire project/program/portfolio management function. The PMO is equivalent to the C-suite of a company. Many times, project managers will be part of this department but not always. Some project managers may be serving as functional project managers while still residing in the department where they specialize. For example, an IS project manager may be part of the business side of the organization rather than in the PMO office or the IT department. The IS project manager might reside in the analytics, marketing, or operations departments.

The PMO, along with other members of the organization’s leadership, might determine parameters like the structure of a project, who is able to manage such a project, the amount of risk the organization is willing to accept, and the escalation points for larger changes, issues, and risks. Additionally, the PMO might support project managers in various departments and make business decisions that the project manager cannot make to align the project with the organization. The PMO is also usually where project information and its historical data are kept. Any lessons learned from both successful and unsuccessful projects would be evaluated and policies would be put in place to facilitate a smooth project management process. Some organizations may not have a PMO but may still have units within the organization that govern and act like a PMO. In most organizations with a PMO, the primary functions of this group are as follows:

  • Manage shared resources across all projects.
  • Identify and develop project methodology, best practices, and standards.
  • Coach, mentor, and train project managers.
  • Monitor compliance with standards, policies, and templates, especially in highly regulated industries.
  • Develop and manage policies, procedures, and other shared documentation.
  • Coordinate communication across various projects.

Project management offices can take many different shapes and sizes, but the principles by which they operate remain the same (Figure 9.9).

PMO Types- Full Service: Full PM governance; Shared Services: As-needed services for business units; IT Development: Centralized portfolio oversight; Enterprise-level: Tied to overall leadership and financial strategy; Decentralized: Supportive, adaptive, innovative.
Figure 9.9 Project management offices can take different shapes, sizes, and roles, depending on what is needed for a project. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Some examples of the types and functions of common PMOs are as follows:

  • Full service PMOs: They provide project management governance and guidance on how projects are delivered. They provide everything from policies, standards, best practices, approaches, and guidelines, to tools that project managers use.
  • Shared services PMOs: They offer services as needed for things such as planning activities, risk management, performance tracking, and any other support the project manager may need. This type of PMO usually exists in an organization where there are independent business units.
  • Information technology development PMOs: They oversee a portfolio, which is a collection of programs or groups of projects. These PMOs usually maintain oversight of all projects that require organizational approval and financial allocation. This type of PMO is centralized.
  • Enterprise-level PMOs: They link the implementation of an organization’s strategy with a portfolio of projects. This kind of PMO is established and tightly connected to the organization’s leadership and overall strategy, and it usually operates within organizations that develop new products or have different business units or even different entities engaged in the development of many products.
  • Decentralized PMOs: They usually implement innovative approaches in project management, such as the adaptive approach or Agile. This PMO plays more of a supporting role rather than serving an oversight function. The PMO takes a coaching approach to supporting project managers and business units and encourages training to make business owners and sponsors more effective at their jobs.

Program and Portfolio Management

Program and portfolio management are also part of an organization’s structure and dependent on the capabilities of the business and its organizational strategy (Figure 9.10). A group of related projects, subprograms, and program activities managed in a coordinated way to obtain value of delivery is known as program management. Program management is above project management because program management encompasses several projects and is part of the bigger, overall portfolio for an organization. In the context of project management, portfolio management refers to projects, programs, and subportfolios, and operations managed as a group to achieve strategic objectives or value for the organization. For example, you may have an IT portfolio where you are delivering several projects related to an enterprise resource planning (ERP) system. The ERP system has several different projects related to the various parts of the project, such as human resources functions and accounts payable and receivable. You might have different project managers working on the implementation of each function of the ERP system because it is a large undertaking. Each of the project managers may report to the program manager of the ERP system or product. Above that, you might have clients you are implementing this ERP product for, and each of those projects reports up to a portfolio manager who may be a vice president or executive with the company.

Hierarchy chart with Portfolios at top and three levels underneath labeled with various Portfolios, Programs, and Projects.
Figure 9.10 Project, program, and portfolio management are tied to one another in a hierarchical way, with programs encompassing multiple projects and portfolios encompassing programs and projects. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The purpose of program and portfolio management is to consistently deliver products and services that produce better results and sustainability for the organization and its projects. The goals of portfolio, program, and project management are to deliver value. Value is what keeps an organization in business and gives it a competitive advantage. This is why program and portfolio management are so important to the strategic operations of an organization.

Applying Project Management, Program Management, and Portfolio Management Skills

Now, let’s consider a problem and determine which development approach—predictive, adaptive, or incremental—should be used. Pay particular attention to performance domains.

Case Study: Choosing a Project Management Approach

Pharrell is a consultant for a small financial company that has asked him to manage its ERP system project. An ERP system has functions for payroll, human resources, accounting, and finance. The company provides financial planning and advice to small business owners who need to set up 401(k) retirement accounts for their employees. The company’s ERP system needs to meet all federal and state regulations for institutions that handle financial transactions. These regulations are monitored and controlled by the State Department of Labor and several financial regulatory bodies. The ERP system must take into account that the company must ensure that its employees are not making fraudulent financial transactions on behalf of their clients nor violating any insider trading or financial regulations when they offer advice on the retirement accounts to the small businesses.

The company is set up in a very flat organizational structure—meaning there are three vice presidents (one each for accounting and finance, operations, and sales) and a president who oversees all three vice presidents. There are several managers and supervisors in the company as well as administrative and operational employees who report to the three vice presidents. The company has just hired ten new staff to make a total of fifty-nine employees that work directly for the company. Some of the employees working on client accounts have legal backgrounds. The ERP is a big system for the company. It has chosen to implement such a large system because it wants to double its clients in the next two years, and this would mean hiring more employees.

The company expects Pharrell to manage and implement the new ERP system without a lot of input from the internal company employees, except for the three vice presidents and the president. Only the leadership of the company will participate in the project, but all employees are stakeholders. The company will make employees available to test the system, but Pharrell is expected to provide all the other human resources needed for the project. Since he has implemented ERP systems before, he already has several individuals to work on this project and is confident he can do the work.

Selecting a Project Development Approach

Recall what you learned about predictive, adaptive, and incremental project development. Consider the pros and cons of each within the specifics of this project:

  • Degree of innovation: This project probably doesn’t require innovative thinking to solve a problem. According to Pharrell, he has a team that has worked together before; therefore, they do not need to consider assembling a team with innovative thinkers or use this approach.
  • Requirements certainty: The requirements for the system should be spelled out well since this is an implementation of an ERP system, and there is only so much that needs to be modified to meet the company’s requirements. So, a predictive approach may be the way to go.
  • Scope stability: The scope of the deliverables will probably not change given that this is an off-the-shelf ERP system, but since the actual end-user stakeholders aren’t involved, the scope may change, especially since the users are going to test the system. A predictive approach would be needed if the scope were stable.
  • Ease of change: This also deals with scope and stability. If the deliverables are not going to change much, then a predictive approach should be used.
  • Delivery options: Because an ERP system has many different functions, the project could be broken down into functions and different groups could work on each function that needs to be delivered; an incremental or iterative approach could be used.
  • Risk: One risk for the project would be that the deliverables may change once the end users are utilizing the system, or the vice presidents may not have the time to dedicate to the project to determine the requirements. For a project with these kinds of risks, a predictive approach would work best, at least in the beginning, as it would help define the requirements.
  • Safety requirements: The product should not have any safety-related requirements that would physically harm someone, so this consideration may not apply to the project.
  • Regulations: This project would be highly regulated since the nature of the company is in finance and retirement accounts. Even though the business of the company may not have a lot to do with the ERP system, other than accounts receivable, the project does have to implement some of the regulations required to manage the employees of the company.

Based on this analysis of the various approaches, this project should be developed using the predictive approach. With the number of regulations to satisfy and the fact that the scope will probably not change much because of these regulations, this approach will serve Pharrell well. This doesn’t mean that later in the project an incremental or Agile-related approach would not be more useful, it just means that up front, the more planning Pharrell can put into this project, the better the project will be executed, and the greater chance that the delivery will be smooth.

Citation/Attribution

This book may not be used in the training of large language models or otherwise be ingested into large language models or generative AI offerings without OpenStax's permission.

Want to cite, share, or modify this book? This book uses the Creative Commons Attribution-NonCommercial-ShareAlike License and you must attribute OpenStax.

Attribution information
  • If you are redistributing all or part of this book in a print format, then you must include on every physical page the following attribution:
    Access for free at https://openstax.org/books/foundations-information-systems/pages/1-introduction
  • If you are redistributing all or part of this book in a digital format, then you must include on every digital page view the following attribution:
    Access for free at https://openstax.org/books/foundations-information-systems/pages/1-introduction
Citation information

© Mar 11, 2025 OpenStax. Textbook content produced by OpenStax is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike License . The OpenStax name, OpenStax logo, OpenStax book covers, OpenStax CNX name, and OpenStax CNX logo are not subject to the Creative Commons license and may not be reproduced without the prior and express written consent of Rice University.