Project Management Fundamentals and Methodologies Questions

Requirements definition:

• Waterfall: Detailed, up-front, contract-style requirements (good when regulations mandate a fixed spec). Low ambiguity before design starts.
• Agile: Evolves requirements via user stories and iterative discovery; prioritizes working increments and continuous stakeholder feedback.

Baselining:

• Waterfall: Single baseline (requirements → design → build). Baseline changes are formal and infrequent.
• Agile: Frequent mini-baselines per sprint/release (backlog snapshots, sprint commitments). Traceable snapshots over time rather than one monolithic baseline.

Traceability:

• Waterfall: Usually implemented end-to-end (requirements→design→test→release) with formal artefacts and a traceability matrix.
• Agile: Achieved via tooling (JIRA/DevOps links), story→task→test links, acceptance criteria, and automated test evidence. Emphasize living links instead of static matrices.

Change control:

• Waterfall: Formal change requests, impact analysis, gating approvals — predictable but slow.
• Agile: Change via backlog reprioritization each iteration; controlled releases and Definition of Done manage risk. Regulatory changes trigger change-control spikes or gated releases.

Acceptance:

• Waterfall: Formal acceptance testing against baselined requirements.
• Agile: Continuous acceptance (story/feature acceptance tests, demos), with final compliance/regulatory acceptance at release milestones.

When to choose:

• Waterfall: Highly regulated programs with fixed contractual requirements, long approval cycles, and heavy audit needs.
• Agile: Products needing frequent user feedback, evolving regs where incremental delivery reduces risk, or when time-to-market and iterative validation matter.
• Hybrid: Regulatory core (Waterfall for safety/security-critical features) + Agile for non-critical features and UX/analytics—combines auditability with adaptability.

Practical steps to maintain traceability in Agile:

1. Use a single ALM tool (JIRA/Azure DevOps) and enforce linking: epic→story→task→test→release.
2. Define unique requirement IDs and include them in code commits, PRs, and test cases.
3. Automate traceability reports via CI/CD (generate evidence bundles for audits).
4. Maintain sprint-level baselines (release notes + backlog snapshot).
5. Use templates for acceptance criteria that map to regulatory clauses.
6. Perform periodic traceability audits and keep an evidence repository (artifacts, test results, approvals).

This approach balances regulatory rigor with delivery agility; recommend a hybrid when audits mandate formal baselines but product evolution and user feedback remain important.

RACI Matrix (roles → stages). Key: R=Responsible (does the work), A=Accountable (single owner), C=Consulted, I=Informed.

Elicitation

• Business-owner: C
• Product-manager: A
• Solutions-architect: R/C (lead technical elicitation)
• Lead-developer: C
• QA: C
• Operations: C
• Legal: I

Documentation

• Business-owner: C
• Product-manager: A
• Solutions-architect: R (produce technical requirements & constraints)
• Lead-developer: C
• QA: C
• Operations: C
• Legal: C (if compliance language)

Approval

• Business-owner: A
• Product-manager: R
• Solutions-architect: C
• Lead-developer: I
• QA: I
• Operations: I
• Legal: C (sign-off on terms)

Development Handoff

• Business-owner: I
• Product-manager: A
• Solutions-architect: R (handoff package + architecture)
• Lead-developer: R (accept and plan)
• QA: I
• Operations: C
• Legal: I

Testing

• Business-owner: I
• Product-manager: A
• Solutions-architect: C
• Lead-developer: R (deliver testable builds/fixes)
• QA: R/A for test execution & sign-off
• Operations: C (env readiness)
• Legal: I

Acceptance

• Business-owner: A (final acceptance)
• Product-manager: R (coordinate UAT)
• Solutions-architect: C
• Lead-developer: C
• QA: C
• Operations: I
• Legal: I

Change Control

• Business-owner: C
• Product-manager: R (submit/triage changes)
• Solutions-architect: C (impact analysis)
• Lead-developer: C (effort estimate)
• QA: C
• Operations: C
• Legal: I/A for contractual changes

Typical conflicts and resolution using RACI + governance

1. Ambiguous ownership (e.g., product vs. architecture on a non-functional requirement)

   • Fix: Ensure single A in matrix (for NFRs assign Solutions-architect accountable for technical feasibility, Product-owner accountable for business acceptance). Use an RACI charter in kickoff and require sign-off before dev.

2. Scope creep via informal stakeholder requests

   • Fix: Enforce change-control cadence (weekly CAB or triage meeting). Product-manager logs requests; Solutions-architect provides impact; Business-owner approves. RACI ensures no one bypasses formal channel.

3. Delays at handoff (dev says docs inadequate)

   • Fix: Define handoff checklist (artifact templates, API contracts, acceptance criteria). Make Solutions-architect Responsible for artifacts and Lead-developer Responsible for formal acceptance; Product-manager Accountable for readiness gating.

4. QA late involvement causing rework

   • Fix: Move QA to Consulted/Responsible earlier (testing in RACI at documentation and handoff). Use “Definition of Ready” that requires test cases and environments before development starts.

5. Legal/compliance discovered late

   • Fix: Include Legal as Consulted on documentation and Approval stages; escalate via governance if compliance risk > threshold — require Legal A for contractual changes.

Operationalizing governance

• Publish RACI with examples in project charter and run a one-page roles & escalation flow.
• Gate artifacts at stage exits with required sign-offs (single A’s signature).
• Quarterly reviews of RACI effectiveness; adjust when recurring disputes appear.
• Use metrics: avg time to approval, % rework due to missing artifacts, change-request backlog — report to steering committee.

Why this suits a Solutions Architect

• Clarifies technical vs. business accountability, reduces rework, ensures architectural constraints are enforced early, and provides a clear escalation path when trade-offs are needed.