PMBoot Waterfall Studio V1.3 | Waterfall PM Simulator

📋 Phase 1 — Requirements Analysis

Foundation

Overview

Stakeholders

Scope

Requirements

Constraints

Artifacts

Gate Review

📋 Requirements Analysis

This is the most critical phase in Waterfall. Mistakes here cascade through every subsequent phase. Your goal is to fully understand WHAT the system must do — before anyone writes a single line of code.

BRDSRSProject CharterFeasibility Study

Identify all stakeholders and their interest/influence levels

Define clear business objectives (measurable, time-bound)

Document what is IN scope and OUT of scope

Capture all Functional Requirements (FR) — what the system shall do

Capture all Non-Functional Requirements (NFR) — how well it shall do it

List constraints and assumptions that affect delivery

PM Tip: Use the SMART criteria for objectives — Specific, Measurable, Achievable, Relevant, Time-bound. Vague objectives lead to scope creep.

A stakeholder is anyone who affects or is affected by the project. Document their interest and power (influence) so you know who to engage and how.

Name	Role	Type	Interest	Power
No stakeholders yet — add your first one above.

Scope creep is the #1 cause of project failure. Be explicit about what you will AND will not build.

Business Objectives (one per line or add individually)

✅ In Scope

❌ Out of Scope

Functional Requirements (FR)

ID	Description	Priority	Category
No functional requirements yet.

Non-Functional Requirements (NFR)

ID	Description	Type	Criteria
No non-functional requirements yet.

Constraints are limitations you cannot change — budget, timeline, technology, regulations.

Assumptions are things you believe to be true but haven't confirmed. Document them so they can be challenged.

All documents are generated from your inputs. Fill in the previous tabs first for complete, meaningful artifacts.

📄

Business Requirements Doc

Objectives, stakeholders, scope, requirements

📋

Software Requirements Spec

Detailed FR & NFR with acceptance criteria

🏛️

Project Charter

Formal authorization, PM authority, objectives

🔍

Feasibility Study

Technical, financial, and operational viability

🔒 Phase Gate 1 — Stakeholder Review

All items below must be satisfied before the stakeholder committee approves progression to System Design.

🏗️ Phase 2 — System Design

Architecture

Overview

Architecture

Modules

Tech Stack

Database

Artifacts

Gate Review

🏗️ System Design

Translate requirements into a technical blueprint. Define how the system will be structured, what technologies will be used, and how data will flow. This document becomes the Bible for your developers.

System Design DocumentTechnical SpecDB Design

Select architecture pattern (Monolithic, Microservices, Layered, etc.)

Break the system into modules/components with responsibilities

Choose technology stack for frontend, backend, database, and server

Define the database schema — key tables and their purposes

PM Tip: Even if you're not technical, you need to understand the architecture. It affects timeline, team skills needed, risk, and cost.

Architecture Pattern

🧱

Monolithic

Single deployable unit, simpler for small teams

⚙️

Microservices

Independent services, scalable for large systems

📚

Layered (N-Tier)

Presentation → Business → Data layers

🖥️

Client-Server

Thin clients calling centralized server

Define each major module/component of the system — its name, responsibility, and how many API endpoints it will expose.

#	Module Name	Responsibility	APIs
No modules defined yet.

Document your technology choices. These decisions affect cost, team hiring, performance, and long-term maintainability.

Frontend Technology

Backend Technology

Database

Server / Cloud

Version Control

CI/CD Tool

Define the key database tables. You don't need every column — focus on the main entities and their purpose.

Table Name	Purpose	Key Columns
No tables defined yet.

🏗️

System Design Document

Architecture, modules, integrations

⚙️

Technical Specification

Tech stack, standards, API contracts

🗄️

Database Design Document

ER diagram description, tables, relationships

🔒 Phase Gate 2 — Architecture Review Board

Technical and business stakeholders must approve the design before implementation begins.

📊 Phase 3 — Implementation Planning

Planning

Overview

WBS

Team

Risk Register

Gantt

Artifacts

Gate Review

📊 Implementation Planning

Before a single developer writes code, you need a detailed plan. Break the work down, assign it to people, identify what could go wrong, and create a realistic timeline.

WBS DocumentRACI MatrixRisk RegisterGantt Chart

Build Work Breakdown Structure — decompose deliverables into tasks

Assign team members with clear roles (use RACI)

Identify and score all risks; create mitigation plans

Create timeline with milestones and dependencies

The Work Breakdown Structure decomposes the project into manageable chunks. Each item should be small enough to estimate and assign.

ID	Task / Deliverable	Phase	Duration
No WBS items yet.

Define your project team. Each person's role will be used to generate the RACI matrix in the artifacts.

Name	Role	Availability
No team members yet.

Risk management is proactive. Identify risks before they become issues. Rate probability (1–5) × impact (1–5) = risk score.

Risk Description

ID	Description	Category	P	I	Score	Level	Owner
No risks identified yet.

🔒 Phase Gate 3 — Project Plan Review

Sponsor and PMO must approve the project plan before development can begin.

🧪 Phase 4 — Testing

Quality Assurance

Overview

Test Cases

Execution

Defect Log

UAT

Artifacts

Gate Review

🧪 Testing Phase

Testing ensures the system meets the requirements defined in Phase 1. Write test cases BEFORE testing (Test-First approach), then execute and log every defect found.

Test PlanTest ReportDefect LogUAT Sign-off

Write test cases mapped to functional requirements

Execute all test cases — record Pass/Fail/Blocked results

Log every defect with severity and priority

Conduct User Acceptance Testing (UAT) with real users

Get UAT sign-off — no open Critical defects allowed

ID	Name	Req ID	Type	Priority	Status
No test cases created yet.

Execute each test case and record the result. Click the status buttons to mark Pass, Fail, or Blocked.

ID	Test Case	Expected	Actual Result	Status
Create test cases first in the Test Cases tab.

Every defect found during testing must be logged. No going to production with open Critical defects.

ID	Title	Test Case	Severity	Status	Edit
No defects logged yet — great sign!

UAT is performed by real end users, not the development team. They verify the system meets business needs, not just technical specs.

📝

Test Plan

Test strategy, scope, resources, schedule

📊

Test Execution Report

Results summary with pass/fail/defect stats

✅

UAT Sign-off Document

User acceptance confirmation with signatures

🔒 Phase Gate 4 — QA Sign-off

QA Lead and Business Owner must confirm all tests passed and no critical defects remain open.

🚀 Phase 5 — Deployment

Go-Live

Overview

Checklist

Go / No-Go

Release Notes

Artifacts

Gate Review

🚀 Deployment Phase

This is go-live day. Every step must be followed precisely. Deployment failures can cause data loss, downtime, and reputational damage. Have your rollback plan ready before you press deploy.

Deployment PlanRelease NotesUser Manual

Golden Rule: Never deploy on a Friday. Prefer Tuesday–Thursday mornings with the full team available for immediate hotfix support.

Every item must be checked before requesting Go/No-Go approval. This is a safety gate — don't skip anything.

Progress: 0/0 items completed

The Go/No-Go meeting brings together all stakeholders for a final decision. It can only be called after the deployment checklist is 100% complete.

Target Deployment Environment Deployment Date & Time Rollback Plan (if deployment fails)

Release notes inform users, stakeholders, and support teams about what changed in this release.

Version Number

New Features

Bug Fixes

Known Issues / Limitations

🚀

Deployment Plan

Steps, environment, rollback procedure

📄

Release Notes

New features, fixes, known issues

📖

User Manual Outline

Module-by-module user guide

🔒 Phase Gate 5 — Go-Live Approval

Production deployment requires sign-off from PM, Tech Lead, and Business Owner.

🔧 Phase 6 — Maintenance

Post-Launch

Overview

Change Requests

Lessons Learned

PIR

Closure

Artifacts

🔧 Maintenance Phase

The project is live — but your job as PM isn't done. Manage incoming change requests, capture lessons learned for future projects, and formally close the project with a Post-Implementation Review.

Change Request LogLessons LearnedPIR ReportClosure Certificate

Every change after go-live must go through formal change control. No informal "quick fixes" — document everything.

ID	Title	Requested By	Priority	Status
No change requests yet.

Lessons learned benefit future projects. Be honest — what went well, what didn't, and what will you do differently next time?

Category	What Went Well	Improve	Action
No lessons captured yet.

Project Closure

Once you generate the closure certificate, this project is formally closed. All deliverables have been handed over and stakeholders have signed off.

📋

Change Request Log

All post-go-live change requests

📚

Lessons Learned Document

Retrospective for future projects

📊

Post-Implementation Review

Objectives vs actuals report

🏆

Project Closure Certificate

Formal project completion certificate

👨‍💼

PM Mentor

Alex Rivera

Welcome! Set up your project to begin the waterfall simulation. Choose a domain that interests you — the sample project will show you a complete example.

Phase Progress