Manage Project Artifacts
QuαΊ£n lΓ½ CΓ‘c tΓ i liα»u vΓ Hiα»n vαΊt Dα»± Γ‘n
Artifacts lΓ mα»i tΓ i liα»u, template, baseline, log, report Δược tαΊ‘o ra trong suα»t dα»± Γ‘n. PM phαΊ£i ΔαΊ£m bαΊ£o chΓΊng Δược tαΊ‘o ΔΓΊng, maintained ΔΓΊng, vΓ accessible ΔΓΊng ngΖ°α»i.
π PMBOK 7 Artifact Categories
πΊπΈ English
PMBOK 7th Edition organizes project artifacts into categories rather than prescribing specific documents. The key types:
- Strategy artifacts: Business case, project charter, roadmap, vision statement
- Logs and registers: Risk register, issue log, change log, stakeholder register, assumption log
- Plans: Project Management Plan + all subsidiary plans
- Hierarchy charts: WBS, OBS (Org Breakdown Structure), RBS (Risk Breakdown Structure)
- Baselines: Scope baseline, schedule baseline, cost baseline (together = performance measurement baseline)
- Visual data & information: Burndown charts, dashboards, Gantt charts, EVM reports
- Reports: Status reports, progress reports, forecast reports
- Agreements & contracts: MOUs, SLAs, contracts, SOW
Reference: PMBOK Guide 7th Edition
π»π³ TiαΊΏng Viα»t
PMBOK 7th Edition tα» chα»©c project artifacts thΓ nh cΓ‘c danh mα»₯c thay vΓ¬ quy Δα»nh tΓ i liα»u cα»₯ thα»:
- Strategy artifacts: Business case, project charter, roadmap
- Logs and registers: Risk register, issue log, change log, stakeholder register
- Plans: Project Management Plan + cΓ‘c subsidiary plans
- Baselines: Scope + Schedule + Cost (= Performance Measurement Baseline)
- Visual data: Burndown charts, dashboards, Gantt charts, EVM reports
- Reports: Status reports, progress reports, forecast reports
π Key Artifacts Reference
| Artifact | Purpose | Owner | Updated When | Agile Equivalent |
|---|---|---|---|---|
| Project Charter | Authorize project, name PM | Sponsor | Major scope changes only | Project brief / vision statement |
| Project Management Plan | How to execute, monitor, control | PM | Via change control | Team agreements + sprint schedule |
| Scope Statement | Define project + product scope | PM | Approved changes | Product vision + roadmap |
| WBS | Break down all work | PM + Team | Approved scope changes | Product Backlog |
| Risk Register | Track risks, responses, owners | PM | Continuously (every sprint/review) | Risk log (same concept) |
| Issue Log | Track active issues and resolution | PM | As issues arise/resolve | Impediment log |
| Change Log | Track all change requests and decisions | PM | Every change request | Backlog change history |
| Stakeholder Register | Track stakeholder info, interest, engagement | PM | When stakeholders change | Same concept |
| RACI Matrix | Clarify roles for activities/decisions | PM | Org/resource changes | Team agreements, sprint roles |
| Lessons Learned Register | Capture knowledge for future use | PM + Team | Throughout + at closure | Retrospective outputs |
π Status Reporting
πΊπΈ English
Status reports communicate project health to stakeholders. They should be: accurate, timely, actionable, and audience-appropriate.
RAG status (Red/Amber/Green): Quick visual indicator of project health. Red = problem requiring action. Amber = at risk, monitoring. Green = on track.
Dashboard vs detailed report: Executives need dashboards (1-page summary, RAG, key metrics). Working teams need detailed status (tasks, blockers, next steps).
π»π³ TiαΊΏng Viα»t
Status reports truyα»n ΔαΊ‘t tΓ¬nh trαΊ‘ng dα»± Γ‘n cho stakeholders. CαΊ§n: chΓnh xΓ‘c, kα»p thα»i, cΓ³ thα» hΓ nh Δα»ng, phΓΉ hợp vα»i Δα»i tượng.
RAG status: Chα» bΓ‘o nhanh vα» sα»©c khα»e dα»± Γ‘n. Δα» = cαΊ§n hΓ nh Δα»ng. VΓ ng = Δang theo dΓ΅i rủi ro. Xanh = ΔΓΊng tiαΊΏn Δα».
Weekly Status Report Template
Project: Project Alpha | Period: 2024-W23 | PM: [Name]
ββ OVERALL STATUS ββββββββββββββββββββββββββββββββββββββββ
Schedule: π‘ AMBER (SPI = 0.92, 3 days behind, recovery plan in place)
Budget: π’ GREEN (CPI = 1.05, $8K under budget)
Scope: π’ GREEN (Scope baseline intact, 1 CR pending CCB)
Quality: π’ GREEN (0 critical bugs in current sprint)
ββ THIS WEEK COMPLETED ββββββββββββββββββββββββββββββββββ
β
Auth service unit tests (100% coverage)
β
Partner Bank A sandbox integration (basic flow working)
β
Sprint 8 review with stakeholders β all demos accepted
ββ NEXT WEEK PLANNED βββββββββββββββββββββββββββββββββββββ
β Complete Partner Bank A error handling (8 SP)
β Performance testing baseline run
β CCB review for CR-047 (API auth header change)
ββ RISKS & ISSUES ββββββββββββββββββββββββββββββββββββββββ
β οΈ R-001: Partner API sandbox stability β monitoring, mock server ready
π΄ I-003: Performance test environment not provisioned β escalated to IT
ββ DECISIONS NEEDED βββββββββββββββββββββββββββββββββββββ
β Approve CR-047 scope trade-off? β CCB meeting Thursday 2pm
Exam Tips β Artifacts Management
- Artifacts are living documents β not create-and-forget. Keep them updated.
- Baselines (scope/schedule/cost) can only be changed via formal change control
- Risk register, issue log, change log = separate documents that work together
- In Agile: information radiators (burndown, kanban boards) replace many formal status reports
- Lessons learned: captured throughout the project, not only at the end
- Project charter cannot be changed by the PM alone β requires sponsor approval
πΌ Thα»±c chiαΊΏn / Scenario
FinTech Company X β Artifact Management System
Context: Project Alpha cΓ³ 15 team members, 3 external stakeholders, and 2 partner organizations. PM needs a clear artifact management approach.
Artifact system setup:
- Confluence: Project Charter (read-only after approval), PM Plan, meeting notes, all technical specs, lessons learned
- Jira: Product backlog, sprint boards, issue log (linked to Jira tickets), change log
- Spreadsheet (shared): Risk register, stakeholder register, RACI matrix
- Weekly Slack post: RAG status report to project channel
- Monthly email: Formal status report to sponsor and partner PMs
Access control: External partners have read access to partner-relevant Confluence pages only. Internal team has full Jira access. Sponsor receives monthly email + can view executive dashboard.
PMP lesson: Artifact management isn't just about what documents exist β it's about who can access, update, and rely on them. Consistency and accessibility are as important as completeness.
βοΈ Practice Questions
Question 1
A PM discovers that team members are making updates to the project schedule directly without going through change control. The schedule is a project baseline. What should the PM do?
- A. Allow it since the team has the best information about schedule needs
- B. Immediately reinforce that baselines can only be changed via approved change requests, and restore the original baseline
- C. Accept the changes and create a new baseline
- D. Report the team members to senior management for policy violation
β
Answer: B β Baselines (scope, schedule, cost) are formally approved and can only be changed through the change control process. Unauthorized changes to baselines undermine the ability to measure project performance (EVM requires a stable baseline). The PM must restore integrity by reinstating the approved baseline and processing any needed changes formally. Option D is an overreaction; this is a training issue, not misconduct.
Question 2
A project manager joins a project midway and discovers the project schedule has been updated three times in the past month without any approved change requests. What is the MOST significant problem?
- A. The schedule is inaccurate
- B. Project performance cannot be measured because the baseline keeps moving without authorization β EVM and variance analysis become meaningless
- C. The team is working too hard
- D. The sponsor was not informed
β
Answer: B β Unauthorized baseline changes destroy the ability to measure performance. Earned Value Management (EVM) requires a stable, approved baseline to calculate SV, CV, SPI, and CPI. When the baseline moves without authorization, there is no reliable reference point β you cannot tell if the project is ahead or behind. While the sponsor not being informed (D) is also a problem, the loss of performance measurement integrity is the most significant consequence.
Question 3
Which artifact would a PM use to track who needs to approve a database architecture change versus who just needs to be informed?
- A. Risk Register
- B. RACI Matrix
- C. Issue Log
- D. Communication Management Plan
β
Answer: B β The RACI Matrix (Responsible / Accountable / Consulted / Informed) is the artifact specifically designed to clarify decision rights and communication expectations for each role on each activity or deliverable. It directly answers "who approves vs. who is notified." The Communication Management Plan (D) describes how information is distributed but doesn't assign roles to specific decisions the way RACI does.
π€ AI Tools for PMs
How AI Augments This Process
AI helps PMs generate project artifacts quickly, review existing artifacts for completeness, create artifact templates tailored to methodology, and build a project document index.
Sample Claude Prompts
Artifact generation for new project
I'm starting a new project and need to quickly build core project artifacts. Help me generate templates.
Project: [name and brief description]
Methodology: [Predictive / Agile / Hybrid]
Team size: [number]
Duration: [months]
Key deliverables: [list main outputs]
Stakeholder complexity: [simple / multi-stakeholder / external partners]
Generate templates (with pre-filled sections where possible) for:
1. Project Charter (key sections: purpose, objectives, scope, stakeholders, authority)
2. Stakeholder Register (columns: name, role, interest, influence, current stance, engagement strategy)
3. Risk Register (columns: ID, description, category, probability, impact, score, response, owner, status)
4. Assumptions Log (columns: ID, assumption, owner, validation method, status, impact if wrong)
5. Change Log (columns: CR#, description, requestor, date, impact summary, decision, date decided)
6. Issue Log (columns: issue ID, description, impact, owner, due date, status, resolution)
7. Lessons Learned Register (columns: ID, category, description, impact, recommendation, applied to)
For Agile projects, also include:
8. Product Backlog structure (Epic β Feature β Story hierarchy with fields)
9. Sprint velocity tracker
Artifact quality review
Review this project artifact for completeness, clarity, and PMP best practice alignment.
Artifact type: [risk register / project charter / comms plan / etc.]
[Paste the artifact content here]
Review against:
1. Completeness: Are all required fields populated? What's missing?
2. Clarity: Are entries specific and actionable, or vague? (e.g., "risk: something might go wrong" = not useful)
3. Accuracy: Are assumptions well-supported? Are estimates reasonable?
4. Consistency: Do entries reference the same project context consistently?
5. PMP alignment: Does this match PMBOK 7 best practices for this artifact type?
6. Actionability: Can someone use this artifact to make decisions?
Output: Scored review (1-5 per dimension) with specific improvement recommendations and rewritten examples for weak entries.
Methodology-appropriate artifact selection
I'm setting up a new project and need to decide which artifacts to create and maintain.
Project characteristics:
Methodology: [Predictive / Agile / Hybrid]
Duration: [months]
Team size: [number]
Organizational requirements: [PMO-required docs / regulatory documentation]
Stakeholder formality needs: [formal sign-offs required / informal agile style]
Risk level: [high / medium / low]
Help me:
1. Recommend the minimum viable artifact set for this project (what's essential vs. nice-to-have)
2. Identify which artifacts are required for compliance vs. optional for project management
3. Design the artifact lifecycle (when each is created, updated, and closed)
4. Suggest where to store each artifact (Confluence / Jira / shared drive)
5. Create a Document Management Plan table
Avoid over-documentation β recommend a lean artifact set that provides value, not just compliance.
Jira / Confluence Template
Confluence β Project Artifact Index
ββ CONFLUENCE: PROJECT ARTIFACT INDEX βββββββββββββββββββ
Project: [Project Alpha] | PM: [name] | Updated: [YYYY-MM-DD]
Purpose: Single source of truth β all project documents linked here
ββ FOUNDATION DOCUMENTS ββββββββββββββββββββββββββββββββββ
Project Charter: [Confluence link] | Approved: [date] | Version: 1.0
Project Management Plan: [Confluence link] | Baseline: [date]
Stakeholder Register: [Confluence link] | Last updated: [date]
Project Glossary: [Confluence link] | Last updated: [date]
ββ PLANNING ARTIFACTS ββββββββββββββββββββββββββββββββββββ
WBS / Product Backlog: [link] | Baseline: [date]
Schedule / Roadmap: [link] | Last updated: [date]
Budget Tracker: [link] | Last updated: [date]
Risk Register: [Jira filter link] | Open risks: [count]
Assumptions Log: [link] | Open items: [count]
ββ EXECUTION ARTIFACTS βββββββββββββββββββββββββββββββββββ
Change Log: [Jira filter link] | Open CRs: [count]
Issue Log: [Jira filter link] | Open issues: [count]
Status Reports: [Confluence folder link]
Decision Log: [link] | Last decision: [date]
ββ CLOSURE ARTIFACTS βββββββββββββββββββββββββββββββββββββ
Lessons Learned: [link] | Final Report: [link] | Archive: [link]