7.2 Information Management & Digital Assets

7.2 Information Management & Digital Assets

[!NOTE] Core MSP Definition: Information Management within the Knowledge theme encompasses the strategies, systems, protocols, and governance controls used to capture, store, secure, maintain, and disseminate programme information and digital assets. It ensures that decision-makers, delivery teams, and operational stakeholders have timely access to accurate, reliable, and authorized data throughout the programme lifecycle.

In modern enterprise transformations, programmes do not merely manage physical assets or human teams; they generate and consume vast ecosystems of digital assets. These include Target Operating Model architectural diagrams, business case financial models, complex project dependency schedules, commercial vendor contracts, automated test scripts, data migration schemas, and sensitive stakeholder registers. If this information is managed casually—scattered across personal email inboxes, local desktop folders, disconnected cloud storage drives, and messaging channels—the programme will rapidly succumb to document sprawl, version chaos, and catastrophic coordination failures.

In MSP 5th edition, Information Management is an essential operational pillar of the Knowledge theme. By establishing clear strategies, enforcing baseline configuration controls, and maintaining a Single Source of Truth, the programme protects the integrity of its governance and delivery mechanisms.

---

The Information Approach

In MSP 5th edition there is a single named product governing programme information: the information approach, part of the programme strategy, developed during design the outcomes and completed during plan progressive delivery. It spans both the strategic rules the programme must comply with and the operating protocols that make those rules workable day to day:

               ┌─────────────────────────────────────────────────────────┐
               │                 THE INFORMATION APPROACH                │
               ├─────────────────────────────────────────────────────────┤
               │  Governance layer — the rules that must be complied with│
               │  - Enterprise compliance & data privacy standards       │
               │  - Information risk appetite & classification tiers     │
               │  - Intellectual property rights & commercial rules      │
               ├─────────────────────────────────────────────────────────┤
               │  Operating layer — how those rules are enacted daily    │
               │  - Common Data Environment (CDE) tooling & platform     │
               │  - File naming conventions & taxonomy tagging           │
               │  - Baseline change control & status accounting rules    │
               │  - Role-based access permissions & security controls    │
               │  - Archiving schedules & document retirement lifecycles │
               └─────────────────────────────────────────────────────────┘

The governance layer

This part of the information approach defines the high-level principles, regulatory requirements, and strategic goals that govern programme information. It aligns the programme with corporate data governance policies, statutory requirements (such as GDPR, ISO 27001, Sarbanes-Oxley, or industry-specific data privacy mandates), and commercial confidentiality boundaries.

The operating layer

The same approach translates those rules into specific, day-to-day procedures, workflows, and tool specifications. It answers pragmatic delivery questions:

• What digital repository or Common Data Environment (CDE) will serve as the authoritative system of record?
• What standardized naming conventions and metadata tags must be applied to every file?
• Who holds the authority to approve a document as a frozen baseline?
• How are changes to baselined documents requested, evaluated, and published?
• How are obsolete or superseded documents securely retired and archived?

---

Establishing a Single Source of Truth (SSOT) & Digital Collaboration Environments

A major pathology in multi-project programmes is architectural divergence caused by fragmented data. When Project A designs an integration using Version 1.2 of an interface document while Project B builds against Version 1.5 stored on a different SharePoint site, the constituent deliverables will fail when brought together for end-to-end integration testing.

To prevent this, MSP mandates the establishment of a Single Source of Truth (SSOT) within a managed Common Data Environment (CDE).

Characteristics of a True Single Source of Truth

• Authoritative System of Record: A single designated digital environment where all authoritative programme assets reside. No secondary repository, local drive, or chat attachment is recognized as official.
• Elimination of Version Ambiguity: Eliminates informal file naming habits such as Target_Operating_Model_v2_final_FINAL_edits_RC.docx. Assets have immutable identifiers, automated version histories, and clear status indicators.
• Unified Cross-Functional Accessibility: Ensures that project delivery teams, Business Change Managers, external system integrators, and executive board members access identical, real-time data regarding programme status, benefits metrics, and architectural standards.
• Elimination of Information Silos: Dismantles departmental boundaries by centralizing information access, ensuring that operational business teams have full visibility into the emerging technical outputs they will soon be expected to adopt.

---

Information Security, Access Control, and Regulatory Compliance

Because programmes frequently handle sensitive corporate data—such as financial restructuring plans, intellectual property, unreleased commercial algorithms, and personally identifiable employee or customer information—information management must enforce strict security controls.

The three pillars of information security

MSP frames programme information security around three pillars, and the Foundation syllabus names them explicitly:

The three pillars are managed together and they pull against one another. Locking a document down to three named individuals maximizes confidentiality and destroys availability; opening a shared drive to everyone maximizes availability and destroys both confidentiality and integrity. The information approach records where the programme sets that balance for each classification tier.

[!TIP] Exam tip: Integrity is the pillar candidates most often overlook, because it is not about secrecy. When a scenario describes teams working from different or superseded versions of a document, the pillar at risk is integrity, not confidentiality.

1. Data Classification Tiers

All programme information must be classified according to sensitivity, determining appropriate handling protocols:

• Public: Information cleared for open external distribution (e.g., public press releases, high-level community consultation documents).
• Internal: Standard programme working documentation accessible to all internal staff and authorized delivery partners (e.g., weekly PMO newsletters, generic training templates).
• Confidential: Sensitive information restricted to specific teams on a "need-to-know" basis (e.g., technical interface designs, vendor commercial bid evaluations, draft project schedules).
• Restricted / Secret: Highly sensitive material restricted to named individuals (e.g., workforce redundancy modeling, board executive minutes, unreleased financial earnings forecasts, patient health data).

2. Role-Based Access Control (RBAC) and Audit Trails

Information security is enforced through Role-Based Access Control (RBAC), ensuring users receive permissions strictly aligned with their governance role (e.g., Read-Only for general stakeholders, Edit for document authors, and Admin/Approval for the Programme Manager and SRO). Furthermore, modern CDE platforms must maintain immutable audit trails—recording exactly who viewed, edited, downloaded, or approved a sensitive document, ensuring total accountability during internal assurance or statutory audits.

---

Configuration Management and Baseline Control in MSP

Perhaps the most critical information management discipline tested on the MSP exam is Configuration Management.

[!IMPORTANT] Definition of Configuration Management: The technical and administrative discipline that applies direction and surveillance over the life cycle of an item to identify, document, and control functional and physical characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

In simple terms, configuration management prevents unauthorized, accidental, or uncoordinated modifications to critical programme assets. A Configuration Item (CI) is any entity (document, software module, architectural blueprint, hardware device, or testing environment) that is uniquely identified and managed under configuration control.

                   THE FOUR CORE CONFIGURATION ACTIVITIES

    ┌──────────────────────┐         ┌──────────────────────┐
    │  1. IDENTIFICATION   │         │     2. CONTROL       │
    │  - Classifying CIs   │  ────►  │  - Baseline freezing │
    │  - Naming conventions│         │  - Formal change reqs│
    │  - Version schemas   │         │  - Authority approval│
    └──────────────────────┘         └──────────┬───────────┘
                                                │
                                                ▼
    ┌──────────────────────┐         ┌──────────────────────┐
    │ 4. VERIFICATION &    │         │ 3. STATUS ACCOUNTING │
    │       AUDIT          │  ◄────  │  - Version tracking  │
    │  - Physical vs doc   │         │  - Change history log│
    │  - Compliance audits │         │  - Baseline records  │
    └──────────────────────┘         └──────────────────────┘

The Four Core Activities of Configuration Management

1. Configuration Identification: Deciding which assets constitute Configuration Items, assigning unique identifiers, defining versioning schemas (e.g., v0.1 for drafts, v1.0 for approved baselines), and tagging metadata.
2. Configuration Control: Ensuring that once a CI is baselined, it can never be altered without progressing through a formal change control process. This requires a formal Change Request (CR), impact assessment (analyzing impacts on scope, cost, time, benefits, and risk), and explicit authorization by the designated Change Authority or Programme Board.
3. Configuration Status Accounting: Maintaining an audit trail and historical ledger of all CIs. It records what baselines exist, who approved them, what change requests are currently pending, and which version is currently active in each delivery environment.
4. Configuration Verification and Audit: Conducting periodic physical and documentary audits to confirm that the actual operational capabilities, software versions, and physical infrastructures match the authorized configuration documentation.

Key Programme Baselines Subject to Strict Configuration Control

On an MSP programme, several foundational documents must be baselined and placed under strict change control:

---

The Controlled Document Lifecycle

To ensure that delivery teams and contractors never execute work based on preliminary or unauthorized notes, all programme documentation must progress through four distinct, controlled lifecycle states:

                                THE CONTROLLED DOCUMENT LIFECYCLE

    ┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
    │    1. DRAFT     │ ────► │ 2. UNDER REVIEW │ ────► │   3. APPROVED   │ ────► │  4. ARCHIVED /  │
    │     (v0.x)      │       │     (v0.x)      │       │ BASELINE (v1.0) │       │   SUPERSEDED    │
    │ Author working; │       │ Formal QA check │       │ Formal sign-off;│       │ Retired version;│
    │  no governance  │       │ & peer review;  │       │ binding upon all│       │ preserved for   │
    │  validity yet   │       │ no execution yet│       │ delivery teams  │       │ audit trails    │
    └─────────────────┘       └─────────────────┘       └────────┬────────┘       └─────────────────┘
                                                                 │
                                                    ┌────────────┴────────────┐
                                                    │ Requires Formal Change  │
                                                    │ Control to Amend (v2.0) │
                                                    └─────────────────────────┘

Detailed Lifecycle States

1. Draft (v0.1, v0.2...):
   • Status: The document is under active authoring by a designated specialist or work stream lead.
   • Governance Rule: It carries zero formal authority. Delivery teams and contractors are strictly prohibited from building interfaces, committing capital, or changing operational workflows based on draft documentation.
2. Under Review (v0.8, v0.9...):
   • Status: The draft is complete and undergoing formal stakeholder review, quality assurance checks, and peer evaluation.
   • Governance Rule: Feedback is collated and resolved. The document remains non-binding until formal sign-off is achieved.
3. Approved Baseline (v1.0, v2.0...):
   • Status: The document has received formal sign-off from the designated governance authority (such as the SRO, Programme Board, or Lead Architect).
   • Governance Rule: It is frozen. It represents the official, binding reference point for all project managers and operational teams. No person—not even the original author—may modify it without submitting a formal Change Request.
4. Archived / Superseded:
   • Status: A newer version (e.g., v2.0) has been approved, rendering the previous version (v1.0) obsolete, or the programme has closed.
   • Governance Rule: Obsolete versions are prominently watermarked as "SUPERSEDED" and moved to an archive directory. They are never deleted, ensuring a permanent historical record for statutory compliance, contractual dispute resolution, and post-programme evaluation.

---

Avoiding Document Sprawl and Information Silos

In multi-year transformations involving hundreds of personnel across distributed geographies, document sprawl represents a critical failure mode. Document sprawl occurs when team members generate duplicate files, maintain localized copies on laptop hard drives, or create rogue messaging groups to bypass central repositories.

Practical Mechanisms to Eliminate Sprawl and Silos

• Mandatory Centralized Indexing: The Programme Office maintains a central Master Information Index (or Configuration Library Register) that catalogs every active CI, its exact location in the CDE, its version, and its assigned owner.
• Direct Link Sharing Instead of File Attachments: Programme policies prohibit emailing document attachments. Team members must share secure hyperlinks pointing directly to the canonical file in the CDE, guaranteeing that recipients always view the latest authorized version.
• Automated Document Deprecation and Archival: Implementing automated CDE policies that archive untouched draft files after 90 days and notify authors of upcoming review milestones.
• Periodic Configuration Audits: The PMO conducts unannounced quarterly checks across project delivery environments, verifying that teams are utilizing authorized baselines rather than unvetted local copies.

---

Real-World Organizational Transformation Scenario

FinTech Prime Core Banking Migration

Context: FinTech Prime, a rapidly scaling European digital bank, launched the "Core Horizon Transformation" to replace its legacy card processing core with a high-throughput, microservices-based ledger architecture across four constituent projects: Payments, Accounts, Risk/Fraud, and Mobile Interface.

The Information Failure: During Month 8 of delivery, the lead architect for the Payments project updated the API payload specification to accommodate a mandatory new European instant payment protocol. He saved the updated document as Payment_API_Spec_v1.4_updated.docx in his personal cloud folder and messaged a summary to his immediate team on Slack. He did not notify the Programme Office, submit a Change Request, or update the CDE. For the next three months, the Mobile Interface and Risk/Fraud projects continued developing automated integration pipelines using the Approved Baseline v1.0 stored in the CDE.

When end-to-end integration testing commenced, 85% of all cross-module payment transactions failed immediately. Over 1,200 automated test scripts crashed due to schema validation errors. The programme suffered a 9-week delay, incurred €1.8M in unplanned contractor overtime, and narrowly missed its statutory regulatory compliance launch window.

The Remediation: The Programme Manager and PMO intervened decisively:

1. Automated Baseline Gating: Re-architected the CDE so that code repositories and automated build pipelines could only compile against digitally signed, approved baselines pulled directly from the SSOT.
2. Formal Baseline Change Control: Re-established a weekly Configuration Change Board (CCB) chaired by the Programme Manager and Lead Enterprise Architect. Any proposed alteration to interface specifications required a formal impact assessment across all four projects before sign-off.
3. Deprecation Watermarking: The PMO conducted a sweep of all shared drives, deleting 450 rogue documents and archiving 300 obsolete files, restoring a single, immutable source of truth.

By Tranche 2 cutover, the programme achieved a 99.8% first-time integration success rate across all microservice modules, proving the critical value of disciplined configuration control.

---

Exam Tips & Common Traps

• Exam Tip (The Four Configuration Activities): Memorize the four core activities of configuration management: Identification, Control, Status Accounting, and Verification/Audit. Questions frequently describe an activity (e.g., verifying that installed hardware matches design schematics) and ask you to identify which configuration activity it represents (Verification & Audit).
• Exam Tip (Who Approves Baselines): The Programme Office administers and records configuration baselines, but the Senior Responsible Owner (SRO) or Programme Board holds the formal authority to approve major programme baselines and authorize baseline changes.
• Common Trap (Baseline Rigidity Fallacy): A common distractor claims that "once a document is baselined, it can never be changed under any circumstances." In MSP, baselines are deliberately designed to evolve, but they must evolve through formal change control, impact assessment, and explicit authorization rather than informal, unvetted edits.
• Common Trap (Draft Documents in Delivery): Watch out for scenario questions where a project team accelerates work by utilizing a draft or unapproved specification. In MSP governance, executing work against a draft document is a critical failure that directly compromises programme integrity.