The Five Phases of a Project — Planning→Design→Production→Verification→Operation

This section demonstrates the specific problems caused by ambiguous phase boundaries.

In a website renewal project, the client requested "let's change the concept after all" during the production phase. Design mockups were already completed and coding was 50% done. The freelance designer, recognizing that agreement in the planning phase was insufficient, is considering providing free additional work to maintain the client relationship.

Such cases are not uncommon. When project phase boundaries are ambiguous, the following problems occur in a chain reaction:

Risks for Contractors

• Unexpected additional work severely reduces profit margins (hourly rates can drop by 50%)
• Schedule delays affect other projects
• Insufficient time to maintain quality creates reputation risks

Risks for Clients

• Budget overruns lead to additional costs (often 1.5-2 times the original budget)
• Release delays impact business plans
• Expected quality and functionality may not be achieved

In actual web development processes, when phase transition criteria are ambiguous, 35% of projects experience delays of one month or more from the original schedule. Additionally, 70% of projects incurring additional costs are due to insufficient agreement in the planning and design phases.

This problem stems from the inability to systematically manage the project workflow. Particularly, proceeding with unclear completion conditions and responsibility boundaries for each phase creates a structure where rework and additional adjustments frequently occur.

This section analyzes the structural causes behind the breakdown of phase management in project approaches.

The fundamental reason phase management fails lies in "perception gaps" and "ambiguous responsibility boundaries" between contractors and clients.

Structural Factors of Perception Gaps

In many projects, clients tend to focus on "outputs (deliverables)" while contractors focus on "processes (work procedures)." This difference in perspective makes phase management difficult.

For example, interpretations of "design phase completion" differ between parties:

• Client's perception: "Complete when screen images are visible"
• Contractor's perception: "Complete when technical specifications, functional requirements, and constraints are all confirmed"

This perception gap leads clients to expect production to start during design, while contractors feel at risk starting production with unconfirmed specifications. As a result, phase transition timing becomes ambiguous.

Institutional Background Creating Ambiguous Responsibility Boundaries

In Japanese outsourced development, there's a cultural background that values "customer orientation" and "flexible response." This results in the normalization of "responding within possible limits" even for requests not specified in contracts or specifications.

Specifically:

• Requirements that should be decided in the planning phase are postponed to the production phase
• Moving to the next phase with ambiguous agreements like "we'll adjust later" or "we'll decide as we go"
• Completion conditions for each phase are not documented, proceeding on verbal agreements

This structure causes problems that should be resolved in previous phases to carry over to subsequent phases, ultimately making phase boundaries ambiguous.

Impact of Increasing Technical Complexity

In recent web development and system development, technical options have increased dramatically. Responsive design, CMS selection, API integration, security requirements, and many other considerations are involved.

This technical complexity causes:

• Difficulty in confirming all requirements at the planning stage
• Need for planning and design revisions when technical constraints become apparent during production
• Increased cross-phase decision-making, making management difficult

Given this background, traditional "unidirectional phase progression" becomes inadequate, and phase management itself tends to become formalistic.

This section explains specific management methods and judgment criteria for each phase: planning, design, production, verification, and operation.

Effective project phase management requires "documented completion conditions" and "clear responsibility boundaries" at each stage. Below are the practical operation methods for the 5 phases.

Phase 1: Planning—Confirming Goals and Constraints

The core of the planning phase is clarifying "what it's for" rather than "what to create."

Completion conditions:

• Quantification of business goals and KPI indicators (e.g., 20% increase in inquiries, CVR improvement)
• Budget and schedule confirmation (setting unchangeable baselines)
• Concrete target and persona definition (based on actual customer data)
• Technical constraints and requirements identification (existing system integration, security requirements)

Contractor's responsibility: Feasibility verification from professional perspective, presenting technical constraints, calculating rough estimates Client's responsibility: Determining business requirements, budget, schedule, internal coordination and approval

Judgment criteria: All four items above are documented and signed/approved by both parties.

Phase 2: Design—Confirming Specific Specifications and Structure

In the design phase, specific means to achieve the goals set in planning are confirmed.

Completion conditions:

• Sitemap and feature list confirmation (specifying page count and detailed features)
• Wireframe and screen transition diagram approval (covering all major screens)
• Technical specification confirmation (technologies used, server requirements, CMS specifications)
• Design concept and direction approval (tone & manner, reference sites)

Contractor's responsibility: Technical specification details, wireframe creation, implementation policy decisions Client's responsibility: Detailed functional requirements specification, UI/UX direction decisions, material and content preparation policy confirmation

Judgment criteria: All specifications necessary for production are confirmed, with no additional specification consideration needed.

Phase 3: Production—Implementation Based on Design

In the production phase, implementation is carried out based on specifications confirmed in design. Specification changes are not accepted in principle during this phase.

Completion conditions:

• Design mockup completion and approval (all pages, all device support)
• Coding and system implementation completion (100% compliance with design specifications)
• Material and content implementation completion (text and image production reflection)
• Internal testing completion (functional operation and display verification)

Contractor's responsibility: Implementation based on design specifications, quality management, internal testing Client's responsibility: Material and content provision, interim confirmation and feedback

Judgment criteria: Zero variance from design specifications and clearing internal quality standards.

Phase 4: Verification—Quality Confirmation and Final Adjustments

In the verification phase, it's confirmed whether the implemented deliverables meet the original goals.

Completion conditions:

• Comprehensive testing completion (functionality, performance, security, usability)
• Final client confirmation and approval
• Production environment operation confirmation
• Operation transition preparation completion (manuals, permission settings)

Contractor's responsibility: Comprehensive testing implementation, bug fixes, production environment construction Client's responsibility: Final confirmation and approval, operation system preparation

Judgment criteria: Meeting goals and requirements set in the planning phase, ready for production operation.

Phase 5: Operation—Continuous Improvement and Maintenance

In the operation phase, continuous improvement and maintenance of the site/system are performed.

Completion conditions: No completion in principle (continuous phase)

• Regular effectiveness measurement and report submission
• Maintenance and security update implementation
• Improvement proposals and next development plan formulation

Contractor's responsibility: Technical maintenance, effectiveness measurement support, improvement proposals Client's responsibility: Operation policy decisions, content updates, effectiveness measurement and analysis

This section shows risks during phase transitions that practitioners tend to overlook and specific countermeasures.

Phase transition failures have significant impacts on overall project quality, cost, and schedule. Below are common failure patterns and their countermeasures.

Failure Pattern 1: Proceeding with "Tentative Decisions"

Many cases involve moving to the next phase with the judgment of "proceed for now and adjust later."

Examples:

• Starting design with ambiguous budget of "around 3-5 million yen"
• Starting production with design direction agreement of just "modern feel"
• Starting coding with functional specifications "details to follow"

Countermeasures:

• Completion condition checklist operation: Pre-list minimum items to be confirmed in each phase
• Deadline setting for tentative decisions: Specify "final decision by [date], additional costs apply thereafter"
• Pre-explanation of impact scope: Present numerical cost and schedule impacts of later changes

Failure Pattern 2: Insufficient Stakeholder Agreement

Cases where project managers have approved but actual users or higher decision-makers are not involved.

Examples:

• Agreement at staff level but major change requests at executive review
• System user department opinions not reflected, usability problems discovered during operation
• Legal/security department reviews postponed, specification changes required after production completion

Countermeasures:

• Stakeholder mapping creation: Pre-identify all people/departments involved in decision-making
• Staged approval process design: Clarify required approvers and approval levels for each phase
• Approval record documentation: Record who approved what and when

Failure Pattern 3: Postponing Technical Verification

Optimistic judgment that "technical problems will be solved during production" leads to discovery of major constraints during implementation.

Examples:

• Integration with existing systems more difficult than expected, requiring major specification changes
• Fundamental design review needed to meet performance requirements
• Planned features unimplementable due to external service API limitations

Countermeasures:

• Technical PoC (Proof of Concept) implementation: Verify high-risk technical elements during design phase
• Early identification of technical constraints: Thorough technical research during planning and design phases
• Alternative plan preparation: Prepare multiple alternatives for major technical risks

Failure Pattern 4: Ambiguous Quality Standards

Endless modifications and adjustments continue due to ambiguous "completion" judgment criteria.

Examples:

• Unlimited design modifications with standard of "until it looks good"
• Frequent feature addition requests for "usability improvement"
• Continued release delays for "perfection"

Countermeasures:

• Quantitative quality standards setting: Numerical standards like page load speed and error rates
• Modification limit setting: Pre-agree on number of modifications per phase
• Completion judgment meeting establishment: Set up meeting body to formally determine phase completion

Failure Pattern 5: Inconsistent Communication Methods

Information scattered across email, chat, phone, meetings, causing important decisions to be buried.

Countermeasures:

• Information management tool unification: Select tools for centralized project information management
• Decision documentation rules: Always document verbal agreements
• Regular reporting systematization: Institutionalize weekly/monthly progress and issue sharing

This section shows specific action items readers can use from their next project.

Effective phase management introduction requires a gradual approach. Below are implementation steps for immediate practical use.

Step 1: Current Project Approach Inventory (Time required: 2 hours)

First, objectively view the current state of projects you're involved in.

Implementation content:

• Review of past 3 projects (identifying problem occurrence points)
• Inventory of currently used project management tools and documents
• Current stakeholder and approval flow understanding

Checkpoints:

• Which phase experiences the most troubles?
• Where are information sharing and decision-making bottlenecks?
• What elements are missing in current contract/agreement formats?

Step 2: Phase Management Template Creation (Time required: 4 hours)

Create management templates based on the 5 phases.

Documents to create:

1. Phase completion checklist: Itemize completion conditions for each phase
2. Responsibility boundary table (RACI table): Specify contractor and client responsibility boundaries
3. Phase transition judgment sheet: Judgment criteria for moving to next phase
4. Stakeholder management table: List stakeholders, approval authority, contact information

Template utilization points:

• Customize according to your industry and project scale
• Create with the premise of sharing with clients for mutual use
• Improve templates after each project completion

Step 3: Trial Operation with Small Projects (1 project)

Test the created templates in actual projects.

Key items during trial:

• Always conduct judgment meetings during phase transitions
• Complete 100% of completion condition checklists
• Record response processes when problems occur

Effectiveness measurement indicators:

• Number of rework occurrences due to phase transitions
• Days delayed from original schedule
• Presence/absence and amount of additional costs

Step 4: Agreement Formation with Clients (Continuous operation)

Once you experience the effectiveness of phase management, form formal agreements with clients.

Content to agree on:

• Adoption of phase management methods (specify in contracts/memorandums)
• Authority and procedures for phase transition judgment
• Conditions and calculation methods for additional costs
• Communication rules and reporting frequency

Points when proposing:

• Explain "quality improvement" and "risk reduction" benefits numerically
• Present specific past problem cases and improvement effects
• Propose gradual introduction (starting with simplified version)

Immediate Actions for Contractors

1. Contract template review: Specify deliverables and completion conditions by phase
2. Estimate structure change: Present phase-separated work hours and costs
3. Project management tool introduction: Visualize phase progress with project management tools

Immediate Actions for Clients

1. Internal approval flow organization: Document approvers and procedures needed for phase transitions
2. Budget management improvement: Set phase-based budget allocation and additional cost approval rules
3. Quality standard setting: Pre-set quantitative completion judgment criteria

Systematization for Continuous Improvement

• Monthly review meetings: Measure phase management effectiveness and extract improvement points
• Case sharing: Share success and failure cases within teams and organizations
• External training and information gathering: Continuous learning of project management methods

Phase management is not complete once introduced but requires continuous improvement. Start with small projects and gradually improve management levels to achieve high-quality project operation with reduced risks for both contractors and clients.

The key is not pursuing perfection but gradually building "better than current state." From your next project, introduce phase management within possible limits and experience its effectiveness.