How do IT project managers decide whether to plan every detail upfront or figure things out as they go — and what stops projects from spinning out of control? That's the problem that project methodologies and constraints solve. For the PK0-005 exam, you need to know the major ways IT projects are run (methodologies) and the unavoidable limits (constraints) that every project faces, so you can recognise which approach fits a given scenario and what trade-offs the project manager must make.
Jump to a section
A simple way to picture IT Project Methodologies and Constraints
Standing in a dusty, empty living room with a sledgehammer in hand. You have two ways to approach a full house renovation. The Waterfall way is to plan everything upfront: you agree on the exact floorplan, pick every tile and paint colour, get a fixed price and timeline, then swing the hammer. You demolish, rewire, plaster, paint, and install — each phase finished completely before the next starts. If you discover the sofa won't fit the new layout, that's a disaster because you already signed off the design. The Agile way is to start with a rough vision, rip out a single wall, build a small section of open-plan kitchen, live with it for a week, then decide whether to knock down the next wall or change the window size. Every two weeks you stop and show the current state to friends, gather their feedback, and adjust the plan. Waterfall gives predictability on day one but punishes change; Agile welcomes change but makes the final cost and date uncertain. Project constraints are the three immovable items in your contract: the firm budget, the immovable moving-in date, and the required room count. You can trade off one against another — cheaper materials might let you add a fourth bedroom — but you cannot fix all three and also demand extra rooms halfway through. That's the triple constraint: scope, cost, and time cannot all be locked down together.
This chapter explains two big ideas that appear constantly on the PK0-005 exam: project methodologies and project constraints.
Let's start with project methodologies. A project methodology is a structured approach to completing a project — think of it as a recipe book for how you plan, execute, and deliver the work. In IT, the two most common methodologies are Waterfall and Agile.
Waterfall is the traditional method. It is called Waterfall because work flows downward in a series of phases, like water going down a staircase. You do Phase 1 (requirements gathering) completely, then Phase 2 (design), then Phase 3 (build), then Phase 4 (testing), then Phase 5 (deployment), and finally Phase 6 (maintenance). You cannot go back to an earlier phase without a formal process. This works well when you know exactly what the customer wants from the start and the requirements are unlikely to change. The exam likes to test Waterfall on projects with fixed scope and regulatory requirements.
Agile is a modern, flexible methodology. Instead of a fixed plan, you work in short cycles called iterations or sprints — typically two to four weeks long. Each sprint produces a working piece of the final product. After each sprint, you review it with stakeholders and adjust the plan for the next sprint based on feedback. The key principles are in the Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Within Agile there are specific frameworks like Scrum (with roles like Product Owner, Scrum Master, and Development Team, and events like daily stand-ups and sprint reviews) and Kanban (which focuses on visualising work on a board and limiting work-in-progress). The exam tests Agile for projects where requirements are unclear or likely to change.
There are also hybrid approaches that mix Waterfall and Agile — for example, planning the overall timeline with Waterfall but building features in agile sprints.
Now, project constraints. Constraints are limits you cannot fully control. The classic model is the Triple Constraint: scope, time, and cost. If you change one, at least one of the others must change. For instance, if the client demands extra features (increased scope) without extending the deadline (time) or increasing the budget (cost), the project manager must push back because quality will suffer. The exam sometimes adds quality as a fourth constraint — so you see the Iron Triangle of scope, time, cost, and quality. Another constraint is risk: the potential for something to go wrong. If you have tight time or cost, risk goes up.
The exam wants you to understand that no methodology is perfect for every situation. The project manager selects a methodology based on factors like how well the requirements are understood, how much flexibility the customer needs, how large the team is, and whether the project must comply with strict regulations (Waterfall is common in regulated industries).
Constraints are managed through trade-offs. A project manager might reduce scope to hit a deadline, or increase cost to add more developers and finish faster. The key exam skill is identifying which constraint is being traded for which in a scenario.
Finally, the exam tests your ability to recognise when a project is in trouble because constraints are not balanced. For example, if a project is over schedule, the correct response might be to ask for more time, reduce scope, or add resources (which costs money). The answer you choose must address the specific constraint mentioned in the question.
Identify the project environment and requirements clarity
Before choosing a methodology, the project manager assesses how well the requirements are understood. If the customer can define everything upfront and change is unlikely, Waterfall is appropriate. If requirements are fuzzy or expected to evolve, Agile is the better fit. This step determines the entire project structure.
Select and tailor the methodology
Based on the assessment, the PM picks Waterfall, Agile (Scrum or Kanban), or a hybrid. They then tailor it — for example, deciding on sprint length (2 weeks vs 4 weeks) or choosing which documentation templates to use. The methodology guides how the team will plan, execute, and review work.
Define the project constraints and baseline them
The PM documents the approved scope, budget, and schedule as the baseline. These are the starting points against which all changes will be measured. The constraints are formally approved by the sponsor. Without a baseline, you cannot measure if scope is creeping or if you are over budget.
Monitor constraints continuously and identify trade-off opportunities
Throughout the project, the PM tracks actual performance against the baseline — earned value metrics, budget velocity, schedule performance. When a variance occurs (e.g., scope increase request), the PM evaluates which constraint to trade: extend time, add cost, or reduce scope. This step keeps the project balanced.
Escalate and implement trade-off decisions
The PM documents the trade-off recommendation and presents it to the project sponsor or change control board (a group that approves changes). Once approved, the PM updates the baseline, re-communicates the plan, and adjusts the team's work. This closes the loop and keeps the project on track.
Imagine you are a junior project manager at a small insurance company called ShieldSure. The company has hired you to lead a project that builds a customer portal where policyholders can file claims online, track them, and upload photos. You have a team of five developers, one tester, and a budget of £150,000. The deadline is six months from now.
Step 1: Choose a methodology. The executives want a fixed-price contract with a clear delivery date — they love predictability. Your team, however, has never built a customer-facing portal before and you are unsure exactly what users will want. After discussion, you choose a hybrid approach: you will use Waterfall for the overall high-level plan (design approval, legal compliance, infrastructure setup) but Agile for the actual feature development. You break the six months into four two-week sprints in the first two months, followed by a longer integration and testing phase.
Step 2: Define the constraints. You identify scope (the features described in the requirements document), time (the six-month deadline), and cost (the £150,000 budget). You also note a fourth constraint: quality (the portal must pass security audits and be easy to use).
Step 3: Manage trade-offs. After three sprints, the team discovers that users want a "chat with an agent" feature that was not in the original scope. Adding it would take two extra weeks (time) or require hiring another developer (cost). You ask the project sponsor: they agree to extend the deadline by two weeks rather than increase the budget. So you trade time for scope increase.
Step 4: Monitor constraints. Every week you track actual spend vs budget, completed features vs planned scope, and the sprint burndown chart — a graph showing remaining work. Halfway through, you see the team is burning through budget faster than planned because a third-party integration turned out to be more expensive. You escalate to the steering committee and get approval to reduce scope by dropping a non-essential reporting feature to stay within budget.
What you actually do each day:
Hold a daily stand-up meeting (15 minutes) where each team member says what they did yesterday, what they will do today, and any blockers.
Update the Kanban board (a visual tool with columns like To Do, In Progress, Done) so everyone sees the current status.
Run the sprint planning session at the start of each sprint to commit to specific tasks.
Conduct a sprint review at the end of each sprint to demo working software to stakeholders and collect feedback.
Maintain a risk register — a spreadsheet listing potential issues like "developer might leave" or "API vendor could raise prices" — with a probability and impact score and a mitigation plan for each.
At the end of the project, you do a lessons-learned session where the team discusses what went well and what could improve. The portal goes live on time and within budget because you actively managed the triple constraint, choosing which trade-off to make at each decision point.
The PK0-005 exam tests three big areas in this chapter: methodology selection, constraint identification, and trade-off analysis. Here is exactly what you need to memorise and the traps they set.
Methodology identification questions are the most common. The exam will give you a scenario and ask which methodology is best. They love to test the following patterns:
A project with completely defined requirements and a fixed price -> Waterfall
A project where requirements are unclear and likely to change -> Agile
A project in a highly regulated industry (healthcare, finance) -> Waterfall (documentation-heavy)
A project with a small, co-located team that can adapt quickly -> Agile (often Scrum)
A project that needs rapid delivery of a minimum viable product -> Agile (Kanban or Scrum)
Trap: They will sometimes describe a project that could use either approach but includes a detail like "the customer wants to see progress every two weeks". That is Agile. Or "the contract requires a fixed specification sign-off before coding begins". That is Waterfall. The key is to look for the specific trigger phrase.
Constraint questions often give you a scenario where something changes and ask you to identify which constraint is most affected. For instance: - "The client asks for three new features without changing the deadline or budget." -> Scope increases, time and cost stay fixed -> quality suffers or the project fails. - "The budget is cut by 20% but the deadline stays the same." -> Scope must decrease or quality must drop. - "The deadline is moved forward by two weeks." -> You either reduce scope, increase cost (add people), or accept lower quality.
Trap: They will sometimes list four constraints and ask you to pick the one that is NOT part of the triple constraint. The triple constraint is scope, time, cost. Quality and risk are often added but are not part of the classic triple. The exam expects you to know the classic model as well as the extended model.
Trade-off analysis questions require you to decide what action the project manager should take. Common answer options:
Request additional resources (cost)
Extend the schedule (time)
Reduce scope (scope)
Accept lower quality (quality)
Escalate to the sponsor
The correct answer is almost always the one that acknowledges the constraint that can be changed without violating the primary constraints already set. For example, if the budget is fixed and the deadline is flexible, the answer is "extend the timeline" not "ask for more money".
Key definitions to memorise: - Waterfall: sequential phases, no going back, comprehensive documentation, fixed scope. - Agile: iterative, incremental, flexible, customer feedback driven. - Scrum: specific Agile framework with roles, ceremonies, and timeboxes. - Kanban: visual workflow board, limit work-in-progress, continuous delivery. - Triple constraint: scope, time, cost. - Iron Triangle: scope, time, cost, quality. - Risk: uncertain event that could affect the project. - Trade-off: exchanging one constraint for another.
Trap patterns: - They might describe a hybrid methodology and ask you to define it — know that hybrid is a mix of Waterfall and Agile. - They might ask which methodology emphasises "individuals and interactions" — that is Agile, from the Agile Manifesto. - They might ask about the role of the Product Owner in Scrum — they prioritise the backlog, which is the list of features to build. - They might ask about a sprint review vs a sprint retrospective — the review is about the product, the retrospective is about the team's process.
How to study: Practice identifying methodology from a two-sentence scenario. Write flash cards with the trigger phrases. For constraints, memorise the classic triple and understand that if you change one, you must adjust at least one other. The exam will never ask you to define the Agile Manifesto in detail, but they will expect you to know its value preferences.
Waterfall is best when requirements are fully known and unlikely to change; Agile is best when requirements are evolving or unclear.
The triple constraint of scope, time, and cost means changing one forces at least one other to change.
Quality is sometimes added as a fourth constraint in the Iron Triangle model.
Scrum uses specific ceremonies: sprint planning, daily stand-up, sprint review, and sprint retrospective.
Kanban focuses on visualising work and limiting work-in-progress to improve flow.
Trade-offs are the project manager's main tool for managing constraints — you adjust scope, time, or cost to keep the project viable.
These come up on the exam all the time. Here's how to tell them apart.
Waterfall
Sequential phases — each phase completes before the next starts
Requirements are fully defined upfront and documented
Changes are difficult and expensive late in the project
Agile
Iterative cycles (sprints) — each produces a working increment
Requirements evolve based on feedback after each sprint
Changes are welcomed and integrated at the end of each sprint
Scope
What the project will deliver — features, functions, requirements
If scope increases, time or cost must also increase
Scope creep is uncontrolled growth of scope without adjusting constraints
Time
The project schedule — start and end dates, milestones
If time is reduced, either scope must decrease or cost must increase
Crashing (adding resources) or fast-tracking (overlapping tasks) are ways to reduce time
Cost Constraint
Financial budget for the project — labour, materials, software licences
If cost is cut, you might reduce scope, extend time, or accept lower quality
Cost overruns often require a formal change request to increase budget
Quality Constraint
The level of performance, reliability, and usability required
If quality is reduced, you can finish faster or cheaper but with more defects
Quality is often measured through testing, reviews, and acceptance criteria
Scrum
Fixed-length sprints (e.g., two weeks) with committed goals
Has defined roles: Product Owner, Scrum Master, Development Team
Work is planned in sprint backlogs and reviewed in sprint reviews
Kanban
Continuous flow — no fixed iterations, work is pulled as capacity allows
No prescribed roles — teams often keep existing job titles
Work is visualised on a board with columns representing stages; limited work-in-progress per stage
Mistake
Agile means no planning and no documentation.
Correct
Agile involves continuous planning and does produce documentation, but it prioritises working software over comprehensive documentation. You still plan each sprint and create enough documentation to support the project. It is not 'no documentation' — it is 'just enough documentation'.
Beginners hear 'responding to change over following a plan' and think planning is optional. In reality, Agile projects plan in short cycles and update the plan constantly.
Mistake
Waterfall is always bad and outdated.
Correct
Waterfall is still widely used and is the correct choice for projects with clear, stable requirements, fixed budgets, and regulatory compliance needs. Many government and healthcare projects use Waterfall successfully.
The tech industry promotes Agile heavily, so beginners assume Waterfall is obsolete. The exam tests both as valid approaches in their proper contexts.
Mistake
The triple constraint means you can only control three things: scope, time, and cost.
Correct
The triple constraint means those three are interdependent — you cannot change one without affecting at least one other. You can control them, but they are interrelated. Quality and risk also matter, and often the triple constraint is expanded to include quality as a fourth element.
The name 'triple constraint' makes beginners think there are exactly three constraints. The exam expects you to know the classic triple but also recognise that quality and risk are additional constraints.
Mistake
In Agile, the project manager does not have a role.
Correct
The Scrum framework does not use the title 'project manager' — instead you have a Scrum Master who facilitates the process and a Product Owner who manages the product backlog. In other Agile frameworks (like Kanban), a project manager role may still exist. The exam tests specific Scrum roles, but Agile as a methodology does not ban project managers.
The popularity of Scrum leads beginners to think all Agile teams have no PM. The exam will ask about Scrum roles specifically, so understand that 'project manager' is not a defined Scrum role, but a project manager can still exist in an Agile organisation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Waterfall is a sequential approach where each phase (requirements, design, build, test, deploy) finishes before the next starts. Agile is an iterative approach where you work in short cycles (sprints) and adjust based on feedback after each cycle. Waterfall resists change; Agile embraces it.
The triple constraint is the model that says every project is limited by scope (what you build), time (the deadline), and cost (the budget). If you change one, you must change at least one of the others to keep the project balanced.
Neither is universally better. Waterfall is better for fixed-scope, regulated projects. Agile is better for projects with evolving requirements or where early feedback is valuable. The exam expects you to choose based on scenario details, not personal preference.
The Scrum Master is a facilitator and coach for the Scrum team. They remove impediments, ensure Scrum practices are followed, and protect the team from distractions. They do not assign tasks or manage people in a traditional sense.
Yes, that is called a hybrid methodology. For example, you might use Waterfall for high-level planning and compliance requirements, then use Agile for actual feature development. Many real-world projects use hybrid approaches.
Quality is a common fourth constraint, often added to form the 'Iron Triangle'. Risk is another — tight constraints increase project risk. The exam may also mention resources (people, equipment) as a constraint.
You've finished IT Project Methodologies and Constraints. Continue through the PK0-005 study guide to build a complete picture of the exam.
Done with this chapter?