HKSM

Document analysis is a technique for reviewing existing project and organizational records to extract requirements, constraints, assumptions, risks, and lessons, and to spot gaps or inconsistencies. It provides context for planning, elicitation, and risk identification throughout the project life cycle.

Definition

The definition is provided above.

Key Points

• Used early and iteratively to quickly understand context and history.
• Leverages existing artifacts to save time and reduce rework.
• Highlights constraints, compliance obligations, and dependencies.
• Reveals gaps, conflicts, ambiguities, and outdated information.
• Findings should be validated with stakeholders and subject matter experts.
• Often paired with interviews, workshops, and process analysis.

Purpose of Analysis

To build a clear picture of the current state, confirm scope boundaries, and identify known requirements, risks, assumptions, and constraints before deeper elicitation. It helps ensure alignment with policies, contracts, and regulations, and informs planning decisions and risk responses.

Method Steps

• Clarify objectives and decision needs for the review.
• Collect relevant documents and verify versions and sources.
• Prioritize by relevance, authority, and recency.
• Annotate and extract key facts: requirements, constraints, rules, risks, decisions, and owners.
• Cross-check documents to find inconsistencies, overlaps, and gaps.
• Capture findings in structured logs with references to document sections.
• Validate unclear or conflicting items with SMEs and stakeholders.
• Synthesize insights and propose follow-up actions or changes.

Inputs Needed

• Business case and project charter.
• Contracts, statements of work, and procurement documents.
• Policies, standards, procedures, and compliance guidelines.
• Previous project plans, reports, and closure or lessons learned records.
• Requirements documents, user stories, and traceability matrices.
• Process maps, SOPs, and service level agreements.
• Risk registers, issue logs, and assumption logs.
• Change requests and change logs.
• Quality reports, test results, and audit findings.
• Stakeholder registers and communication plans.
• Architectural diagrams, product specs, and data dictionaries.
• Roadmaps, release plans, and performance metrics.

Outputs Produced

• Extracted requirements and acceptance criteria with source references.
• Updates to assumption, constraint, risk, and issue logs.
• Identified gaps, conflicts, and questions list for follow-up.
• Compliance and policy obligations catalog.
• Stakeholder list updates and ownership mapping.
• Traceability matrix updates linking requirements to sources.
• Recommendations for elicitation, analysis, or process improvements.

Interpretation Tips

• Check document authority and recency; favor current, approved sources.
• Distinguish as-is constraints from to-be goals to avoid scope confusion.
• Triangulate important findings across multiple documents.
• Flag ambiguous language and confirm with SMEs, not assumptions.
• Use consistent tagging and citations to make findings auditable.
• Watch for implicit requirements hidden in policies or SLAs.
• Document what is not found when it is expected; absence can signal risk.

Example

A project team planning a customer onboarding improvement reviews the business case, SOPs, SLAs, and complaint reports. They find two different SLA targets for response time and a policy requiring dual approval for high-risk accounts that is missing from the current workflow.

The team logs the conflicts, updates the stakeholder list to include Compliance, validates the approval requirement with SMEs, and uses the findings to guide a focused workshop to resolve the discrepancies and update requirements.

Pitfalls

• Relying on outdated or unofficial documents without version checks.
• Assuming documents are complete and not validating with people.
• Overanalyzing low-value artifacts and delaying elicitation.
• Misreading legal or compliance language without expert review.
• Ignoring contradictions between documents and actual practice.
• Failing to record sources, making traceability and audits difficult.

PMP Example Question

A project manager is initiating a new effort in a regulated environment. To prepare for stakeholder workshops, what is the best first step using document analysis?

1. Interview key stakeholders to gather all requirements before reading existing documents.
2. Review current charters, contracts, policies, and lessons learned to extract known requirements, constraints, and gaps.
3. Create the work breakdown structure using only the project charter and product vision.
4. Brainstorm risks with the team without reviewing prior risk registers to avoid bias.

Correct Answer: B — Review current charters, contracts, policies, and lessons learned to extract known requirements, constraints, and gaps.

Explanation: Document analysis should leverage existing authoritative artifacts to build context and identify gaps before deeper elicitation. This reduces rework and improves the quality of subsequent workshops.