1.1 Purpose and Scope of This Document

This document — the Automated Project Management Process Complete Formal Reference Guide, hereinafter referred to as "this Reference Guide" — establishes the authoritative, comprehensive, and binding procedural framework governing all aspects of automated project management within the organization. It is intended to serve as the singular, unified source of truth for all project personnel, technology administrators, governance bodies, and stakeholder representatives who participate in, oversee, or are impacted by project delivery activities conducted under this process.

The scope of this Reference Guide encompasses the full project management lifecycle, from the initial conception and formal authorization of a project through its controlled closure and archival. It explicitly covers the configuration, operation, and governance of automated tools including, but not limited to, Microsoft Copilot (the artificial intelligence — the technology that uses machine learning and large language model capabilities to assist human users with drafting, summarizing, and analyzing content — hereinafter referred to as "Copilot"), Microsoft Power Automate (the low-code workflow automation platform, hereinafter referred to as "Power Automate"), Microsoft Power Business Intelligence (the business analytics and data visualization platform, hereinafter referred to as "Power Business Intelligence"), Microsoft SharePoint (the collaborative document and list management platform, hereinafter referred to as "SharePoint"), Microsoft Teams (the unified collaboration and communication platform, hereinafter referred to as "Teams"), and Microsoft Dataverse (the scalable cloud data platform underpinning the Microsoft Power Platform, hereinafter referred to as "Dataverse").

This Reference Guide applies to all projects managed under the jurisdiction of the Project Management Office (hereinafter referred to as the "Project Management Office") and is binding upon all personnel — whether full-time employees, contractors, or external consultants — who are formally assigned to any project team governed by this framework. Any deviations from the processes, procedures, and standards set forth in this Reference Guide must be formally authorized in writing by the Project Management Office Director and documented as approved exceptions in the relevant project records.

1.2 Vision for Fully Automated Project Management

The overarching vision governing this Reference Guide is the establishment of an intelligent, integrated, and largely automated project management ecosystem in which administrative burden is systematically minimized, human decision-making is consistently supported by real-time data and artificial intelligence-generated insights, and project governance standards are enforced through technology rather than solely through manual processes. This vision is grounded in the recognition that the manual execution of project management activities — including status collection, risk identification, reporting, change tracking, and stakeholder communication — introduces significant inefficiencies, increases the likelihood of human error, and reduces the speed at which organizational leadership can respond to emerging issues.

The fully automated project management environment envisioned by this Reference Guide leverages the capabilities of the Microsoft 365 (Microsoft's cloud-based productivity and collaboration suite, hereinafter referred to as "Microsoft 365") and Microsoft Power Platform (the integrated suite of low-code development, automation, and analytics tools including Power Automate, Power Business Intelligence, Power Apps, and Dataverse, hereinafter referred to as the "Power Platform") ecosystems to create a seamless, end-to-end flow of project information. In this environment, project data is captured at the point of origination — whether through a team member submitting a status update, a risk being logged, or a milestone being marked complete — and flows automatically through validation, consolidation, notification, escalation, and reporting processes without requiring manual intervention at each step.

It is expressly acknowledged that automation does not replace human judgment. The automated processes defined in this Reference Guide are designed to ensure that the right information reaches the right people at the right time, thereby enabling faster, more informed, and more consistent human decision-making. All automated notifications, escalations, approvals, and reports require human review and, where appropriate, human action. The role of automation is to eliminate low-value administrative tasks so that project professionals can direct their attention toward strategic planning, stakeholder engagement, and problem-solving activities that genuinely require human expertise.

1.3 Integration Architecture Overview

The integration architecture supporting this automated project management process is built entirely within the Microsoft 365 and Power Platform ecosystems, ensuring data residency compliance, security consistency, and operational continuity within a single, governed technology environment. The following tools constitute the core of the integration architecture:

• Microsoft Copilot: The artificial intelligence assistant embedded throughout Microsoft 365 applications and the Power Platform. Copilot is used to draft documents, summarize meeting transcripts, generate risk registers, produce status reports, analyze project data, and provide natural language query capabilities within Power Business Intelligence. Copilot operates within the organization's Microsoft 365 tenant and is governed by the organization's data governance and data loss prevention policies.

• Microsoft Power Automate: The cloud-based workflow automation platform used to build, deploy, and manage all automated flows described in Section 6 of this Reference Guide. Power Automate connects to SharePoint, Teams, Microsoft Planner, Microsoft Forms, Microsoft Outlook, Dataverse, and Power Business Intelligence through certified connectors, enabling event-driven automation across the project management lifecycle.

• Microsoft Power Business Intelligence: The data visualization and business analytics platform used to build and maintain the project management performance dashboards described in Section 7 of this Reference Guide. Power Business Intelligence ingests data from SharePoint lists, Dataverse tables, Microsoft Planner (via the Microsoft Graph Application Programming Interface — the Microsoft application programming interface that enables programmatic access to Microsoft 365 data, hereinafter referred to as the "Microsoft Graph Application Programming Interface"), and external financial systems, and presents this data in role-appropriate visual reports.

• Microsoft SharePoint: The foundational data repository platform for this process. All project lists — including the Project Registry, Risk Register, Issue Log, Status Updates list, Budget Tracking list, Change Request log, Stakeholder Register, and Lessons Learned Register — are hosted in SharePoint. SharePoint also serves as the document management system for all project artifacts, including charters, plans, reports, and meeting records.

• Microsoft Teams: The primary communication and collaboration platform for all project-related interactions. Teams serves as the delivery channel for automated notifications, adaptive card approvals, meeting management, and real-time project collaboration. Each project is provisioned with a dedicated Teams environment with structured channels as defined in Section 9.5 of this Reference Guide.

• Microsoft Dataverse: The enterprise-grade data platform used to store structured project data that requires relational integrity, advanced security controls, and Power Platform integration. Dataverse is used for Copilot data grounding, advanced workflow state management, and integration with the broader Power Platform ecosystem including Power Apps (the low-code application development platform within the Power Platform).

The following table provides a high-level summary of the tool integration architecture:

1.4 Alignment with the Project Management Body of Knowledge, Seventh Edition

This Reference Guide is expressly designed to align with and operationalize the standards, principles, and performance domain framework established by the Project Management Institute (the globally recognized professional association for project management, hereinafter referred to as the "Project Management Institute") in its Project Management Body of Knowledge, Seventh Edition (the authoritative guide to the knowledge, skills, and principles essential for effective project management practice, hereinafter referred to as the "Project Management Body of Knowledge Seventh Edition"). The Project Management Body of Knowledge Seventh Edition represents a principles-based evolution from its predecessor editions, emphasizing outcomes-driven delivery, adaptive approaches, and stakeholder value over prescriptive process compliance alone.

This Reference Guide maps the automated processes and governance structures defined herein to the eight performance domains of the Project Management Body of Knowledge Seventh Edition — specifically: the Stakeholder Performance Domain, the Team Performance Domain, the Development Approach and Life Cycle Performance Domain, the Planning Performance Domain, the Project Work Performance Domain, the Delivery Performance Domain, the Measurement Performance Domain, and the Uncertainty Performance Domain. Additionally, all twelve guiding principles of the Project Management Body of Knowledge Seventh Edition are embedded into the governance, automation, and human-review elements of this process, as detailed in Section 4 of this Reference Guide. The practical embodiment of these principles and performance domains in the specific automated workflows, quality gates, and escalation procedures defined in this Reference Guide ensures that compliance with Project Management Institute standards is not merely aspirational but is systematically enforced at the process level.

1.5 Governing Authority, Document Owner, and Version Control

The governing authority for this Reference Guide is the Project Management Office, which operates under the direction of the Project Management Office Director. The Project Management Office Director is responsible for ensuring that this Reference Guide remains current, accurate, and aligned with organizational strategy, applicable standards, and evolving technology capabilities. The Project Management Office Director may delegate specific governance responsibilities to the Microsoft Copilot Coordinator and the Microsoft Power Platform Administrator, as defined in Section 2 of this Reference Guide, but ultimate accountability for this Reference Guide rests with the Project Management Office Director.

This Reference Guide is subject to formal review on an annual basis or upon the occurrence of any of the following triggering events: a material change to the Microsoft 365 or Power Platform toolset; a revision to the Project Management Body of Knowledge or other governing Project Management Institute standards; a significant organizational restructuring affecting project governance; or a formal audit finding that requires process changes. All revisions must follow the change control process defined in Section 11 of this Reference Guide, and all approved versions must be recorded in the Version Control Table above. The most current approved version of this Reference Guide shall be maintained in the Project Management Office document library on SharePoint and shall supersede all prior versions upon its effective date.

2.1 Role Definitions

2.2 RACI Matrix

The following RACI (Responsible, Accountable, Consulted, Informed) matrix defines the roles and responsibilities of each participant across the key deliverables and processes of this automated project management framework. The following codes apply throughout this matrix: R = Responsible (the individual who performs or leads the task), A = Accountable (the individual who is ultimately answerable for the correct and thorough completion of the task — there is only one Accountable party per row), C = Consulted (individuals whose input is sought; two-way communication), and I = Informed (individuals who are notified of outcomes; one-way communication).

3.1 Project Title and Unique Identifier

The Project Title is the official designation of the project as recognized throughout all project documentation, reporting systems, and organizational communications. The title must be clear, descriptive, and approved by the Project Management Office. The Project Unique Identifier is a system-generated alphanumeric code assigned automatically by the Power Automate project intake flow upon formal submission of the Project Charter for approval. This identifier serves as the primary key linking all project records across SharePoint, Planner, Dataverse, and Power Business Intelligence.

3.2 Project Purpose and Business Justification

This section must articulate the strategic rationale for undertaking the project, the organizational problem or opportunity being addressed, and the expected contribution of the project to one or more organizational objectives or key performance indicators (quantifiable measurements of organizational performance against defined targets, hereinafter referred to as "key performance indicators"). The Business Justification must reference the specific business case or strategic plan from which the project is derived, and must explain why this project is the preferred solution over identified alternatives.

3.3 Project Objectives (SMART Format)

All project objectives must be written in Specific, Measurable, Achievable, Relevant, and Time-bound (hereinafter referred to as "SMART") format, in accordance with the Project Management Institute's guidance on defining project success criteria. Each objective must identify a specific, quantifiable outcome, the metric by which success will be measured, the evidence that the objective is realistically achievable within the project's constraints, the connection of the objective to a business benefit, and the specific date by which the objective must be achieved. The Project Manager, in collaboration with the Business Analyst and key stakeholders, is responsible for drafting and validating all project objectives.

3.4 Project Scope

3.5 High-Level Deliverables and Milestones

The following table presents the high-level deliverables and key milestones of the project. This information is used to populate the initial project schedule in Microsoft Planner and the milestones view in the Power Business Intelligence dashboard. Each milestone represents a significant point in the project timeline and triggers the automated gate review process defined in Flow 6.4. All milestone dates are subject to revision through the formal change control process.

3.6 Assumptions, Constraints, and Dependencies

3.7 Risk Summary

This section provides a high-level summary of the most significant risks identified during the project initiation phase. A full risk assessment will be conducted during the planning phase, and all risks will be entered into the SharePoint Risk Register and actively monitored through the automated processes defined in Section 10 of this Reference Guide. The following table captures the initial risks identified at the time of charter development.

3.8 Budget Authorization and Financial Thresholds

This section formally authorizes the initial budget allocation for the project and establishes the financial thresholds that govern automated alerts, escalation requirements, and approval authority levels. All expenditures must be approved in accordance with the authority matrix below and processed through the automated procurement flows defined in Section 12.5. Any expenditure that would cause the actual cost to exceed the approved budget by more than ten percent will trigger the automated budget variance alert defined in Flow 6.5.

3.9 Stakeholder Register (Initial)

The following table presents the initial Stakeholder Register as developed during the project initiation phase. The full Stakeholder Register will be maintained as a living document in SharePoint throughout the project lifecycle and will be updated as new stakeholders are identified or as existing stakeholders' engagement levels, interests, or influence change. New stakeholders added to this register will trigger the automated onboarding process defined in Flow 6.6.

3.10 Project Authority and Governance Structure

The governance structure for this project is defined in accordance with the roles and responsibilities established in Section 2 of this Reference Guide. The following table clarifies the specific levels of decision-making authority applicable to this project. All decisions exceeding the Project Manager's authority must be escalated through the appropriate channel as defined in the escalation path outlined in Section 9.3 of this Reference Guide.

3.11 Sign-off and Approval Block

The formal execution of this Project Charter by the individuals identified below constitutes their official authorization of the project as described in this document and their agreement to provide the resources, governance, and support necessary for project success. Digital signatures collected through the automated approval flow in Microsoft Teams are legally equivalent to handwritten signatures for the purposes of this document.

4.1 Initiating Phase

Entry Criteria: A formal business case or strategic directive has been approved by the Portfolio Manager, and the project has been placed in the project intake queue on the Project Management Office SharePoint site. Sufficient budget authority exists to fund at minimum the planning phase, and an Executive Sponsor has been identified and has agreed to fulfill the role as defined in Section 2.1 of this Reference Guide.

Key Activities: During the Initiating Phase, the Project Manager drafts the Project Charter using the template defined in Section 3, leveraging Copilot to analyze stakeholder inputs, summarize the business case, and generate an initial risk register. The Business Analyst conducts stakeholder identification workshops, and the Risk Manager performs an initial risk screening. The Communications Manager develops the preliminary stakeholder register. The Power Automate project intake flow assigns the project its unique identifier and creates the project SharePoint site, Teams environment, and initial Planner board.

Responsible Roles: Executive Sponsor (accountable), Project Manager (responsible for charter), Business Analyst (responsible for stakeholder identification), Risk Manager (responsible for initial risk screening), Communications Manager (responsible for stakeholder register), Microsoft Power Platform Administrator (responsible for project site provisioning).

Deliverables Produced: Approved Project Charter, initial Stakeholder Register, initial Risk Register, provisioned SharePoint project site, provisioned Teams environment, provisioned Planner board.

Exit Criteria: The Project Charter has been formally approved and digitally signed by all parties identified in Section 3.11. The project unique identifier has been assigned and is active in the Project Registry SharePoint list. The project SharePoint site, Teams channels, and Planner board have been provisioned and are accessible to all assigned team members.

Quality Gate — Gate 1 (Charter Approval): The Quality Assurance Manager reviews the Project Charter against the mandatory template requirements defined in Section 3 and confirms that all mandatory fields are complete, all objectives are written in Specific, Measurable, Achievable, Relevant, Time-bound format, all required signatories have approved, and the project unique identifier has been properly registered. Gate 1 is formally passed only upon the Quality Assurance Manager's documented concurrence.

4.2 Planning Phase

Entry Criteria: Gate 1 has been formally passed. The approved Project Charter is accessible on the project SharePoint site. The Project Manager has been formally assigned and has accepted their role. The project Teams environment is active and all team members have been granted access.

Key Activities: The Planning Phase is the most documentation-intensive phase of the project lifecycle and results in the creation of the comprehensive Project Management Plan. During this phase, Copilot assists the Project Manager and Business Analyst in generating the Work Breakdown Structure, drafting the project schedule, producing the Communication Plan, and structuring the Risk Management Plan. The Work Breakdown Structure is populated into Microsoft Planner as a structured task hierarchy. The project schedule is developed using rolling wave planning — a technique in which near-term work is planned in detail while future work is planned at a higher level, with detail added progressively as the project advances — to accommodate uncertainty in later phases. The Finance Controller reviews and baselines the budget plan, and the Risk Manager completes the full risk assessment for all identified risks.

Responsible Roles: Project Manager (accountable and responsible for Project Management Plan), Business Analyst (responsible for requirements documentation and Work Breakdown Structure), Risk Manager (responsible for Risk Management Plan), Quality Assurance Manager (responsible for Quality Management Plan), Communications Manager (responsible for Communication Plan), Finance Controller (responsible for budget baseline), Technical Lead and Solution Architect (responsible for technical approach documentation).

Deliverables Produced: Project Management Plan (inclusive of all subsidiary plans: Scope Management Plan, Schedule Management Plan, Cost Management Plan, Quality Management Plan, Resource Management Plan, Communication Plan, Risk Management Plan, Procurement Management Plan, Stakeholder Engagement Plan), Work Breakdown Structure, Project Schedule Baseline, Cost Baseline, Risk Register (full), Stakeholder Engagement Plan.

Exit Criteria: The Project Management Plan and all subsidiary plans have been reviewed by the Quality Assurance Manager, approved by the Project Manager, and endorsed by the Project Steering Committee. All baseline documents — schedule, cost, scope — have been locked in SharePoint and are protected against uncontrolled modification.

Quality Gate — Gate 2 (Planning Baseline Approval): The Quality Assurance Manager reviews all subsidiary plans for completeness against defined templates. The Project Management Office Director confirms alignment with organizational methodology standards. The Finance Controller confirms budget baseline accuracy. Only upon documented approval from all three reviewers does Gate 2 pass and execution activities commence.

4.3 Executing Phase

Entry Criteria: Gate 2 has been formally passed. All required resources — including personnel, technology licenses, and vendor contracts — have been confirmed as available and are ready to support the commencement of execution activities. The project schedule, as reflected in Microsoft Planner, is populated with all tasks and assignments for at minimum the first planning horizon.

Key Activities: During the Executing Phase, Project Team Members perform the work of the project as defined in the Work Breakdown Structure and tracked in Microsoft Planner. The Project Manager directs and manages project work, conducts regular team meetings in Teams, and uses Copilot to summarize meeting transcripts and extract action items for automatic creation in Planner. The Communications Manager executes the Communication Plan, including automated weekly status reports generated through the Power Automate flow defined in Section 6.1. The Quality Assurance Manager conducts ongoing quality assurance activities as defined in Section 8.2. The Risk Manager monitors the Risk Register and responds to automated alerts generated by Flow 6.2.

Responsible Roles: Project Manager (accountable), all Project Team Members (responsible for assigned tasks), Quality Assurance Manager (responsible for quality assurance), Risk Manager (responsible for risk monitoring), Communications Manager (responsible for communication execution), Deputy Project Manager (responsible for day-to-day administrative management).

Deliverables Produced: Completed Work Breakdown Structure deliverables (as defined in the project-specific Work Breakdown Structure), Quality Assurance audit reports, weekly Status Reports, meeting records and action item logs, updated Risk Register, updated Issue Log.

Exit Criteria: All Work Breakdown Structure deliverables for the Executing Phase have been completed, reviewed, and accepted by the designated approvers. All open issues and risks have been assessed and have active response plans. All milestone deliverables due within this phase have been completed and have passed Gate 3.

Quality Gate — Gate 3 (Executing Phase Milestones): For each milestone within the Executing Phase, the automated gate review process defined in Flow 6.4 is triggered. The Project Steering Committee reviews the gate review package and provides formal digital approval or rejection via Teams adaptive card. The Quality Assurance Manager must confirm the deliverable has passed all applicable quality control checks before the gate review package is transmitted to the Steering Committee.

4.4 Monitoring and Controlling Phase

Entry Criteria: The Executing Phase has commenced and project performance data is being generated. The Power Business Intelligence dashboard is populated with at minimum one full cycle of status data, and the project schedule and budget baselines are active and locked.

Key Activities: The Monitoring and Controlling Phase runs concurrently with the Executing Phase throughout the project lifecycle. The Project Manager and Deputy Project Manager review the Power Business Intelligence dashboard on a daily basis to monitor Schedule Performance Index (the ratio of Earned Value to Planned Value, indicating schedule efficiency, hereinafter referred to as the "Schedule Performance Index") and Cost Performance Index (the ratio of Earned Value to Actual Cost, indicating cost efficiency, hereinafter referred to as the "Cost Performance Index") trends. Copilot analyzes project performance data to identify variances and recommend corrective actions. Automated Power Automate flows alert the appropriate roles when thresholds are breached. The Change Control Board reviews and decides upon all submitted change requests through the automated process defined in Flow 6.3. The Risk Manager reviews and updates the Risk Register on a weekly basis.

Responsible Roles: Project Manager (accountable), Deputy Project Manager (responsible for daily monitoring), Risk Manager (responsible for risk monitoring), Finance Controller (responsible for budget monitoring), Quality Assurance Manager (responsible for quality control), Change Control Board (responsible for change decisions).

Deliverables Produced: Performance reports, Earned Value Analysis (a methodology that integrates scope, schedule, and cost performance data to provide a comprehensive picture of project performance, hereinafter referred to as "Earned Value Analysis") reports, corrective and preventive action records, approved or rejected Change Requests, updated project baselines (where changes are approved), variance analysis reports.

Exit Criteria: All project deliverables have been completed and accepted, all open Change Requests have been resolved, and the project is ready to transition to formal closure. The Schedule Performance Index and Cost Performance Index values are within acceptable thresholds, or documented corrective actions have been implemented and are producing the expected improvement.

Quality Gate — Gate 4 (Pre-Closing Readiness Review): The Project Manager, Quality Assurance Manager, and Finance Controller jointly confirm that all deliverables have been formally accepted, all change requests are closed, all invoices have been processed, and all outstanding risks and issues have been resolved or formally accepted. Only upon this joint confirmation does the project advance to the Closing Phase.

4.5 Closing Phase

Entry Criteria: Gate 4 has been formally passed. The customer or authorizing entity has formally accepted all project deliverables. The project status has been updated to "Closing" in the Project Registry SharePoint list, which triggers the automated Lessons Learned Collection Flow defined in Flow 6.7.

Key Activities: During the Closing Phase, the Project Manager coordinates the formal acceptance of all deliverables, closes all vendor contracts, facilitates the lessons learned process, and ensures the orderly transition of project outputs to the operations team. Copilot generates the draft lessons learned document and the project closure report based on the consolidated lessons learned survey responses and project performance data. All project documents are archived in the designated SharePoint archive folder. The project site is set to read-only and remains accessible for reference purposes in accordance with the retention policy defined in Section 13.5.

Responsible Roles: Executive Sponsor (accountable for formal closure), Project Manager (responsible for closure activities), Procurement Officer (responsible for contract closeout), Communications Manager (responsible for final stakeholder communications), Microsoft Power Platform Administrator (responsible for archiving Power Platform resources).

Deliverables Produced: Final Project Closure Report, Lessons Learned Register, Benefits Realization Report, archived project document library, final Stakeholder Register, archived Planner board.

Exit Criteria: The Executive Sponsor has formally signed the Project Closure Report. All project documents are archived. All contracts are closed. The project status in the Project Registry has been updated to "Closed." Power Automate flows specific to this project have been deactivated by the Microsoft Power Platform Administrator.

Quality Gate — Gate 5 (Formal Project Closure): The Project Management Office Director reviews the Project Closure Report and Lessons Learned Register for completeness. The Finance Controller confirms all financial obligations have been settled. The Executive Sponsor provides final digital approval of the project closure. Only upon the Executive Sponsor's approval is the project formally closed.

4.6 Stakeholder Performance Domain

The Stakeholder Performance Domain encompasses all activities and functions associated with identifying, analyzing, and engaging project stakeholders effectively throughout the project lifecycle. Effective stakeholder engagement is a critical determinant of project success, as stakeholders who are insufficiently engaged or whose interests are inadequately addressed can withhold support, introduce obstacles, or actively oppose project activities. This domain recognizes that stakeholder engagement is not a one-time activity confined to the initiating phase but a continuous, adaptive process that evolves as stakeholder interests, influence levels, and engagement states change over time.

Under this automated project management process, stakeholder engagement activities are systematically supported through the automated onboarding flow defined in Flow 6.6, the communication delivery mechanisms defined in Section 9, and the Stakeholder Engagement Classification model defined in Section 9.4. The Communications Manager is the primary role responsible for this performance domain and works in conjunction with Copilot to draft tailored stakeholder communications that reflect the individual interests, influence levels, and preferred communication channels of each stakeholder. Stakeholder engagement assessments are conducted at each gate review and updated in the Stakeholder Register accordingly.

4.7 Team Performance Domain

The Team Performance Domain addresses the activities and functions associated with establishing an effective, collaborative, and high-performing project team. This domain encompasses team development from the initial forming of the team through the norming, performing, and adjourning stages described in Tuckman's model of team development. It includes establishing a shared team culture, clarifying individual roles and responsibilities, providing development opportunities, addressing performance issues, and managing conflict constructively and professionally.

Under this automated process, team health is monitored indirectly through the Resource and Team Utilization dashboard page in Power Business Intelligence, which tracks individual workload, utilization rates, and overtime alerts. The Project Manager uses this data to identify and address capacity imbalances, prevent burnout, and ensure equitable work distribution. Conflict resolution follows a structured escalation path: the Project Manager first attempts to resolve conflict through direct facilitation; if unresolved, the matter is escalated to the Project Steering Committee and, if necessary, to the Executive Sponsor for final resolution.

4.8 Development Approach and Life Cycle Performance Domain

The Development Approach and Life Cycle Performance Domain addresses the selection and tailoring of the project life cycle — predictive, agile, or hybrid — best suited to the nature, complexity, and uncertainty of the specific project. A predictive (also known as "waterfall") approach is appropriate for projects with well-defined, stable requirements, high certainty, and a clear understanding of the solution, where scope is defined comprehensively upfront and work proceeds sequentially through planned phases. An agile approach is appropriate for projects with high uncertainty, evolving requirements, or where early and continuous delivery of value is prioritized, using iterative cycles (called "sprints" or "iterations") of planning, execution, and review. A hybrid approach combines elements of both, typically using predictive methods for governance and overall schedule management while using agile methods for specific delivery components.

Under this Reference Guide, the development approach for each project is formally selected during the Initiating Phase and documented in the Project Charter. The choice of approach directly determines how the project schedule is structured in Microsoft Planner — sequentially for predictive approaches, or in sprint cycles for agile approaches — and how status reporting, milestone gates, and quality reviews are configured. The Microsoft Power Platform Administrator is responsible for configuring the appropriate Planner board structure and Power Automate flow triggers to reflect the chosen development approach.

4.9 Planning Performance Domain

The Planning Performance Domain addresses the activities and functions associated with the initial and ongoing organization, elaboration, and coordination of the work required to deliver the project's outcomes. Planning under the Project Management Body of Knowledge Seventh Edition is explicitly recognized as a continuous, iterative process rather than a single, front-loaded event. Rolling wave planning — the technique of planning near-term work in comprehensive detail while planning future work at a higher level of abstraction, progressively elaborating the plan as more information becomes available — is the preferred planning approach for all projects governed by this Reference Guide.

Under this automated process, planning activities are supported by Copilot's ability to generate initial Work Breakdown Structure drafts, project schedule structures, and communication plan templates based on the approved Project Charter and requirements documentation. These Copilot-generated drafts are reviewed, validated, and refined by the Project Manager and relevant subject matter experts before being approved and baselined. All planning artifacts are version-controlled in the project SharePoint document library, and any post-baseline changes must pass through the change control process defined in Section 11.

4.10 Project Work Performance Domain

The Project Work Performance Domain addresses the activities and functions associated with establishing project processes, managing the physical resources of the project, fostering a learning environment, and coordinating ongoing project work to produce the intended deliverables. This domain encompasses the day-to-day operational management of the project, including directing and managing project work, managing project knowledge, monitoring work performance, and implementing approved changes and corrective actions.

Under this automated process, the Project Work Performance Domain is supported by the weekly status collection flow defined in Flow 6.1, which ensures a consistent, automated mechanism for gathering work performance data from all Project Team Members. The action item tracking flow defined in Flow 6.8 ensures that all commitments made in project meetings are captured, assigned, and followed up automatically. The Project Manager reviews consolidated work performance data through the Power Business Intelligence Individual Project Health Dashboard each week and uses this data to make informed decisions about resource reallocation, scope prioritization, and corrective action implementation.

4.11 Delivery Performance Domain

The Delivery Performance Domain addresses the activities and functions associated with delivering the scope and quality of the project that meet stakeholder expectations and create the intended value. This domain emphasizes that delivery is not merely the production of outputs (tangible artifacts or products) but the creation of outcomes (changes in behavior or capability) and ultimately the realization of benefits (improvements to organizational performance) that justify the investment in the project. Effective delivery requires maintaining clear traceability from business objectives through deliverables to benefits throughout the project lifecycle.

Under this automated process, the Delivery Performance Domain is supported by the milestone gate review mechanism defined in Flow 6.4, which provides structured checkpoints at which the Project Steering Committee formally evaluates whether completed deliverables meet the acceptance criteria defined in the Project Charter and subsidiary plans. Deliverable acceptance records are stored in SharePoint and are incorporated into the Power Business Intelligence Work Breakdown Structure completion percentage metric. The Benefits Realization Report produced during the Closing Phase, as described in Section 13.4, formally documents the extent to which the intended benefits have been realized or are on track for realization post-project.

4.12 Measurement Performance Domain

The Measurement Performance Domain addresses the activities and functions associated with assessing project performance and implementing appropriate responses to maintain optimal performance. Effective measurement in the context of the Project Management Body of Knowledge Seventh Edition requires identifying the right metrics, collecting accurate and timely data, analyzing data to understand what is happening and why, communicating findings to the right audiences, and using insights to drive informed decisions and corrective actions. Measurement must be purposeful — metrics should be selected because they provide actionable insight, not merely because they are easy to collect.

The primary performance metrics used under this automated process are those of Earned Value Analysis, including Planned Value (the authorized budget assigned to work scheduled to be accomplished at a given point in time), Earned Value (the authorized budget associated with work that has actually been accomplished), Actual Cost (the realized cost incurred for work accomplished on the project), Schedule Variance (Earned Value minus Planned Value — a positive value indicates ahead of schedule; a negative value indicates behind schedule), Cost Variance (Earned Value minus Actual Cost — a positive value indicates under budget; a negative value indicates over budget), Schedule Performance Index, Cost Performance Index, Estimate at Completion (the expected total cost of completing all project work, calculated as Actual Cost plus the Estimate to Complete — the expected cost needed to finish all the remaining project work), and Variance at Completion (the difference between the Budget at Completion — the total approved budget for the project — and the Estimate at Completion). These metrics are calculated automatically by Power Business Intelligence from the data collected through the automated status collection and budget tracking flows and are displayed on the Individual Project Health Dashboard described in Section 7.3.

4.13 Uncertainty Performance Domain

The Uncertainty Performance Domain addresses the activities and functions associated with navigating risk, ambiguity, complexity, and volatility throughout the project lifecycle. The Project Management Body of Knowledge Seventh Edition defines uncertainty not merely as risk — the possibility of an event occurring that has an effect on the project — but as a broader category that includes ambiguity (the lack of clarity about requirements, solutions, or the project environment), complexity (the result of human behavior, system interactions, and ambiguity that make projects difficult to manage using linear, reductionist approaches), and volatility (the speed and unpredictability of change in the project environment).

Under this automated process, the Uncertainty Performance Domain is addressed through the comprehensive risk management framework defined in Section 10, the automated risk escalation flows defined in Flow 6.2, the real-time risk monitoring capabilities of the Power Business Intelligence Risk and Issue Management View, and the adaptive planning techniques — including rolling wave planning and the maintenance of contingency reserves — embedded throughout this Reference Guide. The Risk Manager is the primary role responsible for this performance domain, supported by all Project Team Members who are required to log risks and issues as they are identified and to participate in periodic risk reviews.

4.14 The Twelve Guiding Principles of the Project Management Body of Knowledge Seventh Edition

The following twelve guiding principles, as established in the Project Management Body of Knowledge Seventh Edition, are embedded throughout all processes, governance structures, and automated workflows defined in this Reference Guide. Each principle is described below, along with an explanation of how it is operationalized within this automated project management process.

5.1 Copilot in the Initiating Phase

During the Initiating Phase, Copilot is used primarily to accelerate the drafting of foundational project documents and to synthesize stakeholder input into structured, actionable formats. The Project Manager uses Copilot in Microsoft Word to generate an initial draft of the Project Charter based on the approved business case and the Project Charter template defined in Section 3. Copilot analyzes the business case document and prompts the Project Manager with questions to fill any identified gaps in the charter's mandatory fields, reducing the time required to produce a complete first draft from hours to minutes while ensuring comprehensive coverage of all required content areas.

Copilot in Microsoft Teams is used during the initial stakeholder identification workshops to generate real-time summaries of meeting discussions, capturing key stakeholder interests, concerns, and requirements as they are articulated. These summaries are saved to the project SharePoint site and reviewed by the Business Analyst for accuracy before being incorporated into the Stakeholder Register. Additionally, Copilot in SharePoint is used to generate an initial risk register by analyzing the Project Charter, business case, and any prior related project documentation, identifying potential risk themes and drafting initial risk descriptions for review by the Risk Manager. This Copilot-assisted risk identification process ensures that the initial risk register is comprehensive and that no major risk categories are overlooked.

5.2 Copilot in the Planning Phase

During the Planning Phase, Copilot's document generation capabilities are used extensively to produce the subsidiary plans that comprise the Project Management Plan. Using the approved Project Charter and requirements documentation as input, Copilot generates initial drafts of the Work Breakdown Structure, project schedule structure, Communication Plan, and Risk Management Plan. The Project Manager and relevant subject matter experts review, refine, and validate each of these Copilot-generated drafts before they are finalized and baselined. Copilot's ability to generate comprehensive first drafts significantly accelerates the planning process while ensuring that all mandatory plan components are addressed.

Copilot in Microsoft Planner — accessed through the Teams interface — assists the Project Manager in decomposing the Work Breakdown Structure into specific tasks, assigning estimated durations, identifying dependencies, and organizing tasks into a logical sequence. Copilot can also suggest resource assignments based on team member skill profiles documented in Dataverse. Additionally, Copilot generates the Communication Plan by analyzing the Stakeholder Register and proposing tailored communication strategies, frequencies, and channels for each stakeholder group, which the Communications Manager then refines to reflect organizational norms and stakeholder preferences.

5.3 Copilot in the Executing Phase

During the Executing Phase, Copilot's meeting intelligence capabilities — specifically, the ability to generate post-meeting summaries, extract action items, and identify key decisions from Microsoft Teams meeting transcripts — are among its most valuable and frequently used features. At the conclusion of every project meeting conducted in Teams, Copilot automatically generates a structured meeting summary that includes a brief narrative overview of the topics discussed, a bulleted list of all action items identified (with proposed owners and due dates), a list of decisions made, and a list of open questions requiring follow-up. The Project Manager reviews this summary for accuracy and, upon approval, it is saved to the project SharePoint site. The confirmed action items are then automatically created as tasks in Microsoft Planner through the action item tracking flow defined in Flow 6.8.

Copilot is also used during the Executing Phase to draft weekly project status reports. The Deputy Project Manager provides Copilot with the current week's status data — consolidated from the automated status collection flow defined in Flow 6.1 — and prompts Copilot to generate a formal, professional status report in the organization's standard format. Copilot produces a draft that includes narrative summaries of schedule status, budget status, risk status, and key accomplishments, which the Project Manager reviews and finalizes before distribution to stakeholders in accordance with the Communication Plan.

5.4 Copilot in the Monitoring and Controlling Phase

During the Monitoring and Controlling Phase, Copilot's data analysis capabilities — particularly its integration with Power Business Intelligence — are used to provide the Project Manager with intelligent, contextualized insights about project performance. Using natural language queries within Power Business Intelligence, the Project Manager can ask questions such as "Which tasks are most at risk of causing a schedule delay?" or "What is the projected Estimate at Completion if the current Cost Performance Index trend continues?" and receive immediate, data-grounded responses. Copilot in Power Business Intelligence analyzes the project's Earned Value Analysis metrics, schedule status, risk register, and budget actuals to generate these insights, and can automatically produce narrative explanations of anomalies or trends detected in the project data.

When the Power Business Intelligence dashboard or automated Power Automate flows identify a performance variance that exceeds defined thresholds, Copilot is used to assist the Project Manager in drafting corrective action recommendations. The Project Manager provides Copilot with the performance data and the nature of the variance, and Copilot generates a set of potential corrective actions, with pros and cons for each option, that the Project Manager can use as a starting point for decision-making. All Copilot-generated corrective action recommendations require human review and explicit approval before implementation.

5.5 Copilot in the Closing Phase

During the Closing Phase, Copilot's document generation capabilities are used to produce the project's closing documentation efficiently and comprehensively. Upon the triggering of the Lessons Learned Collection Flow defined in Flow 6.7, Copilot analyzes the consolidated lessons learned survey responses from all project participants and generates a structured, thematically organized lessons learned document that identifies recurring themes, highlights the most impactful lessons, and proposes specific process improvements for consideration in future projects. The Project Manager reviews this Copilot-generated document and adds their own qualitative assessment before it is finalized and stored in the Lessons Learned Register on SharePoint.

Copilot is also used to generate the Project Closure Report, which provides a comprehensive retrospective assessment of the project's performance against its original objectives, scope, schedule, budget, and quality targets. Copilot produces this report by analyzing the project's performance data from Power Business Intelligence, the approved Project Charter objectives, and the final status records in SharePoint. The Project Manager refines the Copilot-generated draft with qualitative context and lessons learned before presenting the final report to the Executive Sponsor for formal approval. Additionally, Copilot generates a summary of all formal deliverable acceptance records, consolidated from the individual acceptance records stored in SharePoint throughout the project lifecycle, for inclusion in the closure documentation package.

5.6 Copilot in Microsoft Power Automate

Copilot in Power Automate enables the Microsoft Power Platform Administrator and project team members to create, describe, and troubleshoot automated workflows using natural language rather than requiring deep technical expertise in Power Automate's visual interface. Using the "Describe your flow" feature, an administrator can describe the desired automation behavior in plain English — for example, "When a new item is added to the Risk Register list in SharePoint, if the severity rating is four or five, send a Teams message to the Risk Manager and Project Manager" — and Copilot will generate a draft Power Automate flow implementing that behavior, which the administrator then reviews, validates, and refines before activating.

Additionally, Copilot in Power Automate is used to generate comprehensive documentation for each automated flow — including a plain-language description of the flow's purpose, trigger, logic, actions, and error handling behavior — which is stored in the Microsoft Power Platform Administrator's documentation library in SharePoint. This documentation is essential for the ongoing maintenance and governance of the automated flows and ensures that any authorized administrator can understand, modify, or troubleshoot any flow without relying on undocumented institutional knowledge. Copilot can also assist in diagnosing failed flow runs by analyzing error messages and run history logs and suggesting potential root causes and remediation steps.

5.7 Copilot in Microsoft Power Business Intelligence

Copilot in Power Business Intelligence provides project stakeholders with the ability to query project data using natural language, enabling individuals who are not trained in Power Business Intelligence report authoring to obtain specific data insights on demand without requiring the assistance of the Microsoft Power Platform Administrator or a report developer. For example, an Executive Sponsor can navigate to the Power Business Intelligence dashboard and ask "Show me all projects where the Cost Performance Index is below 0.9 and the projected completion date has slipped by more than thirty days" and receive an immediate, formatted answer derived from the project performance data model.

Copilot also generates automated narrative descriptions of dashboard pages — plain-language summaries of key findings, trends, and anomalies visible in the visual reports — that are updated each time the data model is refreshed. These narratives are particularly useful for stakeholders who consume reports in email distribution format rather than interactively through the Power Business Intelligence service, as they provide a concise, intelligible summary of the most important information without requiring the recipient to navigate the full visual dashboard. Additionally, Copilot in Power Business Intelligence supports automated anomaly detection — the identification of data points that deviate significantly from expected patterns or historical norms — and generates alerts when anomalies are detected in project performance data, which are routed to the appropriate role through the Power Automate notification flows.

5.8 Copilot Governance and Prompt Engineering Standards

The governance of Copilot usage within this automated project management process is the responsibility of the Microsoft Copilot Coordinator, in coordination with the Microsoft Power Platform Administrator. All project personnel who use Copilot are required to complete the Copilot onboarding training program administered by the Microsoft Copilot Coordinator before using Copilot for any project-related activity. This training covers the capabilities and limitations of Copilot, the approved use cases defined in the approved prompt library in Appendix G, data privacy and sensitivity requirements, and the mandatory human review requirement that applies to all Copilot-generated content.

The following governance standards apply to all Copilot usage under this Reference Guide:

• Human Review Requirement: All content generated by Copilot — including drafted documents, summaries, risk register entries, action items, and data analysis narratives — must be reviewed and approved by a qualified human reviewer before being used for any official project purpose, published to any SharePoint site, sent to any stakeholder, or recorded in any formal project record. The identity of the reviewing human and the date of their review must be documented.

• Sensitive Data Prohibition: Personnel must not input personally identifiable information (information that can be used to identify a specific individual, hereinafter referred to as "personally identifiable information"), protected health information, classified information, or any data subject to contractual or regulatory confidentiality restrictions into Copilot prompts without explicit authorization from the Data Governance Officer and the organization's Privacy Officer. The approved prompt library in Appendix G identifies which prompts involve sensitive data considerations.

• Approved Prompt Library Requirement: All Copilot prompts used for recurring, standardized project management activities — such as charter drafting, status report generation, lessons learned synthesis, and risk register generation — must be drawn from or modeled on the approved prompt library defined in Appendix G. Customizations to approved prompts are permitted, provided the customization does not introduce sensitive data inputs or deviate materially from the approved prompt's intended use case.

• Attribution Requirement: All Copilot-generated content incorporated into official project documents must be identified as having been produced with Copilot assistance in the document's revision history, in accordance with the organization's intellectual property and attribution policy.

• Periodic Governance Review: The Microsoft Copilot Coordinator will conduct a quarterly review of Copilot usage logs, approved prompt library currency, and compliance with data privacy requirements, and will report findings to the Project Management Office Director and the Data Governance Officer.

6.1 Weekly Project Status Collection Flow

Conditions and Logic Branches:

• If the current date is listed in the Holiday Exclusion List in SharePoint, the flow terminates without sending notifications and logs a "Holiday Skip" record in the flow execution log in SharePoint.

• If a team member's account is listed as "On Leave" in the Team Status SharePoint list, the status request is not sent to that individual, and their response is automatically recorded as "Excused Absence."

• If a team member has not responded to the adaptive card within four hours of delivery, a reminder is sent via Teams direct message.

• If a team member has still not responded by 5:00 in the afternoon Eastern Time, an escalation notification is sent to the Project Manager via Teams.

Step-by-Step Actions:

1. The flow is triggered at 8:00 in the morning Eastern Time every Monday.

2. The flow queries the Project Registry SharePoint list to retrieve all projects with a status of "Active."

3. For each active project, the flow queries the Team Member Dimension table in Dataverse to retrieve the list of all active Project Team Members assigned to that project.

4. For each Project Team Member, the flow sends a personalized adaptive card via Teams containing the following fields, as defined in Appendix D: Task Identifier, Task Name, Percentage Complete (numeric entry), Blockers and Impediments (free-text entry), New Risks Identified (free-text entry), Hours Logged This Week (numeric entry), and overall Project Health Assessment (Red / Yellow / Green selection).

5. The adaptive card response data is captured and written to the Status Updates SharePoint list for the relevant project, with the following fields populated: Project Identifier, Team Member Name, Response Date and Time, all submitted response values, and a Response Status of "Submitted."

6. A scheduled check runs at 12:00 noon Eastern Time to identify all team members for whom no response has been recorded in the Status Updates list. For each non-respondent, the flow sends a reminder message via Teams direct message stating that their weekly status update is required by 5:00 in the afternoon Eastern Time.

7. A second scheduled check runs at 5:00 in the afternoon Eastern Time. All team members who have still not submitted a response are flagged as "Non-Respondent" in the Status Updates SharePoint list. The flow sends a Teams notification to the Project Manager listing all non-respondents and requesting that the Project Manager follow up directly.

8. Upon completion of all response collection activities, the Power Business Intelligence dataset for the project is refreshed via the Power Business Intelligence Application Programming Interface refresh endpoint, ensuring the dashboard reflects the most current data.

9. A flow execution summary — recording the total number of status requests sent, responses received, reminders sent, and escalations triggered — is written to the Flow Execution Log in SharePoint.

Notifications and Recipients: Initial adaptive card to all active Project Team Members (via Teams); reminder message at noon to non-respondents (via Teams); escalation notification at 5:00 in the afternoon to Project Manager (via Teams).

Data Written: Status Updates SharePoint list (one record per team member per project per week); Flow Execution Log in SharePoint.

Error Handling and Retry Logic: If a Teams adaptive card delivery fails for a specific user, the flow retries delivery three times at five-minute intervals. If delivery still fails after three retries, the flow logs an error record in the Flow Error Log in SharePoint and sends an alert to the Microsoft Power Platform Administrator via Teams. If the Power Business Intelligence dataset refresh fails, the flow retries twice at fifteen-minute intervals and, if unsuccessful, notifies the Microsoft Power Platform Administrator.

6.2 Risk and Issue Escalation Flow

Conditions and Logic Branches:

• If the Severity Rating is one, two, or three: The flow logs the new risk to the Risk Register and notifies the Risk Manager by Teams message within one hour. No immediate escalation to the Project Manager is triggered.

• If the Severity Rating is four: The flow sends an immediate Teams notification to both the Risk Manager and the Project Manager. A task is created in the project's Microsoft Planner board with a due date of three business days from the date of risk submission.

• If the Severity Rating is five: All actions for a Severity Rating of four apply, plus the flow schedules an emergency risk review meeting in Microsoft Outlook calendar for the next available business day, inviting the Risk Manager, Project Manager, and relevant Subject Matter Experts as identified in the Risk Register entry.

Step-by-Step Actions:

10. The flow is triggered by the creation or modification of a Risk Register item in SharePoint.

11. The flow reads the Severity Rating field from the triggering item.

12. The flow evaluates the Severity Rating against the conditional logic branches defined above.

13. For Severity Ratings of four or five, the flow sends an immediate Teams notification to the Risk Manager and Project Manager, including the Risk Identifier, Risk Description, Probability rating, Impact rating, Severity Score, Proposed Response Strategy, and Risk Owner as recorded in the Risk Register entry.

14. For all Severity Ratings, the flow creates an action item task in the relevant project's Microsoft Planner board, assigned to the Risk Owner identified in the Risk Register entry, with the task name, due date, and a hyperlink to the Risk Register item in SharePoint.

15. For a Severity Rating of five, the flow calls the Microsoft Graph Application Programming Interface to create a calendar event in Microsoft Outlook for the next available business day, inviting all relevant parties.

16. Every Friday at 4:00 in the afternoon Eastern Daylight Time, the flow generates a summary digest of all new and modified risks added during the current week and sends this digest as a Teams channel message to the project's Risk and Issues channel, and as an email via Microsoft Outlook to the Risk Manager, Project Manager, and Deputy Project Manager.

Error Handling and Retry Logic: If any Teams notification action fails, the flow retries three times at two-minute intervals and, if unsuccessful, falls back to sending the notification via Microsoft Outlook email. If the Outlook calendar event creation via the Microsoft Graph Application Programming Interface fails, the flow sends a Teams alert to the Microsoft Power Platform Administrator and logs the failure in the Flow Error Log.

6.3 Change Control Board Approval Flow

Conditions and Logic Branches:

• If the Change Request classification is "Minor": The flow routes the request to the Project Manager only for a single-approver decision. No Change Control Board vote is required.

• If the Change Request classification is "Moderate" or "Major": The flow routes the request to all Change Control Board members for parallel voting. A majority vote (greater than fifty percent of voting members) determines the outcome.

• If the Change Request classification is "Emergency": The flow bypasses the standard Change Control Board voting process and routes the request directly to the Project Manager and Executive Sponsor for immediate joint decision, as defined in Section 11.6.

• If an approved majority vote is achieved: The flow updates the project schedule baseline and relevant SharePoint records.

• If the vote results in rejection or deferral: The flow notifies the Change Request submitter of the decision and the reasons recorded by the Change Control Board members.

Step-by-Step Actions:

17. The flow is triggered when a Change Request form is submitted in Microsoft Forms.

18. The flow retrieves the form response data, including the Change Request title, description, classification, impacted scope items, schedule impact (in business days), cost impact (in United States dollars), submitter name, and supporting rationale.

19. The flow generates a unique Change Request Identifier using a sequential numbering scheme (format: CRQ-[Year]-[Sequential Number], e.g., CRQ-2026-0017) and records the new Change Request in the Change Requests SharePoint list with a status of "Pending Review."

20. The flow sends a confirmation Teams message to the Change Request submitter acknowledging receipt and providing the Change Request Identifier.

21. Based on the Change Request classification, the flow applies the appropriate routing logic as defined in the Conditions section above.

22. For Moderate and Major classifications, the flow sends a Teams adaptive card to each Change Control Board member containing the full Change Request details and a three-option vote: Approve, Reject, or Defer. The adaptive card specifies the voting deadline (forty-eight hours from the time of card delivery).

23. The flow collects all votes received within the forty-eight-hour window and calculates the outcome based on majority vote rule. If fewer than fifty percent of Change Control Board members respond within the deadline, the flow escalates to the Project Manager to determine whether to extend the voting period or assign a default outcome.

24. The flow updates the Change Request record in the SharePoint Change Requests list with the vote tally, individual votes (for audit purposes), and the final decision (Approved, Rejected, or Deferred).

25. If the decision is "Approved," the flow sends a notification to all Project Team Members whose Planner tasks are impacted by the change, updates the relevant project schedule fields in SharePoint, and generates a Teams channel announcement in the project's General channel notifying all team members of the approved change.

26. If the decision is "Rejected" or "Deferred," the flow sends a Teams message and email notification to the submitter explaining the decision, including any comments recorded by the Change Control Board members.

Error Handling and Retry Logic: If an adaptive card delivery fails for a specific Change Control Board member, the flow falls back to sending the voting request via Microsoft Outlook email with a link to a dedicated voting form. All delivery failures are logged in the Flow Error Log in SharePoint.

6.4 Milestone Completion and Gate Review Flow

Step-by-Step Actions:

27. The flow is triggered when a Planner task labeled with the category tag "Milestone" is marked as complete by the assigned Project Team Member or Project Manager.

28. The flow retrieves the milestone details from the Planner task record via the Microsoft Graph Application Programming Interface, including milestone name, associated project identifier, completion date, and assigned team member.

29. The flow updates the Milestones SharePoint list for the relevant project, recording the milestone name, completion date, and completion status as "Completed — Pending Gate Review."

30. The flow compiles the gate review package by retrieving all relevant deliverable documents from the project SharePoint document library associated with the completed milestone, as defined in the Milestone Deliverables mapping table maintained by the Project Manager in SharePoint.

31. The flow sends a Teams adaptive card notification to all Project Steering Committee members, attaching or linking to the gate review package documents, and requesting formal approval or rejection of the milestone via the adaptive card interface. The adaptive card specifies a seventy-two-hour review and response window.

32. Upon receipt of all Steering Committee responses (or upon expiration of the seventy-two-hour window), the flow calculates the majority decision. If a majority approves, the flow proceeds with the approval actions. If a majority rejects, the flow proceeds with the rejection actions.

33. If the milestone is approved: The flow updates the Milestones SharePoint list record to "Approved," unlocks the next phase's task assignments in Microsoft Planner by updating the tasks' start dates to the current date (or the next business day, if the approval occurs outside business hours), and sends a Teams channel announcement notifying all project team members that the milestone has been approved and the next phase has commenced.

34. If the milestone is rejected: The flow updates the Milestones SharePoint list record to "Rejected," creates a Corrective Action task in Microsoft Planner assigned to the Project Manager with a due date of five business days from rejection, and sends a Teams direct message to the Project Manager specifying the rejection reasons recorded by the Steering Committee members.

Error Handling and Retry Logic: If the Planner task completion event is not received within an expected window after a manual completion is reported, the Microsoft Power Platform Administrator should manually trigger the flow via the Power Automate portal. All adaptive card delivery failures fall back to Microsoft Outlook email notification, as described in Flow 6.3.

6.5 Budget Variance Alert Flow

Conditions and Logic Branches:

• If the actual cost variance is between ten percent and twenty-four-point-nine percent above the planned cost baseline: The flow sends an immediate alert to the Finance Controller and Project Manager and generates a Power Business Intelligence variance report export.

• If the actual cost variance is twenty-five percent or more above the planned cost baseline: All actions for the ten-to-twenty-four-point-nine percent threshold apply, plus the flow sends an immediate escalation notification to the Executive Sponsor via both Teams and Microsoft Outlook email.

Step-by-Step Actions:

35. The flow is triggered by the creation or modification of a Financial Tracking record in SharePoint.

36. The flow calculates the budget variance percentage using the formula: ((Actual Cost to Date minus Planned Cost to Date) divided by Planned Cost to Date) multiplied by one hundred.

37. If the variance percentage exceeds ten percent, the flow proceeds with alert actions.

38. The flow retrieves the relevant project information — including project name, project unique identifier, Project Manager name, current phase, and budget baseline details — from the Project Registry SharePoint list.

39. The flow sends an immediate Teams notification and Microsoft Outlook email to the Finance Controller and Project Manager, including the variance percentage, the monetary amount of the variance, the current actual cost to date, the planned cost to date, and the remaining budget available.

40. The flow calls the Power Business Intelligence Application Programming Interface to trigger a refresh of the Budget Variance report and exports the refreshed report as a PDF (Portable Document Format) file, attaching it to the Microsoft Outlook email notification.

41. If the variance percentage is twenty-five percent or more, the flow additionally sends an escalation notification to the Executive Sponsor via Teams and Microsoft Outlook email, including a summary of the variance, the potential impact on project completion, and a request for guidance on whether to apply contingency reserve funds.

42. The flow records the alert event in the Budget Alert History SharePoint list, capturing the date and time of the alert, the variance percentage at the time of alert, the recipients notified, and the escalation level applied.

Error Handling and Retry Logic: If the Power Business Intelligence Application Programming Interface call fails, the flow retries twice at ten-minute intervals. If the report export still fails, the flow sends the notification without the attached report and includes a note directing recipients to access the dashboard directly. The failure is logged in the Flow Error Log.

6.6 New Stakeholder Onboarding Flow

Step-by-Step Actions:

43. The flow is triggered when a new stakeholder record is created in the Stakeholder Register SharePoint list by the Communications Manager or Project Manager.

44. The flow reads the stakeholder's name, email address, organization, stakeholder classification (Internal or External), and communication preference from the new SharePoint list item.

45. The flow retrieves the project overview document, Communication Plan, and reporting schedule from the project SharePoint document library.

46. The flow sends a formal welcome email via Microsoft Outlook to the new stakeholder, including: a personalized salutation, a brief introduction to the project (project name, purpose, and objectives), an attached copy of the Project Overview document, an attached copy of the applicable sections of the Communication Plan outlining how and how frequently they will receive project communications, and the name and contact information of the Communications Manager as the primary point of contact.

47. The flow grants appropriate SharePoint site permissions to the stakeholder's organizational account based on their stakeholder classification — Internal stakeholders receive "Read" access to the project SharePoint site; External stakeholders receive access only to the designated External Stakeholder document library, which contains publicly approved project documents.

48. The flow adds the stakeholder to the relevant project Teams channels based on their classification — all stakeholders are added to the "Announcements" channel; Internal stakeholders with a classification of "Supportive" or "Leading" are also added to the project's "General" channel.

49. The flow adds the stakeholder's email address to the relevant Microsoft Outlook distribution list for the project, ensuring they receive all broadcast email communications.

50. The flow creates a scheduled onboarding meeting in the Communications Manager's Microsoft Outlook calendar for the next available business day following the stakeholder's addition to the register, with the new stakeholder invited as a required attendee. The meeting invitation includes a standard agenda covering project overview, stakeholder role and expectations, and communication cadence.

51. A confirmation record is written to the Onboarding History SharePoint list, capturing the stakeholder name, onboarding date, permissions granted, channels added, and whether the welcome email was successfully delivered.

Error Handling and Retry Logic: If the permission assignment action fails (for example, due to the stakeholder's organizational account not being accessible in the tenant), the flow logs the failure and sends an alert to the Microsoft Power Platform Administrator and the Communications Manager to handle permission assignment manually. All email delivery failures are retried three times at five-minute intervals.

6.7 Lessons Learned Collection Flow (Project Closing)

Step-by-Step Actions:

52. The flow is triggered when the Project Manager updates the Project Status field in the Project Registry SharePoint list to "Closing."

53. The flow retrieves the complete list of all project participants — including Project Team Members, Subject Matter Experts, Stakeholder Representatives, and the Project Manager — from the Team Member Dimension table in Dataverse.

54. The flow sends a Microsoft Forms survey link via Microsoft Outlook email to all project participants, accompanied by a formal covering message from the Project Manager requesting their candid participation in the lessons learned process. The survey questions are as defined in Appendix E of this Reference Guide.

55. The flow sets a fourteen-calendar-day response window for the survey. A reminder email is sent to non-respondents at day seven via Microsoft Outlook.

56. Upon expiration of the fourteen-day window (or upon receipt of all expected responses, whichever occurs first), the flow retrieves all Microsoft Forms survey responses via the Forms connector.

57. The flow consolidates all survey responses into the Lessons Learned Register in SharePoint, organizing entries by project phase, category (People / Process / Technology / Communication), and sentiment (Positive Lesson — what worked well; Negative Lesson — what should be improved).

58. The flow triggers a Copilot-assisted summary generation process: it sends the consolidated response data to Copilot, using the approved prompt from Appendix G, requesting a structured, thematically organized lessons learned summary document. The generated document is saved as a draft in the project SharePoint document library, flagged for review by the Project Manager.

59. The flow initiates the document archival process: it copies all documents from the active project SharePoint document library to the designated archive folder within the Project Management Office SharePoint archive site, maintaining the original folder structure. Documents are tagged with the project unique identifier, project name, and archival date.

60. The flow sets the permissions on the active project SharePoint site to "Read Only" for all current members, preventing further modification of project records.

61. Upon completion of all archival actions, the flow sends a Teams notification to the Project Manager and Microsoft Power Platform Administrator confirming that the archival process is complete and providing a link to the archive location.

62. A completion record is written to the Project Closure Log in SharePoint, capturing the date and time of archival, the number of documents archived, the Lessons Learned Register entry count, and confirmation that all actions were completed successfully.

Error Handling and Retry Logic: If the document copy action fails for individual files, the flow logs the failed files in a "Archival Errors" SharePoint list and continues with the remaining files. A summary of all archival errors is sent to the Microsoft Power Platform Administrator upon completion of the archival process for manual remediation. The flow does not set the site to read-only until all documents have been successfully archived or the archival error list has been reviewed and acknowledged by the Microsoft Power Platform Administrator.

6.8 Meeting Action Item Tracking Flow

Step-by-Step Actions:

63. The flow is triggered when a new meeting transcript file — in VTT (Web Video Text Tracks) or DOCX format as generated by Teams — is saved to the "Meeting Transcripts" folder in the project SharePoint document library. This occurs automatically when the Teams meeting organizer has enabled transcription for the meeting.

64. The flow reads the transcript file content and retrieves the associated meeting metadata — including meeting title, date and time, attendee list, and meeting organizer — from the Teams meeting record via the Microsoft Graph Application Programming Interface.

65. The flow submits the transcript content to Copilot using the approved action item extraction prompt from Appendix G, requesting that Copilot identify all action items, commitments, and follow-up tasks mentioned in the transcript. For each identified action item, Copilot returns the action item description, the name of the individual assigned to the action (as identified in the transcript), and the due date as stated in the meeting (if mentioned).

66. The flow reviews the Copilot output for completeness and, for any action items where the due date was not stated in the transcript, assigns a default due date of seven calendar days from the meeting date.

67. For each identified action item, the flow creates a task in the relevant project's Microsoft Planner board, assigned to the team member identified as the action item owner. The task title is the action item description, and the task notes field includes the meeting title, date, and a link to the transcript in SharePoint for reference.

68. The flow generates a post-meeting summary document using Copilot, including: the meeting title and date, a list of all attendees, a brief narrative summary of the topics discussed, a structured list of all decisions made, and a table of all action items with owners and due dates. This summary document is saved to the "Meeting Records" folder in the project SharePoint document library.

69. The flow sends the post-meeting summary to all meeting attendees via a Teams channel message in the project's meeting channel, with a link to the full summary document in SharePoint. For attendees who were invited but did not attend, the summary is also sent via Microsoft Outlook email.

70. The flow schedules a reminder notification: twenty-four hours before each action item's due date, the assigned Planner task owner receives a Teams direct message reminding them that their action item is due the following day, with the action item description and a link to the Planner task.

71. Upon completion of all actions, the flow writes a record to the Action Item Tracking Log in SharePoint, including the meeting identifier, the number of action items extracted, the number of Planner tasks created, and the date and time of processing.

Error Handling and Retry Logic: If Copilot fails to process the transcript (for example, due to the transcript file being too large or in an unrecognized format), the flow sends an alert to the Deputy Project Manager and Microsoft Power Platform Administrator, attaching the raw transcript file for manual review. If a Planner task creation fails for a specific action item, the flow retries three times and, if unsuccessful, logs the failed action item in the Action Item Error Log in SharePoint and notifies the Deputy Project Manager.

7.1 Data Sources and Connections

The Power Business Intelligence dashboard connects to the following data sources through certified Power Platform connectors, all of which are configured to use the organizational service accounts provisioned by the Microsoft Power Platform Administrator:

• SharePoint Lists: Project Registry (containing all project metadata), Risk Register (containing all risk records), Issue Log (containing all issue records), Status Updates (containing all weekly status submissions), Budget Tracking (containing all financial data), Change Requests (containing all change request records), Stakeholder Register (containing all stakeholder records), and Lessons Learned Register (containing all lessons learned records).

• Microsoft Planner (via Microsoft Graph Application Programming Interface): Task completion data, milestone status, and resource assignment information are retrieved from Planner through the certified Microsoft Graph Application Programming Interface connector.

• Microsoft Dataverse (via Power Platform connector): Team Member Dimension table, Risk Category Dimension table, Project Dimension table, and workflow state data maintained by Power Automate flows.

• Finance System Data (via OData feed): Actual cost data, purchase order data, and invoice data are retrieved from the organization's financial management system through an OData (Open Data Protocol — an open standard data access protocol) feed connection refreshed daily at midnight.

• Microsoft Project Online (where applicable): For projects using Microsoft Project Online for schedule management, the Project Online connector provides task and milestone data to supplement the Planner data model.

7.2 Data Model

The Power Business Intelligence data model follows a star schema — a relational data model structure in which a central fact table is surrounded by dimension tables, each connected to the fact table through a defined relationship — to optimize query performance and enable flexible, multi-dimensional analysis of project performance data. The following tables constitute the core data model:

7.3 Dashboard Pages

7.4 Row-Level Security Configuration

Row-level security — a Power Business Intelligence feature that restricts which rows of data a given user is authorized to see based on their identity and role — is configured in the data model to ensure that project data is accessible only to authorized personnel. The following row-level security roles are defined in the Power Business Intelligence data model and assigned to organizational security groups by the Microsoft Power Platform Administrator:

• Executive Portfolio Role: Users in this role see data for all active projects across the organization. This role is assigned to the Executive Sponsor, Portfolio Manager, and Project Management Office Director.

• Project Manager Role: Users in this role see data only for the specific projects to which they are assigned as Project Manager or Deputy Project Manager in the Project Dimension table. This role is assigned to all Project Managers and Deputy Project Managers.

• Project Team Member Role: Users in this role see data only for the specific project to which they are assigned in the Team Member Dimension table, and only the task and status data relevant to their own assignments. Aggregate project performance data (Earned Value Analysis metrics, budget totals, risk severity scores) is visible but not filterable to individual team member data of other participants.

• Finance Role: Users in this role see budget and cost data for all projects but are restricted from viewing task-level and team member-level data. This role is assigned to the Finance Controller and Procurement Officer.

• Risk Manager Role: Users in this role see full risk and issue data for all projects but are restricted from viewing budget and team member utilization details of other roles. This role is assigned to the Risk Manager.

7.5 Automated Report Distribution

The Power Business Intelligence service's scheduled email subscription feature is configured to deliver formatted dashboard report snapshots to role-based distribution lists on the following schedule. All subscriptions are managed by the Microsoft Power Platform Administrator and are updated whenever changes to role assignments, stakeholder lists, or distribution list membership are made. Report snapshots are delivered as PDF attachments and include a direct link to the live dashboard for interactive exploration.

7.6 Mobile Optimization and Power Business Intelligence Mobile Application

All dashboard pages are configured with mobile-optimized layouts using the Power Business Intelligence mobile layout editor, enabling authorized users to access project performance data through the Power Business Intelligence Mobile Application (the native mobile application for iOS and Android that provides access to Power Business Intelligence reports and dashboards) on smartphones and tablets. Mobile layouts are simplified versions of the desktop layouts, prioritizing the most critical visual elements — primarily card visuals, status badges, and the top-five risk table — for clear readability on small screens without requiring horizontal scrolling.

The Microsoft Power Platform Administrator is responsible for maintaining the mobile layouts and ensuring that they remain synchronized with any changes made to the desktop layouts during dashboard maintenance activities. All users who access the dashboard through the mobile application must complete the same authentication and row-level security controls as desktop users, ensuring consistent access governance regardless of device type. The organization's mobile device management policy governs the installation and use of the Power Business Intelligence Mobile Application on personal and organizational devices.

7.7 Natural Language Query Configuration

The Power Business Intelligence natural language query feature — also known as "Questions and Answers" — is configured for all dashboard pages to allow users to ask questions about the project data in plain English and receive immediate visual or numerical answers. The Microsoft Power Platform Administrator has configured a library of pre-defined question-and-answer terms — synonyms, entity names, measure names, and common questions — to optimize the accuracy and relevance of natural language query results. Copilot's integration with the natural language query feature further enhances this capability by enabling more complex, context-aware queries that reference multiple data sources simultaneously. All natural language query sessions are subject to the same row-level security controls as the underlying data model, ensuring that users cannot access data beyond their authorized scope through natural language queries.

8.1 Quality Standards and References

The quality management approach for all projects governed by this Reference Guide is aligned with the following standards and references: the Project Management Body of Knowledge Seventh Edition (specifically the Delivery Performance Domain, which addresses the quality of outputs, outcomes, and benefits); the International Organization for Standardization 9001 (an internationally recognized standard for quality management systems, hereinafter referred to as "International Organization for Standardization 9001") where applicable to the organization's certified processes; and the organization's internal Quality Management Framework, maintained by the Quality Assurance Manager and accessible on the Project Management Office SharePoint site. In cases of conflict between these standards and the requirements of this Reference Guide, the organization's internal Quality Management Framework shall take precedence, unless the conflict pertains to a Project Management Institute standard, in which case the Project Management Institute standard shall prevail.

8.2 Quality Assurance Activities

Quality assurance activities are process-oriented activities performed to provide confidence that the project will satisfy the relevant quality standards. Under this Reference Guide, the following quality assurance activities are mandatory for all projects:

• Process Compliance Audits: The Quality Assurance Manager conducts a formal process compliance audit at the midpoint of each project phase, reviewing the project team's adherence to the processes defined in this Reference Guide, including status reporting, risk management, change control, and communication activities. Audit findings are documented in the Quality Audit Report in SharePoint and reviewed by the Project Manager within five business days of receipt.

• Document Quality Reviews: All formal project documents — including the Project Charter, Project Management Plan, status reports, risk register, and closure documentation — are reviewed by the Quality Assurance Manager for completeness, accuracy, and compliance with the templates defined in this Reference Guide and the appendices thereto before being formally approved or distributed.

• Automated Process Monitoring: The Power Business Intelligence dashboard's automated anomaly detection capability, described in Section 7.7, is used to monitor the quality of process execution by identifying patterns that deviate from defined standards — for example, consistently late status update submissions, unusually high rates of change request rejections, or unusually long mean time to close issues — and alerting the Project Manager and Quality Assurance Manager to these patterns for investigation.

8.3 Quality Control Activities

Quality control activities are product-oriented activities performed to identify defects in deliverables and take corrective action to ensure that deliverables meet their defined acceptance criteria. Under this Reference Guide, the following quality control activities are mandatory for all projects:

• Deliverable Inspections: All formal project deliverables must be formally inspected by the Quality Assurance Manager against the acceptance criteria defined in the relevant section of the Project Management Plan before being submitted for stakeholder approval at a milestone gate review. The inspection must be documented using the Deliverable Inspection Checklist template maintained by the Project Management Office on SharePoint.

• Testing Activities: For technical deliverables, the Quality Assurance Manager and Technical Lead and Solution Architect jointly define the testing strategy — including unit testing, integration testing, user acceptance testing, and performance testing as appropriate — and the specific acceptance criteria for each test type. All testing activities and their results must be documented in the Test Results Log in SharePoint.

• Defect Management: All defects identified during deliverable inspections or testing activities are logged in the Issue Log in SharePoint with full traceability to the deliverable, the acceptance criterion that was not met, the severity of the defect, and the remediation action required. Defects with a severity rating of four or five on a five-point scale are automatically escalated to the Project Manager through the Risk and Issue Escalation Flow defined in Flow 6.2.

8.4 Quality Gates by Phase

8.5 Defect and Non-Conformance Management

A defect is a condition in which a deliverable fails to meet one or more of its defined acceptance criteria. A non-conformance is a condition in which a process activity fails to adhere to one or more of the standards or procedures defined in this Reference Guide or the organization's Quality Management Framework. Both defects and non-conformances are recorded in the Issue Log in SharePoint using the Non-Conformance Record template maintained by the Quality Assurance Manager. Each record must include: the identifier and description of the defect or non-conformance, the deliverable or process activity affected, the acceptance criterion or standard violated, the date of discovery, the severity rating, the assigned remediation owner, the required remediation due date, and the status of the remediation action.

For defects and non-conformances with a severity rating of four or five, the Risk and Issue Escalation Flow defined in Flow 6.2 automatically notifies the Project Manager and Quality Assurance Manager and creates a remediation task in Microsoft Planner. The Project Manager is responsible for ensuring that all defects and non-conformances are remediated within the timeframes defined in the Non-Conformance Record before the affected deliverable is resubmitted for approval or the project advances through its next quality gate. A pattern of recurring non-conformances in the same process area shall trigger a formal process improvement review led by the Quality Assurance Manager and the Project Management Office Director.

9.1 Communication Matrix

The following Communication Matrix defines every formal communication associated with this automated project management process, specifying the intended audience, message content, delivery frequency, communication channel, and responsible role for each communication type. All communications must be executed in accordance with this matrix unless formally amended through the change control process defined in Section 11.

9.2 Reporting Cadence

The following reporting cadence applies to all projects governed by this Reference Guide. Adherence to this cadence is monitored by the Deputy Project Manager, and any deviations — including late or missed reports — must be documented in the project issue log and remediated promptly. The automated flows defined in Section 6 enforce the cadence for all event-driven and scheduled automated communications.

• Daily: The Project Manager and Deputy Project Manager review the Power Business Intelligence Individual Project Health Dashboard each business day for schedule, cost, risk, and issue anomalies. No formal daily report is published unless a critical issue requiring immediate stakeholder notification is identified.

• Weekly: Weekly project status reports are published every Monday by noon Eastern Daylight Time. Risk digests are distributed every Friday at 4:00 in the afternoon Eastern Daylight Time. Power Business Intelligence dashboard email subscriptions are delivered as defined in Section 7.5.

• Monthly: The Portfolio Review Briefing is conducted on the first Tuesday of each month. The Change Control Summary Power Business Intelligence report subscription is delivered on the first Monday of each month.

• Milestone-Based: Gate review notifications are distributed immediately upon milestone completion through Flow 6.4. Milestone approval or rejection notifications are distributed within twenty-four hours of the gate review decision.

9.3 Escalation Path and Escalation Thresholds

The following escalation path defines the sequence of contacts and timeframes governing escalation of issues, risks, decisions, and performance variances that cannot be resolved at the current level of authority. Escalation is mandatory whenever the conditions defined in this table are met; failure to escalate in accordance with this path is a process non-conformance subject to the defect management procedure defined in Section 8.5.

9.4 Stakeholder Engagement Classification

All stakeholders identified in the Stakeholder Register are classified according to the engagement level model defined in the Project Management Body of Knowledge Seventh Edition. This classification is used to guide the development of tailored communication and engagement strategies for each stakeholder group. The five engagement levels are defined as follows:

• Unaware: The stakeholder is not aware of the project or its potential impact on them. Communication strategy: inform of project existence, purpose, and relevance to the stakeholder's interests through an introductory communication and follow-up meeting.

• Resistant: The stakeholder is aware of the project but is resistant to the change it represents. Communication strategy: engage actively through one-on-one meetings facilitated by the Communications Manager to understand and address specific concerns; involve in working groups where feasible to build ownership.

• Neutral: The stakeholder is aware of the project but is neither resistant nor actively supportive. Communication strategy: maintain regular informational communications to build awareness and understanding; seek opportunities to highlight benefits relevant to the stakeholder's interests.

• Supportive: The stakeholder is aware of and supportive of the project. Communication strategy: leverage the stakeholder's support by inviting them to serve as internal advocates; keep them informed and engaged to sustain their support through regular, substantive communications.

• Leading: The stakeholder is actively engaged in ensuring the project succeeds. Communication strategy: involve in governance activities, gate reviews, and decision-making processes; provide full access to project performance information and recognize their leadership contribution formally.

Stakeholder engagement classifications are assessed by the Communications Manager at each gate review and updated in the Stakeholder Register accordingly. Changes in a stakeholder's classification that represent a deterioration (for example, from Supportive to Neutral, or from Neutral to Resistant) must trigger an immediate review of the communication strategy for that stakeholder and, if warranted, an escalation to the Project Manager for personal engagement.

9.5 Microsoft Teams Channel Structure for the Project

Each project governed by this Reference Guide is provisioned with a dedicated Microsoft Teams environment with the following standardized channel structure. This structure is created automatically by the project intake Power Automate flow upon charter approval and is maintained by the Microsoft Power Platform Administrator. All project team members and relevant stakeholders are added to the appropriate channels as defined by their role and classification.

10.1 Risk Identification Process

Risk identification is the systematic process of identifying and documenting all potential events or conditions that could positively or negatively affect the project's ability to achieve its objectives. Under this Reference Guide, risk identification is a continuous, organization-wide responsibility — not the exclusive domain of the Risk Manager — and all project personnel are expected to identify and log risks as they are encountered throughout the project lifecycle. New risks may be identified through formal risk workshops, structured stakeholder interviews, expert judgment sessions, analysis of historical project data in the Lessons Learned Repository accessible via the Power Business Intelligence Page 6 dashboard, and review of analogous project records.

The primary automated trigger for risk identification is the Risk and Issue Escalation Flow defined in Flow 6.2, which activates whenever a new risk record is created in the SharePoint Risk Register. Additionally, Copilot is used during the Initiating Phase to perform an automated initial risk screening of the Project Charter and business case, as described in Section 5.1, to ensure that no major risk categories are overlooked in the initial risk register. All newly identified risks must be entered into the SharePoint Risk Register within one business day of identification.

10.2 Risk Assessment: Probability and Impact Matrix

All identified risks are assessed on two dimensions: Probability (the likelihood that the risk event will occur) and Impact (the magnitude of the consequence to the project if the risk event occurs). Both dimensions are rated on a five-point ordinal scale as defined in the following tables. The Severity Score for each risk is calculated by multiplying the Probability rating by the Impact rating, yielding a score between one and twenty-five. The automated Risk and Issue Escalation Flow applies different routing and escalation actions based on the Severity Score as described in Flow 6.2.

The following five-by-five Risk Matrix summarizes the Severity Score ranges and their associated escalation classification:

Color Key: Green (1–4) = Low; Yellow (5–9) = Moderate; Orange (10–14) = High; Red (15–19) = Very High; Dark Red (20–25) = Critical

10.3 Risk Response Strategies

For each identified risk, the Risk Manager and Project Manager must define and document an appropriate risk response strategy in the Risk Register. The following five response strategies, aligned with the Project Management Body of Knowledge Seventh Edition's guidance on risk response planning, are available:

• Avoid: Changing the project plan to eliminate the risk or protect the project from its impact. Avoidance involves eliminating the root cause of the risk rather than merely reducing its probability or impact. Avoidance is most appropriate for risks with Critical severity scores (twenty to twenty-five) where the potential impact is unacceptable and where the necessary plan change is feasible within the project's constraints.

• Transfer: Shifting the financial consequence of the risk to a third party — typically through insurance, performance bonds, warranties, or fixed-price contracts with vendors — without eliminating the risk itself. Transference reduces the organization's financial exposure to the risk but does not prevent the risk event from occurring. It is most appropriate for financial risks that can be contractually assigned to another party.

• Mitigate: Reducing the probability of a risk occurring, reducing the impact of the risk if it does occur, or both. Mitigation actions must be specific, measurable, and achievable within the project's time and cost constraints. Mitigation is the most commonly applicable strategy and is appropriate for risks with Moderate, High, or Very High severity scores where the risk cannot be avoided or transferred.

• Accept: Acknowledging the risk and deciding to take no proactive action unless and until the risk event occurs (passive acceptance) or establishing a contingency plan and contingency reserve to be invoked if the risk materializes (active acceptance). Acceptance is appropriate for risks with Low severity scores (one to four) or for risks where no cost-effective response strategy is available.

• Escalate: Escalating the risk to a higher level of authority within or outside the organization when the risk is beyond the scope of the project manager's authority or when its impact would extend beyond the boundaries of the project. Escalated risks are reported to the Executive Sponsor or Portfolio Manager and are managed at the program or portfolio level rather than the project level.

10.4 Residual Risk Monitoring

Residual risks are risks that remain after the implementation of risk response strategies. Even after a risk response has been implemented, the underlying risk may not be fully eliminated, and the remaining probability and impact of the risk must be reassessed and continuously monitored. Residual risks are documented in the Risk Register alongside the original risk and its response strategy, and are assigned their own Residual Probability, Residual Impact, and Residual Severity Score. The Risk Manager reviews all residual risks on a weekly basis as part of the Risk Register maintenance activity and updates the residual ratings as new information becomes available. Residual risks with a Residual Severity Score of ten or above are reviewed by the Project Manager and are included in the weekly risk digest distributed through Flow 6.2.

10.5 Automated Risk Escalation Rules

The following automated risk escalation rules are implemented in the Risk and Issue Escalation Flow defined in Flow 6.2 and are enforced automatically by Power Automate without requiring manual intervention by the Risk Manager or Project Manager:

• Severity Rating of five on the Probability or Impact scale alone: The Risk Manager receives an automated Teams notification within thirty minutes of the risk record being created or modified. A Planner task is created for the Risk Manager with a due date of two business days.

• Severity Score of fifteen through nineteen (Very High): The Risk Manager and Project Manager both receive immediate Teams notifications. A Planner action item is created with a due date of three business days. The risk is included in the next weekly digest.

• Severity Score of twenty through twenty-five (Critical): All Very High escalation actions apply, plus an emergency risk review meeting is scheduled in Microsoft Outlook for the next available business day, and the Executive Sponsor is notified via Teams direct message.

• Any risk that remains open (status not set to Closed or Accepted) for more than thirty calendar days without a recorded response action: The Risk Manager and Project Manager receive an automated Teams reminder. The risk is highlighted in the Power Business Intelligence Risk and Issue Management View with a red "Stale Risk" indicator.

10.6 Risk Register Template

The following table defines all required fields in the SharePoint Risk Register list. The Microsoft Power Platform Administrator is responsible for ensuring that the SharePoint list is configured with all fields defined below and that all field types, validation rules, and automated flow triggers are correctly implemented. The blank Risk Register template for project use is provided in Appendix B of this Reference Guide.

11.1 Change Request Submission Procedure

Any project stakeholder — including Project Team Members, Subject Matter Experts, Stakeholder Representatives, or external parties — may submit a Change Request at any time during the project lifecycle by completing the Change Request Form in Microsoft Forms, the link to which is pinned in the project's Change Control Teams channel and is accessible from the project SharePoint site. The Change Request Form template is provided in Appendix C of this Reference Guide and includes all mandatory fields required for the Change Control Board to evaluate the request.

The submitter is responsible for providing a complete, accurate, and detailed description of the proposed change, including its rationale, the specific scope elements or baselines it would affect, and a preliminary estimate of its impact on the project schedule and budget. Incomplete Change Request forms will be returned to the submitter by the Project Manager with a request for the missing information; the clock for the Change Control Board review period does not begin until a complete Change Request form has been received. All Change Request submissions trigger the automated Change Control Board Approval Flow defined in Flow 6.3.

11.2 Change Request Classification

All Change Requests are classified by the Project Manager upon receipt, based on the scope and magnitude of the proposed change. The classification determines the routing, approval authority, and timeline for the change control process:

11.3 Change Control Board Composition and Voting Rules

The Change Control Board is composed of the following roles, as defined in Section 2.1 of this Reference Guide: the Project Manager (who serves as the non-voting Change Control Board Chair, responsible for presenting the Change Request package and facilitating the review process), a minimum of two and a maximum of five Change Control Board Members representing the key stakeholder groups, the Finance Controller (non-voting, providing financial impact analysis), and the Technical Lead and Solution Architect (non-voting for minor and moderate changes; voting member for major and technically complex changes). The Executive Sponsor participates in the Change Control Board review only for Major classification changes requiring Executive Sponsor ratification.

The voting rules for the Change Control Board are as follows: A quorum is established when at least two-thirds of the voting Change Control Board members have cast their votes within the defined review period. A majority vote — defined as more than fifty percent of votes cast — is required to approve a change request. If a quorum is not achieved within the review period, the Project Manager may extend the voting period by an additional forty-eight hours, or may escalate to the Project Steering Committee for a decision. All votes are recorded in the Change Requests SharePoint list for audit purposes, regardless of whether the vote is cast via the Teams adaptive card or via the fallback Microsoft Outlook email voting mechanism.

11.4 Change Impact Assessment Procedure

Before transmitting a Change Request to the Change Control Board for voting, the Project Manager, supported by the Business Analyst, Technical Lead and Solution Architect, Finance Controller, and Risk Manager, must conduct a formal change impact assessment and document the results in the Change Request record in SharePoint. The change impact assessment must address all of the following dimensions:

• Scope Impact: Which Work Breakdown Structure components, deliverables, or acceptance criteria would be added, removed, or modified by this change?

• Schedule Impact: How many business days would the project completion date be advanced or delayed by this change? Which milestone dates, if any, would be affected?

• Cost Impact: What is the estimated incremental cost (or cost saving) associated with this change in United States dollars? What would be the new Estimate at Completion if the change is approved?

• Quality Impact: Would this change affect the defined acceptance criteria for any project deliverable? Would additional testing or quality assurance activities be required?

• Risk Impact: Does this change introduce new risks or modify the severity of existing risks in the Risk Register? If so, have these risks been logged and assessed?

• Stakeholder Impact: Which stakeholders would be affected by this change? How should they be notified and engaged regarding the change?

• Resource Impact: Does this change require additional personnel, skills, technology, or vendor resources not currently available to the project?

11.5 Change Implementation and Baseline Update Procedure

Upon formal approval of a Change Request by the appropriate authority, the Project Manager is responsible for implementing the approved change in an orderly and controlled manner. The following steps must be completed within five business days of the approval decision for all Minor and Moderate changes, and within ten business days for Major changes:

72. The Project Manager updates the relevant baseline documents — Project Schedule Baseline, Cost Baseline, and Scope Baseline — in SharePoint to reflect the approved change. The updated baseline documents must be version-controlled with a new version number and the Change Request Identifier recorded in the document revision history.

73. The Project Manager updates the Work Breakdown Structure and Microsoft Planner task board to reflect any new, modified, or removed tasks resulting from the approved change.

74. The Finance Controller updates the budget tracking records in SharePoint to reflect the approved cost impact of the change.

75. The Risk Manager reviews the risk register for any risks introduced or modified by the approved change and updates the Risk Register accordingly.

76. The Communications Manager distributes formal notification of the approved change to all affected stakeholders in accordance with the Communication Plan.

77. The Change Request record in the SharePoint Change Requests list is updated to a status of "Implemented" with the implementation date recorded.

78. The automated Power Automate flow defined in Flow 6.3 triggers a Power Business Intelligence dataset refresh to ensure the dashboard reflects the updated baselines.

11.6 Emergency Change Protocol

The Emergency Change Protocol applies when an immediate change is required to prevent imminent project failure, regulatory non-compliance, safety risk, or irreversible harm, and when the standard Change Control Board review cycle cannot be completed within the required timeframe. The following procedure governs Emergency Changes:

79. The Project Manager contacts the Executive Sponsor directly via Teams direct message or telephone to describe the nature and urgency of the required change and obtain verbal authorization to proceed.

80. The Project Manager submits the Emergency Change Request Form via Microsoft Forms, selecting "Emergency" as the classification. Flow 6.3 routes the request directly to the Project Manager and Executive Sponsor for immediate decision rather than to the Change Control Board.

81. Upon receipt of verbal authorization from the Executive Sponsor, the Project Manager may immediately implement the emergency change while simultaneously completing the formal documentation.

82. Within twenty-four hours of implementing the emergency change, the Project Manager must ensure that the formal Change Request Form is complete and has been digitally approved by both the Project Manager and the Executive Sponsor in the SharePoint system.

83. Within five business days of implementation, the Change Control Board conducts a retrospective review of the emergency change to assess its impact, confirm its appropriateness, and determine whether any further corrective actions are required. The retrospective review findings are documented in the Change Request record in SharePoint.

84. All Emergency Changes are subject to the same baseline update procedure defined in Section 11.5, which must be completed within three business days of the Executive Sponsor's formal digital approval.

12.1 Procurement Planning

Procurement planning is the process of determining what project needs can best be met by acquiring products, services, or results from external sources, and documenting the approach to sourcing those external resources. During the Planning Phase, the Project Manager and Procurement Officer jointly develop the Procurement Management Plan — a subsidiary plan of the Project Management Plan — which documents all planned procurement activities, identifies the specific goods and services to be procured, defines the contract types and approval thresholds that will apply, and establishes the vendor performance monitoring approach that will be used throughout the project lifecycle.

The Procurement Management Plan must be reviewed and approved by the Finance Controller before it is incorporated into the Project Management Plan baseline. All planned procurements must be budgeted within the approved project budget defined in Section 3.8 of the Project Charter. Any procurement not anticipated in the Procurement Management Plan requires a Change Request submission in accordance with the process defined in Section 11 before a purchase commitment is made.

12.2 Vendor Selection Criteria

All vendor selection activities conducted under this Reference Guide must be governed by the organization's Procurement Policy and must apply objective, documented selection criteria. The following standard vendor selection criteria apply to all procurements unless the Procurement Officer documents a justified deviation in the Procurement Management Plan:

• Technical Capability: The vendor's demonstrated ability to deliver the required goods or services to the specified quality standards and acceptance criteria.

• Experience and References: The vendor's track record of delivering similar goods or services to organizations of comparable size and complexity, including verifiable references from prior engagements.

• Financial Stability: Evidence of the vendor's financial health and organizational stability, including financial statements or third-party credit assessments where appropriate.

• Pricing and Value for Money: The total cost of the vendor's offering relative to the value delivered, evaluated on a total cost of ownership basis rather than on initial price alone.

• Compliance and Regulatory Standing: The vendor's compliance with all applicable laws, regulations, and organizational policies, including data privacy, labor standards, and environmental requirements.

• Delivery Schedule and Capacity: The vendor's ability to deliver within the project's required timeframe and their demonstrated capacity to meet the project's volume and complexity requirements.

12.3 Contract Types and Approval Thresholds

The following contract types are available for use on projects governed by this Reference Guide, subject to the approval thresholds defined below. All contracts must be reviewed by the organization's Legal Counsel before execution and must be filed in the Contracts document library in the project SharePoint site upon execution.

12.4 Vendor Performance Monitoring

Vendor performance is monitored on an ongoing basis throughout the contract period using a combination of automated Power Business Intelligence reporting and periodic formal performance review meetings. The Procurement Officer is responsible for entering vendor performance data — including delivery milestone completion, quality of deliverables received, responsiveness to issues, and compliance with contract terms — into the Vendor Performance SharePoint list on a monthly basis. This data is integrated into the Power Business Intelligence data model and is displayed on the Individual Project Health Dashboard in a dedicated vendor performance summary section.

Formal vendor performance review meetings are conducted by the Procurement Officer and Project Manager at monthly intervals for contracts exceeding a defined value threshold, and quarterly for smaller contracts. The outcomes of each performance review are documented in the Vendor Performance SharePoint list and any performance concerns are raised as issues in the Issue Log. If a vendor's performance consistently falls below the defined threshold — specifically, if the vendor receives a composite performance rating below three on a five-point scale for two consecutive monthly review periods — the Project Manager and Procurement Officer must initiate a formal vendor performance improvement process and notify the Finance Controller.

12.5 Purchase Order and Invoice Approval Flows

All purchase orders and vendor invoices are processed through an automated approval flow built in Power Automate. The flow is triggered when a purchase order is created or an invoice is submitted to the designated Finance document library in the project SharePoint site. The flow routes the purchase order or invoice to the appropriate approvers based on the monetary value and contract type, as defined in the approval threshold table in Section 12.3. Approvers receive a Teams adaptive card requesting their digital approval or rejection, with the option to include comments.

Upon approval, the flow records the approval in the Financial Tracking SharePoint list, updates the Budget Actuals data model for the Power Business Intelligence dashboard, and sends a confirmation notification to the Procurement Officer and Finance Controller. Upon rejection, the flow notifies the submitter with the rejection reason and creates an action item for the Procurement Officer to address the rejection condition. All purchase order and invoice records, including the complete approval audit trail, are archived in the Finance document library in SharePoint and retained in accordance with the document retention policy defined in Section 13.5.

13.1 Formal Acceptance and Sign-Off Process

Formal project closure begins with the formal acceptance of all project deliverables by the authorized receiving party — typically the Executive Sponsor or the operational team inheriting the project's outputs. Formal acceptance is evidenced by the completion and digital signature of a Deliverable Acceptance Record for each major deliverable defined in the Project Charter and Project Management Plan. Deliverable Acceptance Records are stored in the Deliverable Acceptance document library in the project SharePoint site and are incorporated by reference into the Project Closure Report.

The Project Manager is responsible for ensuring that all Deliverable Acceptance Records are completed and signed before initiating the project closure activities. If a deliverable is not formally accepted — due to outstanding defects, non-conformances, or stakeholder disagreements — the issue must be resolved through the defect management process defined in Section 8.5 and the change control process defined in Section 11 before the project can advance to formal closure. The Project Manager updates the project status in the Project Registry SharePoint list to "Closing" only after all deliverables have been formally accepted, which triggers the Lessons Learned Collection Flow defined in Flow 6.7.

13.2 Contract Closeout

Contract closeout is the process of verifying that all work performed by vendors and contractors has been completed in accordance with the contract terms, all deliverables have been formally accepted, all invoices have been paid and reconciled, and all contractual obligations on both sides have been fulfilled. The Procurement Officer is responsible for coordinating the contract closeout process for all active contracts. For each contract, the Procurement Officer must complete a Contract Closeout Checklist — maintained in the Project Management Office's contract management document library on SharePoint — confirming that all specified conditions have been met.

Upon completion of the Contract Closeout Checklist, the Procurement Officer notifies the Finance Controller, who confirms that all final payments have been processed and that there are no outstanding financial obligations under the contract. The Finance Controller's confirmation, together with the completed Contract Closeout Checklist, constitutes the formal record of contract closeout and is filed in the Contracts document library in the project SharePoint site. The Procurement Officer sends a formal contract closeout notification to each vendor upon completion of their respective contract closeout process.

13.3 Lessons Learned Facilitation

The lessons learned process is a mandatory component of project closure for all projects governed by this Reference Guide, regardless of project size, duration, or outcome. Lessons learned are systematically collected through the automated survey process defined in Flow 6.7, analyzed by Copilot to identify recurring themes and improvement opportunities, and compiled into the Lessons Learned Register in SharePoint and the Lessons Learned Repository accessible through the Power Business Intelligence Page 6 dashboard. The Project Manager is responsible for facilitating a formal Lessons Learned Workshop — conducted via Teams — at which the project team reviews, discusses, and validates the Copilot-generated lessons learned summary before it is finalized.

Lessons learned identified during the project closure process must be categorized by project phase (Initiating, Planning, Executing, Monitoring and Controlling, or Closing) and by category (People, Process, Technology, or Communication). For each lesson identified, the Lessons Learned Register must capture: the lesson title, description, category, phase, the specific impact the lesson had on the project, the recommended improvement action for future projects, the individual or role responsible for implementing the improvement, and the target implementation date. The Project Management Office Director is responsible for ensuring that high-priority lessons learned are reviewed during the quarterly Project Management Office process improvement review and are incorporated into future versions of this Reference Guide or the associated templates and training materials as appropriate.

13.4 Benefits Realization Measurement

Benefits realization measurement is the process of assessing the extent to which the benefits defined in the Project Charter and Business Case have been achieved as a result of the project. Benefits realization assessment is conducted during project closure and, for projects with benefits that materialize over an extended period post-closure (for example, cost savings or revenue growth), is conducted again at defined intervals after project closure — typically at six months and twelve months post-closure — in accordance with the Benefits Realization Plan developed during the Planning Phase.

The Project Manager, in coordination with the Finance Controller and the Executive Sponsor, completes the Benefits Realization Report template during the Closing Phase. The report assesses each benefit defined in Section 3.2 of the Project Charter against the specific metric and target value defined in Section 3.3, documenting the actual value achieved, the variance from the target, the explanation for any material variance, and any further actions required to realize the full intended benefit. For benefits that are expected to materialize post-closure, the Benefits Realization Report identifies the responsible operational role who will conduct the post-closure benefits tracking and the mechanisms — typically Power Business Intelligence reports connected to operational data systems — through which benefits will be measured and reported.

13.5 Document Archival and Retention Policy

All project documents — including the Project Charter, Project Management Plan and all subsidiary plans, risk register, issue log, change request records, meeting records, status reports, deliverable acceptance records, contract documents, lessons learned records, and the Project Closure Report — must be formally archived in the designated Project Archive folder within the Project Management Office SharePoint archive site upon project closure. The archival process is initiated automatically by the Lessons Learned Collection Flow defined in Flow 6.7 when the project status is set to "Closing." The Microsoft Power Platform Administrator is responsible for ensuring that the archive folder structure is correctly maintained and that all archived documents are properly indexed and searchable.

The following document retention periods apply to all archived project documents and are governed by the organization's Records Management Policy. These retention periods supersede any shorter document retention periods that may be specified in individual project plans:

13.6 Transition to Operations

The transition of project outputs to the operational team responsible for their ongoing maintenance, use, and support is a critical final activity of the project lifecycle and must be formally planned and executed to ensure continuity of operations and the sustained realization of project benefits. The Project Manager, in coordination with the Technical Lead and Solution Architect and the relevant operational leadership, must develop a Transition Plan as a component of the Project Management Plan during the Planning Phase, specifying the activities, timeline, resource requirements, and acceptance criteria for the transition of each project deliverable to operations.

The Transition Plan must address, at minimum: the operational readiness criteria that must be met before the transition occurs; the training and knowledge transfer activities required to equip operational staff to manage and support the transitioned deliverables; the documentation — including user manuals, technical specifications, support procedures, and escalation paths — that must be completed and transferred to the operational team; the support model that will govern the project team's availability to assist the operational team during the transition period (typically thirty to ninety days post-closure, depending on the complexity of the deliverables); and the formal handover meeting or ceremony at which the Project Manager formally transfers ownership of all deliverables to the operational team leadership, with both parties signing the Transition Acceptance Record.

14.1 Project Management Office Governance Model

The Project Management Office operates under a Controlling Project Management Office model — a Project Management Office governance structure in which the Project Management Office both provides project management support and enforces compliance with organizational project management standards, methodologies, and tools across all governed projects. In this model, the Project Management Office Director has the authority to audit project compliance with this Reference Guide, to require corrective actions when deviations are identified, and to recommend the suspension or termination of projects that persistently fail to meet governance requirements.

The Project Management Office conducts governance activities at three levels: project-level governance (through the quality gates, audits, and automated monitoring defined in this Reference Guide), portfolio-level governance (through the monthly Portfolio Review Briefing and the Power Business Intelligence Executive Portfolio Overview dashboard), and process-level governance (through the quarterly Process Improvement Review at which lessons learned from closed projects are evaluated for incorporation into this Reference Guide and associated standards). All Project Management Office governance activities are documented and maintained in the Project Management Office Governance Log in SharePoint.

14.2 Audit and Compliance Requirements

All projects governed by this Reference Guide are subject to periodic compliance audits conducted by the Project Management Office. The Project Management Office Director schedules at minimum one formal compliance audit for each active project per calendar quarter. The audit reviews the project's adherence to the processes, documentation standards, and automated workflow requirements defined in this Reference Guide and assesses whether the project's automated flows are operating correctly and producing accurate data for the Power Business Intelligence dashboard. Audit findings are classified as Critical (requiring remediation within five business days), Major (requiring remediation within fifteen business days), or Minor (requiring remediation within thirty business days) and are tracked in the Audit Findings SharePoint list until remediated and closed.

In addition to the Project Management Office compliance audits, projects may be subject to internal audit activities conducted by the organization's Internal Audit function, external audits conducted by regulatory bodies or certification authorities, and client audits where contractually required. The Project Manager is responsible for ensuring that all requested audit documentation is available and current in the project SharePoint site at all times, and for coordinating the project team's participation in any audit activities.

14.3 Data Governance for Microsoft Power Platform

All data created, processed, or stored within the Power Platform environment used by this automated project management process — including data in Power Automate flows, Power Business Intelligence datasets, Dataverse tables, and SharePoint lists — is subject to the organization's Data Governance Policy. The Microsoft Power Platform Administrator is responsible for ensuring that all Power Platform resources comply with the applicable data classification, access control, and data lifecycle management requirements defined in the Data Governance Policy.

Data classification for project management data follows the organization's standard data classification scheme: Public (information approved for unrestricted distribution), Public Edition (information intended for use by authorized employees and contractors), Confidential (information that could cause harm to the organization or individuals if disclosed), and Restricted (information subject to the highest level of access control and requiring explicit approval for access). Most project management data falls within the Public Edition classification; financial data and personally identifiable information of project participants may fall within the Confidential classification and must be handled accordingly.

14.4 License and Access Management

Access to all Power Platform and Microsoft 365 resources used in this automated project management process is governed by the principle of least privilege — the principle that each user should be granted only the minimum level of access necessary to perform their defined role and responsibilities. The Microsoft Power Platform Administrator is responsible for maintaining the access control matrix for all Power Platform resources, ensuring that role assignments are current and accurate, and conducting a quarterly access review to identify and revoke any access that is no longer required.

The following license requirements apply to the automated project management process. The Microsoft Power Platform Administrator, in coordination with the organization's IT Licensing Manager, is responsible for ensuring that all required licenses are provisioned and maintained:

• Microsoft Copilot License: Required for all roles that use Copilot functionality — specifically, the Project Manager, Deputy Project Manager, Business Analyst, Communications Manager, Risk Manager, and Microsoft Copilot Coordinator, at minimum.

• Microsoft Power Automate Per-User or Per-Flow License: Required for the Microsoft Power Platform Administrator and for each automated flow that uses premium connectors. The specific license type is determined by the connector requirements of each flow as documented in the Flow Specifications in Section 6.

• Microsoft Power Business Intelligence Pro or Premium License: Required for all users who access the project management dashboard through the Power Business Intelligence service and who are not covered by a Premium capacity workspace allocation. All roles defined in Section 2 that interact with the Power Business Intelligence dashboard require at minimum a Power Business Intelligence Pro license.

• Microsoft 365 E3 or E5 License: Required for all project team members to access Teams, SharePoint, Outlook, Planner, and Forms. Roles that require advanced security and compliance features — specifically the Microsoft Power Platform Administrator and Microsoft Copilot Coordinator — require a Microsoft 365 E5 license or equivalent add-on licensing.

14.5 Data Loss Prevention Policies in Microsoft Power Automate

Data loss prevention policies — governance configurations within the Power Platform that restrict which connectors can be used together within a single Power Automate flow, thereby preventing the unintentional transfer of sensitive organizational data to unauthorized external services — are configured and maintained by the Microsoft Power Platform Administrator in the Power Platform Administration Center. These policies are a critical component of the organization's data security posture and must be reviewed and updated whenever new connectors are introduced into the automated project management environment or whenever the organization's data security requirements change.

The following data loss prevention policy rules apply to all Power Automate flows within the project management environment. These rules define which connectors are classified as "Business" (permitted for use with organizational data), "Non-Business" (permitted for personal or non-organizational use only), and "Blocked" (prohibited from use in any flow within the governed environment):

• Business (Permitted) Connectors: SharePoint, Microsoft Teams, Microsoft Outlook, Microsoft Planner, Microsoft Forms, Microsoft Graph Application Programming Interface (HTTP with Azure Active Directory — Microsoft's cloud-based identity and access management service), Dataverse, Power Business Intelligence, Microsoft Project Online, and all other Microsoft first-party connectors explicitly approved by the Microsoft Power Platform Administrator.

• Non-Business (Restricted) Connectors: Consumer social media connectors, personal email connectors, and any third-party connector not explicitly classified as Business. These connectors may be permitted in non-production environments for testing purposes only, with explicit written authorization from the Project Management Office Director.

• Blocked Connectors: All connectors that would transmit organizational data to external, non-approved, or unknown endpoints. The blocked connector list is maintained by the Microsoft Power Platform Administrator and is updated at a minimum on a quarterly basis.

Any request to add a new connector to the Business (Permitted) category must be submitted to the Microsoft Power Platform Administrator as a formal connector approval request. The Microsoft Power Platform Administrator reviews the request with the Data Governance Officer and, if approved, updates the data loss prevention policy within ten business days of approval. All data loss prevention policy changes are logged in the Power Platform Governance Log in SharePoint.