Start where you are, iterate, simplify and automate

Start where you are, and what "directly" means

This principle says to assess the current state honestly before deciding what to build, and to keep whatever is already working. A team asked to replace an ageing tool that first inventories its integrations, workflows and data — and finds several components worth carrying forward — is applying it exactly. The failure it guards against is the clean-slate rebuild that throws away working parts along with the broken ones.

It has a second, sharper edge that questions like: measure the current state DIRECTLY rather than through somebody else's report. A manager planning an improvement from the supplier's monthly summary and never watching the service run has broken this principle, even though they did look at data. Second-hand summaries are shaped by whoever produced them, and the principle asks for observation.

Progress iteratively with feedback

Break the work into pieces small enough to finish, and use what each piece teaches before starting the next. The examinable failure is the programme that runs for months with nothing released because the team intends to hand over the finished thing in one go — no deliverable and, crucially, no feedback, so nobody knows whether any of it is right.

Note what the principle is actually about when a scenario has both halves. Dividing work into six cycles is the iteration half; reviewing results with users after each cycle and adjusting the plan is the feedback half, and when a question asks which principle the REVIEW-AND-ADJUST step illustrates, it is still this one. Iteration without feedback is just a schedule.

Keep it simple and practical

This principle owns the question of whether a step should exist at all. If an activity produces nothing anybody uses, it goes. The standard scenario is a report that is produced, circulated and archived every week while no decision anywhere depends on it — and the answer is not to automate its production or improve its formatting, it is to stop making it.

The instruction is to use the minimum number of steps that achieve the objective, which also means resisting the urge to design for every rare exception. A workflow with forty conditional questions that everybody must answer in order to make a routine request has optimised for the exception at the expense of the majority; the principle says to design the main path for the common case and handle the exceptions separately.

Optimize and automate, in that order

The two words are a sequence and the exam tests the sequence far more often than either half. Optimisation means making something as effective and useful as it can be; automation means using technology to run it with little or no human intervention. Automating first locks the waste in and makes it run faster, which is why an adviser insisting that redundant approval steps be removed BEFORE robotic process automation is applied is giving the textbook answer.

The principle also expects you to know that automation is not the goal. It is applied where it genuinely helps, after simplification, and a proposal to automate something that should not exist is a failure of the previous principle rather than of this one.