Phase Overview

Purpose

Understand the problem space before making commitments. Build trust with stakeholders, surface constraints, and establish shared understanding of success.

The Universal Pattern

Regardless of project size or methodology, alignment follows these steps:

1. Understand the need: What problem? Why now?
2. Identify stakeholders: Who cares? Who decides?
3. Surface constraints: What limits our options?
4. Assess risk: What could go wrong?
5. Estimate effort: How much work?
6. Get agreement: Are we aligned to proceed?

The depth and formality scale with scope and risk, but these questions remain constant.

Entry & Exit

You start with: A project concept or business need

You deliver: Approved project charter with stakeholder sign-off

Core Activities

1. Initial Stakeholder Discovery

Set expectations and understand the landscape.

Key Questions:

• What problem are we solving? Why now?
• What does success look like?
• Who else needs to be involved?
• What are the hard constraints (timeline, budget, technology, compliance)?
• What keeps you up at night about this project?

How to Do This Well:

• Listen more than you talk—take notes, ask clarifying questions, observe dynamics
• Don’t jump to solutions yet—stay neutral and build trust first
• Demonstrate genuine interest in stakeholder needs, not just their requirements
• In every meeting, ask “Who else should be involved?”

2. Requirements Discovery

Translate business needs into clear, prioritized requirements.

Functional Requirements:

• What tasks must users complete?
• What business rules govern the process?
• What data needs to be captured or integrated?

Architectural Characteristics (often missed):

• Performance: Response time, throughput expectations
• Scalability: Growth projections for users and data
• Availability: Uptime requirements
• Security: Authentication, authorization, data protection (see Security Foundations)
• Compliance: Regulatory requirements (GDPR, HIPAA, etc.) (see Compliance & Governance)

Prioritization:

• Must have vs. should have vs. could have
• MVP scope vs. future enhancements
• Force-rank if everything is “critical”

How to Do This Well:

• Ask “why” repeatedly to get to root needs
• Probe for architectural characteristics explicitly—stakeholders often forget them
• Push for measurable, testable criteria (not “it should be fast” but “page loads < 2 seconds”)
• Document acceptance criteria clearly so there’s no ambiguity later
• Think holistically about how requirements impact architecture

3. Constraint & Risk Assessment

Surface limitations and potential blockers while they’re cheap to address.

Constraints to Document:

• Technical (platform mandates, technology restrictions, integration requirements)
• Resource (budget, team size/skills, timeline pressures)
• Compliance (industry standards, data residency, audit requirements)
• Organizational (governance policies, procurement processes, support requirements)

Risk Categories:

• Technical: New technologies, complex integrations, unknowns
• Schedule: Aggressive timelines, resource availability
• Business: Market timing, competitive pressure
• Organizational: Stakeholder alignment, political challenges
• Operational: Deployment complexity, support readiness

Risk Mitigation Approaches:

• Avoid: Change approach to eliminate risk
• Mitigate: Reduce likelihood or impact
• Transfer: Use vendors/insurance to shift risk
• Accept: Acknowledge and plan contingency

How to Do This Well:

• Extract implicit constraints—stakeholders often assume you know their limitations
• Challenge “requirements” that are actually preferences
• Quantify risks with likelihood and impact scoring
• Map dependencies on other teams/systems explicitly
• Budget time for organizational overhead (approvals, procurement, access delays)
• Be honest about uncertainties—don’t sugarcoat risks

4. Initial Sizing & Estimation

Provide realistic ballpark estimates for go/no-go decisions.

Estimation Approach:

• Break the solution into major components or epics
• Estimate effort using analogous estimation, planning poker, or t-shirt sizing
• Include infrastructure, operational costs, testing, deployment, and documentation
• Add a contingency buffer (typically 20-30%)
• Involve the team; engineers doing the work should validate estimates

Provide Ranges, Not Point Estimates: “4-6 months” is more honest than “5 months.” Explain your methodology and assumptions clearly so stakeholders understand the reasoning, and flag high-uncertainty areas explicitly.

Be realistic, not optimistic. Frame alignment as risk mitigation.

Feasibility Assessment:

• Go: Estimates fit within constraints
• No-Go: Not feasible, recommend cancellation
• Pivot: Adjust scope/timeline/approach to make feasible

Visual Communication During Alignment

Purpose

Use diagrams to build shared understanding, not to create documentation.

During Align, visualization serves discovery. The goal is to ensure stakeholders share the same mental model of the problem space, system boundaries, and key relationships. These are working artifacts, not formal documentation.

What Works at This Stage

C4 Level 1 (Context Diagrams):

• Shows the system boundary and external dependencies
• Helps stakeholders understand what’s in scope vs. out of scope
• Clarifies which external systems, teams, or users are involved
• Useful when: Multiple systems interact, scope boundaries are unclear, or stakeholders have different assumptions about what’s included

Simple Box-and-Arrow Sketches:

• Whiteboard-level clarity for exploring ideas
• No formal notation required—focus on communication
• Easy to change as understanding evolves
• Useful when: Exploring concepts collaboratively, testing different mental models, or facilitating stakeholder discussions

Data Flow Diagrams:

• Shows how information moves through the system
• Identifies sources, destinations, and transformations
• Useful when: The problem centers on data movement, integration points are unclear, or compliance requires data flow documentation

When to Create Diagrams

Create diagrams when:

• Stakeholders have different mental models of the system boundary
• External dependencies or integrations are unclear
• Multiple teams or systems are involved and roles need clarification
• Compliance or governance requires visual documentation of scope
• Verbal descriptions create confusion or misalignment

Skip diagrams when:

• Everyone already shares the same mental model
• The system is simple enough to describe clearly in a few sentences
• You’re still discovering what the problem actually is (too early to diagram)
• Creating the diagram would take longer than the value it provides

The Project Charter

Purpose

Formalize understanding and secure commitment. The charter is the contract that authorizes the project to proceed.

Essential Components

1. Executive Summary (1-2 pages)

• Project name, sponsor, and key personnel
• High-level business problem and objectives
• Recommended approach
• Estimated timeline and budget
• Critical success factors

2. Scope Definition

In-Scope: Clear deliverables and capabilities Out-of-Scope (equally important): What you’re explicitly NOT doing

Example:

IN SCOPE:
- Customer portal with login and profile management
- Integration with existing CRM
- Mobile-responsive web design

OUT OF SCOPE:
- Mobile native apps (web only)
- International language support (future phase)
- Integration with legacy billing system (separate project)

3. Success Criteria (Measurable)

• Business metrics (revenue, cost savings, conversion rate)
• User metrics (adoption rate, satisfaction)
• Technical metrics (uptime, performance)
• Timeline metrics (launch date, milestones)

Example:

Success =
✓ Portal launched by Q3 2025
✓ 70% customer adoption within 3 months
✓ 99.9% uptime achieved
✓ Support calls reduced 30%
✓ Page load < 2 seconds (95th percentile)

4. Authority & Decision Rights

• What can you decide autonomously?
• What requires stakeholder approval?
• Escalation path for issues
• Budget authority and spending limits

5. Communication Plan

• Meeting schedules and cadence
• Status reporting approach
• Where artifacts will be stored
• How decisions will be documented

6. Risk Register (Top 5-10)

• Risk description, likelihood, impact
• Mitigation strategy and owner

7. Assumptions & Dependencies

• Key assumptions (and what invalidates them)
• Dependencies on other teams/systems
• Timeline impacts if dependencies delayed

Minimum vs. Maximum

Small Projects: 3-5 pages, simple scope, basic risks Large Projects: 15-20 pages, detailed scope, comprehensive risk register, governance structure

Getting Real Approval

Present the charter in person; don’t just email it. Walk through key sections together and ask stakeholders to explain the project back to you. Make the charter scannable with headings, bullets, and tables. Get formal written sign-off, not just verbal agreement.

Readiness: Transitioning to Agree

Artifacts can be completed without genuine alignment. Before moving to Phase 2 (Agree), verify that alignment is real, not just documented.

Test alignment with these questions:

• Can each stakeholder explain the project’s purpose and success criteria without referring to the charter?
• Do stakeholders describe the project consistently, or do they emphasize different goals?
• When you present a hypothetical trade-off (“What if we had to cut 20% of scope?”), do stakeholders agree on what to cut?
• Are stakeholders asking questions and engaging, or just signing off to move things along?

You’re ready for Agree when:

• Project charter is signed by all key stakeholders
• Stakeholders can explain the project in their own words
• Success criteria are measurable and agreed (not vague or conflicting)
• Constraints are documented and acknowledged
• Key risks are identified with owners and mitigation strategies
• Budget and resources have real commitment (not “we’ll figure it out”)
• Decision rights are clear (who decides what)
• No stakeholder is withholding concerns or planning to revisit decisions later

What Happens If You Proceed Too Early

Moving to Agree without genuine alignment creates problems that surface later: architecture decisions made against misunderstood requirements, design work thrown away when real requirements emerge, stakeholder conflicts mid-implementation, and scope creep as stakeholders add requirements they “thought were obvious.”