lesson 4.5 - waterfall project methodology
Don't go chasing waterfalls... unless you're planning a digital project! Dive into the step-by-step logic of the Waterfall methodology for BTEC DIT.
Imagine trying to build a house by putting the roof on before you've built the walls. Sounds like a total disaster, right? In digital project management, the Waterfall methodology is the ultimate "one step at a time" approach. Once you finish a phase, you lock it in and flow downwards to the next one - no swimming upstream! Today, we are going to explore how this strict, structured method keeps massive tech projects from turning into absolute chaos.
Learning Outcomes
The Building Blocks (Factual Knowledge)
The Connections and Theories (Conceptual Knowledge)
The Skills and Methods (Procedural Knowledge)
Recall the distinct phases of the Waterfall project methodology.
Describe the linear and sequential nature of the Waterfall approach.
The Connections and Theories (Conceptual Knowledge)
Analyse the advantages and disadvantages of using the Waterfall methodology for digital projects.
Evaluate the importance of comprehensive documentation at each stage of the Waterfall lifecycle.
The Skills and Methods (Procedural Knowledge)
Apply the Waterfall methodology phases to a given project scenario.
Create a phased project plan mapping specific tasks to their appropriate Waterfall stage.
Digital Skill Focus: Applying Project Management Methodologies
Welcome to the world of project methodologies! When managing a digital project, you need a solid framework to keep everything on track. The Waterfall methodology is one of the most traditional and structured ways to manage a build. It is a linear and sequential approach. This means you move downwards through the project step-by-step, much like water falling over a cliff edge.
In a strict Waterfall project, you must completely finish one phase (and get it signed off by the client) before you can start the next one. There is no swimming upstream!
1
Requirements: Gathering exactly what the client wants and defining the project scope.
2
Design: Creating the visual identity, mood boards, and detailed interface wireframes.
3
Implementation: The actual coding and development of the digital product.
4
Testing: Checking for bugs and ensuring the product meets all initial requirements.
5
Deployment: Launching the finished interface to the target audience.
6
Maintenance: Providing ongoing support and fixing any future issues.
Why use it?
Waterfall is excellent for projects with fixed budgets and crystal-clear milestones. Because of the heavy documentation required at each stage, everyone knows exactly what they are doing and what the final product should look like from day one.
Waterfall is excellent for projects with fixed budgets and crystal-clear milestones. Because of the heavy documentation required at each stage, everyone knows exactly what they are doing and what the final product should look like from day one.
Why avoid it?
It is highly inflexible. If the client decides they want a major new feature during the Testing phase, going back to the Design phase is incredibly expensive and causes massive delays. It is not built for changing minds!
It is highly inflexible. If the client decides they want a major new feature during the Testing phase, going back to the Design phase is incredibly expensive and causes massive delays. It is not built for changing minds!
Task The Waterfall Wizard
It is time to put things in order and visualise the flow! A confused project manager has dropped their task list, and all the jobs for a new mobile app have been mixed up. You need to use diagrams.net to build a strict Waterfall methodology diagram and sort them out before the project fails and you get the sack.
1
Research & Setup
Before you build anything, let's use Google Image search to see what a professional diagram looks like by searching for Waterfall method diagrams.
Once you have the standard layout fixed in your mind, head over to app.diagrams.net.
As always, organise your workspace.
2
Build the Flow
1
Create six distinct boxes or sections for the official phases of the Waterfall model.
2
Connect them with arrows pointing downwards to show the strict linear flow.
3
Read the following tasks and place each one inside the correct phase on your diagram:
Fix a bug found by a user one month after launch
Draw a wireframe for the home screen
Ask the client what features they want
Write the Python code for the login system
Run a script to check for security flaws before release
Upload the finished app to the Google Play Store
3
The Inflexibility Problem
Imagine you are in the "Testing" phase. The client emails you and says...
"Actually, I want the app to be a game instead of a booking system."
Good grief. Add a text box to the side of your diagram with a short paragraph explaining why this is a massive problem in the Waterfall methodology and what you would have to do to fix it.
If you are struggling to understand why changing things late is so hard, try asking your AI assistant for help:
Act as a supportive, expert computer science tutor. Explain why the Waterfall project management methodology is considered inflexible when a client wants to make major changes during the testing phase. Limit your response to 100 words. Explain this so a 14-to-16-year-old Key Stage 4 student can easily understand. Keep the tone encouraging and clear, avoiding overly academic jargon. Use exactly 2 short paragraphs. Include 1 real-world analogy. Do not write the assignment answer for me. NO intro, NO outro, NO deviation from the topic, NO follow-up questions.
4
Export your Work
Once your diagram is perfectly sequenced and your evaluation text box is added, go to File > Export As > PDF. Save the file with a sensible name ready to submit it to your teacher!
Outcome: A digital PDF diagram created in diagrams.net demonstrating the linear flow of the Waterfall methodology, with correctly sequenced tasks and a written evaluation of its inflexibility.
Application to the Component Sample PSA
Understanding the Waterfall methodology is incredibly useful when tackling your Component Pearson Set Assignments (PSAs), as it provides a rigid framework for planning your approach.
For the Component 1: Majestic Cinema brief, you are tasked with designing a user interface for a booking system. Applying a Waterfall approach means you would spend a significant amount of time in the Requirements phase, fully defining the needs of different audience types (like older users needing clear text). You would then complete and lock in your Design phase (mood boards and wireframes) before you even think about the Implementation phase (building the interactive prototype). This strict sequence ensures you do not waste time building a prototype that doesn't meet the brief.
For the Component 2: Pedal Power Cycles brief, you must build a data dashboard. A Waterfall approach would dictate that you completely finalise what data needs to be shown and how it should look (Design) before you open your spreadsheet software to manipulate the raw data (Implementation). Because Waterfall relies heavily on documentation, you would have a clear plan to refer back to when you reach the Testing phase, making it easier to check if your dashboard meets all of Pedal Power's initial goals.
Out of Lesson Learning
⭐ The Majestic Milestones
For the Majestic Cinema user interface project, a project manager using the Waterfall method needs clear milestones to sign off before moving to the next stage. Write down three distinct, logical milestones for the Majestic Cinema project (for example, "Audience Requirements Approved"). For each milestone, write one sentence explaining exactly what must be completed before the project is allowed to flow down to the next phase.
For the Majestic Cinema user interface project, a project manager using the Waterfall method needs clear milestones to sign off before moving to the next stage. Write down three distinct, logical milestones for the Majestic Cinema project (for example, "Audience Requirements Approved"). For each milestone, write one sentence explaining exactly what must be completed before the project is allowed to flow down to the next phase.
⭐⭐ Pedal Power: The Price of Change
Imagine you are currently in the "Implementation" phase of the Pedal Power Cycles dashboard project. You are actively building the spreadsheet and creating the charts. The shop owner emails you to say: "I've changed my mind! Instead of a dashboard showing sales, I want an interactive map showing where my customers live." Write a short, professional email replying to the shop owner. You must explain why this request is a massive problem when using the strict Waterfall methodology, and outline exactly which previous phases would need to be completely redone to accommodate this change.
Imagine you are currently in the "Implementation" phase of the Pedal Power Cycles dashboard project. You are actively building the spreadsheet and creating the charts. The shop owner emails you to say: "I've changed my mind! Instead of a dashboard showing sales, I want an interactive map showing where my customers live." Write a short, professional email replying to the shop owner. You must explain why this request is a massive problem when using the strict Waterfall methodology, and outline exactly which previous phases would need to be completely redone to accommodate this change.
⭐⭐⭐ The Methodology Match-Up
The Waterfall methodology is just one way to manage a project, and it is known for being highly inflexible. Think about the Majestic Cinema booking system. Write a short evaluative paragraph (around 100 words) arguing whether you think a strict, rigid Waterfall approach is the *best* way to build this specific interface, or whether a more flexible approach that allows for changes during the build process would be better. Justify your argument using examples from the cinema scenario.
The Waterfall methodology is just one way to manage a project, and it is known for being highly inflexible. Think about the Majestic Cinema booking system. Write a short evaluative paragraph (around 100 words) arguing whether you think a strict, rigid Waterfall approach is the *best* way to build this specific interface, or whether a more flexible approach that allows for changes during the build process would be better. Justify your argument using examples from the cinema scenario.
Last modified: March 18th, 2026
