Project: Pick a Methodology & Plan Phases

Project: Pick a Methodology & Plan Phases

Throughout this tutorial you have studied the full landscape of development methodologies — from the linear rigour of Waterfall to the adaptive cadence of Scrum, the flow-based discipline of Kanban, and the pragmatic blends of hybrid approaches. Now comes the hardest skill of all: applying the right methodology to a real project, justifying that choice with evidence, and mapping out concrete phases from day one.

This lesson walks through three realistic business scenarios. For each one you will see how an analyst reads the project's signals, selects a methodology, documents the justification, and produces an initial phase plan. Treat this as a template you can replicate on your own projects.

The Decision Framework: Five Signals

Before choosing a methodology, gather answers to five diagnostic questions. The pattern of answers tells you which approach fits best.

The signals map to methodology tendencies like this:

• Waterfall scores well when: requirements are fixed and complete, stakeholder availability is limited, risk tolerance is very low, and a single integrated delivery is acceptable.
• Scrum / Agile scores well when: requirements will evolve, stakeholders can attend regular reviews, the team is experienced with self-organisation, and early partial delivery creates value.
• Kanban scores well when: work arrives as a continuous stream rather than discrete projects, cycle time matters more than sprint commitments, and the team is small and mature.
• Hybrid scores well when: the project has a stable core (Waterfall) and an evolving digital layer (Agile), or when regulatory compliance demands formal sign-off at milestones.

Scenario A — Clinic Appointment Booking System

Context: A private medical clinic with 12 GPs and 3 reception staff wants to replace paper appointment books with a digital booking system. The clinic owner has already agreed the budget ($52,000), the go-live deadline is in 7 months (before a planned expansion), and the main requirements are well understood: online booking, SMS reminders, and integration with the existing billing software. The billing system vendor has confirmed a documented REST API. The IT team is two developers with solid experience but no Agile practice. The clinic owner can attend a monthly progress meeting but not more.

Signal analysis:

• Requirements clarity: High — core features are agreed and stable; billing API contract is documented.
• Stakeholder availability: Low — one monthly meeting only.
• Risk tolerance: Low — a booking system touching patient data in a regulated environment; errors cost patient safety and legal liability.
• Team size and maturity: Small (2 devs), no Agile experience.
• Delivery speed: Single go-live — partial delivery offers no value (clinic cannot run two booking systems in parallel).

Recommended methodology: Waterfall with a UAT gate.

Justification: All five signals point toward a structured, phase-gated approach. The requirements are fixed and documented, so there is no analytical reason to pay the overhead of sprint ceremonies. Stakeholder availability only allows monthly check-ins, which align naturally with phase-end reviews rather than two-week sprint demos. The regulatory context demands formal sign-off at each phase before proceeding. A single integrated delivery is the only viable mode.

The one Waterfall risk — late defect discovery — is mitigated by adding a formal UAT phase (4 weeks) with real clinic staff before go-live, using scripted test scenarios derived from the requirements specification.

Phase plan (7 months):

• Month 1 — Planning & Analysis: Stakeholder interviews, requirements specification (functional + non-functional), gap analysis of billing API, risk register. Deliverable: signed-off Requirements Document.
• Month 2 — Design: Database schema, API contracts, UI wireframes, security design (patient data encryption, access control). Deliverable: Design Specification document.
• Months 3–5 — Implementation: Development in three internal iterations (booking engine → SMS gateway → billing integration), weekly internal code reviews, unit + integration tests. Deliverable: test-ready system.
• Month 6 — UAT: 4-week scripted UAT with 2 reception staff and 1 GP. Bug triage and fixes. Deliverable: UAT sign-off report.
• Month 7 — Deployment & Handover: Production deployment, data migration from paper records, staff training, go-live monitoring. Deliverable: live system + training manual.

Scenario B — E-Commerce Platform for a Fashion Startup

Context: A fashion startup with $180,000 in seed funding wants to launch an online store. The founders have strong opinions about the look and feel, but these opinions change weekly as they test ideas with early customers. The product roadmap is a living document — new features (wishlists, influencer referral codes, AR try-on) may be added or cut depending on market response. The team is 4 developers and a product designer, all experienced with Agile. The founders can participate in weekly demos.

Signal analysis:

• Requirements clarity: Low — features and UI direction change as market feedback arrives.
• Stakeholder availability: High — founders available for weekly reviews.
• Risk tolerance: High — a startup; pivoting is expected, not a failure.
• Team size and maturity: Medium (5 people), Agile-experienced.
• Delivery speed: Incremental value — founders want a working checkout live in 6 weeks, then iterate.

Recommended methodology: Scrum with 2-week sprints.

Justification: The defining characteristic here is volatile requirements combined with high stakeholder availability and an experienced team — exactly the conditions Scrum was designed for. Delivering a minimal working checkout in Sprint 3 gives the founders real market data that will sharpen later requirements. The cost of a sprint ceremony (planning, daily standup, review, retrospective) is entirely justified by the requirement churn it prevents. Waterfall would lock in assumptions that will certainly be wrong by month 4.

Phase plan (first 12 weeks):

• Sprint 0 (1 week) — Setup: Product backlog creation, architecture decision records, CI/CD pipeline, dev/staging environments. Goal: team is unblocked.
• Sprints 1–2 — Core Checkout: Product catalogue, cart, checkout flow, Stripe payment integration, order confirmation email. Goal: a real order can be placed.
• Sprints 3–4 — Customer Accounts: Registration, order history, address book, password reset. Goal: returning customers can log in.
• Sprints 5–6 — Discovery: Search, filtering by size/colour/price, category pages. Goal: customers can find products without knowing the name.
• Ongoing: Each sprint review with founders reprioritises the backlog. AR try-on gets scheduled when technical feasibility is confirmed; referral codes move up if a pilot campaign is planned.

Scenario C — Logistics Fleet Management System

Context: A regional logistics firm with 200 trucks wants to replace three disconnected legacy systems (route planning in spreadsheets, driver scheduling in a 12-year-old Access database, fuel tracking in a paper logbook) with a unified fleet management platform. The firm is ISO 9001 certified — every system change requires documented approval at defined milestones. The project budget is $320,000 over 18 months. Requirements for regulatory compliance features are fixed and non-negotiable; requirements for the driver mobile app are exploratory and will be validated with drivers during development. The internal IT team has 3 developers (Waterfall background) and the firm plans to hire 2 more contractors familiar with mobile development.

Signal analysis:

• Requirements clarity: Mixed — compliance/route core is fixed; driver app is exploratory.
• Stakeholder availability: Medium — operations managers can do monthly milestone reviews; drivers available for fortnightly app pilots.
• Risk tolerance: Low for compliance features, Medium for app.
• Team size and maturity: Mixed — internal team is Waterfall-trained; contractors are Agile-native.
• Delivery speed: Phased — route planning replacement must go live before fuel tracking; the app can launch later.

Recommended methodology: Hybrid — Waterfall backbone for compliance core, Scrum for driver app.

Justification: The ISO 9001 context mandates formal sign-off at defined milestones — non-negotiable. The compliance and routing core has documented, stable requirements, making Waterfall the natural fit. However, treating the driver mobile app the same way would produce a product that does not match driver workflows, because those workflows are not yet fully understood. Running a Scrum track in parallel (2-week sprints, fortnightly driver demos) generates validated learning while the core system is being built. The two tracks merge at integration testing in month 15.

Phase plan (18 months, two parallel tracks):

• Months 1–2 — Master Planning: Requirements specification for core system, Scrum backlog creation for driver app, architecture design for shared data model. Milestone: Steering Committee sign-off on scope and budget allocation.
• Months 3–6 — Core Design & Dev (Waterfall track): Database design, route planning engine, scheduler module. Milestone: Design sign-off before coding begins.
• Months 3–12 — Driver App (Scrum track): 2-week sprints; fortnightly demo with 5 pilot drivers. Backlog includes: manifest view, proof-of-delivery photo, fuel logging, navigation integration.
• Months 7–14 — Core Implementation continues: Fuel tracking module, reporting dashboards, legacy data migration scripts.
• Months 15–16 — Integration & System Testing: App and core connect via internal API; end-to-end test scenarios covering 20 documented compliance rules.
• Month 17 — UAT & Pilot: 20-truck pilot with real routes. ISO 9001 UAT sign-off protocol.
• Month 18 — Full Rollout: Phased fleet-wide deployment, legacy system decommission, training programme.

Writing Your Methodology Justification Document

When you present a methodology recommendation to a sponsor or steering committee, the document should contain exactly four sections:

1. Project Characteristics Summary — one paragraph describing the five signals and their values for this project.
2. Methodology Selection — the chosen approach, in one sentence. No hedging. "This project will use Scrum with 2-week sprints."
3. Justification — three to five bullet points explaining why the chosen methodology fits better than the alternatives. Name the alternatives you rejected and explain why they were rejected.
4. Phase Plan — a milestone table with phase names, dates, key activities, and deliverables. Concrete enough that a new team member could pick it up and know what week 3 looks like.

Putting It Into Practice

Before you finish this tutorial, take 30 minutes to apply the framework to a project you know — one you are currently working on, have worked on in the past, or can imagine clearly. Write down your signal values, state your methodology choice, and draft a five-row phase plan. The act of writing it down forces clarity that verbal agreement never does.

This is the skill that distinguishes a junior analyst who can document requirements from a senior analyst who can steer a project from the start. Methodology selection is not a bureaucratic formality — it is the foundational decision that determines whether a project's structure fights the project's nature or flows with it.