HKSM

Text-oriented formats are narrative or tabular descriptions used to capture project information such as roles, responsibilities, deliverable details, and requirements. They add clarity where visuals are insufficient and commonly appear as role descriptions, WBS dictionary entries, or requirement statements.

Key Points

• Plain-text or tabular narratives that describe roles, work, and requirements in a structured way.
• Commonly used for role descriptions, WBS dictionary entries, acceptance criteria, and requirement statements.
• Help analyze ownership, scope boundaries, and handoffs when diagrams are not enough.
• Easy to create and maintain with templates; suitable for remote and document-centric teams.
• Complement visual tools like RAM/RACI, org charts, and process maps; they do not replace them.
• Improve traceability and audits by capturing sources, dates, and versions.

Purpose of Analysis

Use text-oriented formats to clarify exactly who does what, what is being delivered, and how it will be verified. They reduce ambiguity, support alignment across stakeholders, and provide a durable record for planning, execution, and control.

Method Steps

• Define the objective and scope of the description (roles, deliverables, requirements, or handoffs).
• Select a template and fields (for roles: responsibility, authority, competencies; for deliverables: ID, description, acceptance criteria, assumptions, constraints, owner).
• Gather inputs from existing artifacts and stakeholder interviews.
• Draft concise, testable statements using clear verbs and measurable conditions.
• Cross-check for alignment with WBS, RAM/RACI, schedule, and requirements.
• Review with stakeholders and refine to remove gaps and overlaps.
• Version-control and integrate into the relevant management plan or repository.

Inputs Needed

• Project charter and business objectives.
• Scope statement, WBS, and WBS dictionary templates.
• Stakeholder register and team roster.
• Resource management artifacts such as RAM/RACI, OBS/RBS.
• Requirements documentation or backlog items.
• Organizational policies, role catalogs, and document templates.
• Assumptions and constraints log.

Outputs Produced

• Role and responsibility descriptions with authority and competency expectations.
• Updated WBS dictionary entries including acceptance criteria.
• Requirement statements with clear, testable conditions.
• Documented interfaces and handoffs between roles or teams.
• Updates to the assumptions, constraints, and traceability records.
• Versioned documents stored under configuration control.

Interpretation Tips

• Use unambiguous, measurable language; avoid vague terms like manage or support without specifics.
• Keep entries concise and structured; one idea per bullet or field.
• Record source, owner, date, and version to aid traceability.
• Validate with accountable stakeholders to confirm feasibility and authority.
• Reconcile with visuals (RACI, org charts, process maps); resolve any conflicts immediately.

Example

Role Description (excerpt)

• Role: Quality Lead.
• Responsibilities: Define test strategy; approve acceptance criteria; track defects; report quality status weekly.
• Authority: Stop release if exit criteria are not met.
• Competencies: Test planning, risk-based testing, defect triage.
• Interfaces: Product Owner, Delivery Lead.

WBS Dictionary Entry (excerpt)

• WBS ID: 3.1.2.
• Deliverable: User Guide.
• Description: Concise end-user instructions for all major features.
• Acceptance Criteria: Covers top 10 workflows; readability score ≥ 60; approved by Product Owner.
• Assumptions: SMEs available 2 hours/week for review.
• Constraints: Max 40 pages; English language.
• Owner: Documentation Lead.

Pitfalls

• Overly long narratives that hide decisions and make maintenance hard.
• Vague statements that are not testable or assignable.
• Copying templates without tailoring to the project context.
• Poor version control leading to conflicting descriptions.
• Not linking entries to WBS, schedule, or RACI, causing misalignment.
• Skipping stakeholder review and sign-off, which undermines buy-in.

PMP Example Question

A project manager finds that the org chart and RACI do not convey detailed responsibilities and required competencies for each role. What should the PM use to document this level of detail?

1. Responsibility assignment matrix.
2. Text-oriented formats.
3. Stakeholder engagement plan.
4. Project schedule network diagram.

Correct Answer: B — Text-oriented formats

Explanation: Text-oriented formats provide narrative role descriptions, competencies, and interfaces that go beyond what a RAM/RACI or org chart shows. They are ideal when more detail is needed to remove ambiguity.