Skip to content

← Chapter 1 Applied Lab · ← Part 2

Part 3 — Changed Fact, Independent Rebuild, DMBOK Debrief & Completion Key

Formatted source: https://docs.google.com/document/d/1ti73eZ5IeeHEbh8etGTJvFQGx0MP5Bzph5Pvkq7Ylws/edit

Lab G — Change one fact

Revisit one of your priorities or recommendations after changing a material condition.

Choose a variation such as:

  • Customer data is still widely reused, but it no longer contains restricted attributes.
  • Product data quality is poor, but the company cannot reliably replenish or sell items until it improves.
  • The revenue KPI lineage is documented, but Finance and Sales still use different business definitions.
  • A proposed platform can scan technical metadata, but stewardship/decision rights remain undefined.

For the changed fact, answer:

  1. What changes in your priority assessment?
  2. Which DMBOK Knowledge Area now leads the problem?
  3. Which part of your Charter/Scope/Roadmap changes?
  4. What evidence would you need before approving the new response?
  5. What tempting response would still be weaker, and why?

The purpose is to prove that you are applying Chapter 1 reasoning rather than memorizing a fixed answer.

Lab H — Independent reconstruction

Close this guide and rebuild the Chapter 1 baseline from a blank page or blank document.

Without looking, reconstruct:

  1. the purpose of Data Management;
  2. at least five reasons data is an unusual asset;
  3. the distinction among lifecycle, lineage and SDLC;
  4. why requirements should precede technology selection;
  5. Charter vs Scope vs Roadmap;
  6. all 11 Knowledge Areas with a one-line purpose for each;
  7. why Data Governance is central but not the whole discipline;
  8. your top Meridian priorities and the evidence that drove them.

Then compare your reconstruction with the Chapter 1 theory package and your completed lab evidence. Correct omissions in a different color or under a “Repair” heading rather than silently rewriting the first attempt.

12. DMBOK Debrief

Answer in complete sentences without copying the guide.

Concept translation

  1. How did the Data Asset Inventory demonstrate that Data Management is broader than database administration?
  2. How did the value/priority exercise reflect the idea that data is an organizational asset with unusual properties?
  3. What did the lifecycle map reveal that a simple system inventory would not?
  4. Why did the requirements-before-technology table matter?
  5. How are Charter, Scope Statement and Roadmap related but different?
  6. Which Meridian issue involved the greatest number of Knowledge Areas, and why did you still choose one lead area for the current question?

Distinction check

Explain the deciding difference for each pair:

  • Data Management vs Data Governance
  • Data Management vs IT Management
  • Lifecycle vs lineage
  • Lifecycle vs SDLC
  • Data Strategy vs Data Management Program Strategy
  • Charter vs Scope Statement vs Implementation Roadmap

Business explanation

Explain to a Meridian executive, in plain language, why the Chapter 1 lab was not “just documentation.” Your answer should connect the work to enterprise value, quality, risk, coordination, prioritization and decision-making.

13. Answer / reconstruction key

The exact rankings and Meridian recommendations can differ if they are supported by evidence. Use the following as the reasoning key, not as a single mandatory business answer.

What strong work should show

Data Asset Inventory: assets are described by business meaning and use, not merely table/file names; multiple systems may represent the same enterprise asset; producing processes, consumers, ownership/stewardship, sensitivity, quality, metadata/lineage and lifecycle concerns are visible.

Value / priority matrix: priority is justified using several factors such as business dependency, reuse, quality exposure, risk, replacement difficulty and opportunity. It does not equate volume with value or invent a universal economic formula.

Lifecycle map: includes planning/creation or acquisition, storage/maintenance, use, transformation/enhancement, sharing and disposal; distinguishes lineage and SDLC; shows cross-cutting quality, metadata, security/risk and governance concerns.

Requirements before technology: expresses the business outcome, definitions, data scope, quality, metadata, security/privacy, lifecycle, integration/latency, governance and evidence requirements before choosing a platform.

Charter: establishes the program mandate, vision, business case, principles/goals, success measures, risks/critical factors and operating intent.

Scope Statement: defines the planning-horizon boundaries, priority goals/domains/processes and accountable roles/organizations/leaders.

Implementation Roadmap: translates direction into sequenced initiatives/projects/tasks/assignments and milestones.

Knowledge Area mapping: recognizes that real issues are cross-domain; chooses a lead area based on the question being answered; does not call Governance the lead for everything merely because it is central in the DAMA Wheel.

Independent rebuild: reproduces the Chapter 1 mental structure without replaying the lab instructions line by line.

14. Completion rubric

Dimension Not yet Working Mastered for this lab
Chapter 1 explanation Can name terms but cannot connect them. Explains most concepts with notes. Explains the Chapter 1 mental model accurately in DAMA language and plain language.
Enterprise asset reasoning Treats assets mainly as tables/systems. Identifies business meaning and some dependencies. Connects business purpose, process, systems, value, risk, quality, metadata and lifecycle.
Strategy artifacts Confuses Charter/Scope/Roadmap. Mostly distinguishes them. Can create and defend each artifact’s distinct purpose.
Knowledge Area reasoning Picks one area by keyword. Recognizes multiple relevant areas. Chooses lead/supporting areas based on the actual question and explains why.
Technology boundary Reaches for tools first. Sometimes states requirements first. Consistently states business/data/governance requirements before implementation choices.
Evidence Notes are incomplete or unsupported. Most outputs exist. Evidence package is inspectable, coherent and supports the conclusions.
Independent reconstruction Needs the tutorial. Rebuilds much of it with prompts. Rebuilds and explains the core logic from a blank page.

15. Source / implementation notes

  • DAMA-specific meaning is controlled by DAMA-DMBOK2 Revised, Chapter 1 — Data Management and the Chapter 1 Mastery package.
  • Meridian company facts, systems, domains, personas, stable issue IDs and incidents come from the Meridian Commerce Group Enterprise Data Management Casebook.
  • Inventory fields, scoring scales, evidence filenames, exact priority decisions and strategy recommendations are Meridian instructional design choices, not DAMA-prescribed mandatory templates.
  • Technology is intentionally light in this Chapter 1 lab. Later 00C technology gates introduce SQL/PostgreSQL/Python/pandas only when dependent chapters need them.
  • Save your actual learner errors separately. Do not create Chapter 1 Artifact 08 until real performance evidence exists.

Lab completion record

Record the completed lab in the Master Tracker / evidence system with:

  • lab ID / chapter;
  • date;
  • evidence link;
  • scaffold level;
  • independent rebuild result;
  • DMBOK debrief score;
  • mistakes/repair notes;
  • next revisit trigger.

Back to Chapter 1 Applied Lab Hub