Scope of what is to be directed and/or planned, and principles and methods of direction and planning
Scope of what is to be directed and/or planned
Scope has three dimensions
When asked 'what should be directed and planned?', the safe and examinable answer is: the whole system that creates value, not just the IT function. Scope can be sliced three ways.
By level: strategic (long horizon, whole organization), tactical (medium horizon, a product, service or value stream), operational (short horizon, day-to-day delivery).
By dimension: the four dimensions of service management - organizations and people, information and technology, partners and suppliers, value streams and processes. Planning that touches only technology is incomplete.
By boundary: the value chain and the extended value system, including suppliers, partners and consumers. Direction and planning cross organizational boundaries; a plan that stops at the edge of the IT department fails at the first hand-off.
There is also the context of the organization - its purpose, culture, customers, competitors, regulation and constraints. Scope is meaningless without it.
Traps: questions baiting you into saying scope is 'IT services only', or that a governing body should not direct partners and suppliers. Another trap is assuming wider scope is always better; wider scope brings more alignment and value but more complexity, more stakeholders and slower decisions. Scope must be chosen deliberately and stated explicitly.
Rule of thumb: state scope as level + dimensions + boundary. If a scenario names only one of the three, expect the answer that reminds you the others still exist.
Principles and methods of direction and planning
Principles are universal; methods are chosen
The ITIL guiding principles are the backbone of this area: focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimize and automate. They apply to direction, planning and improvement alike, at every level. A common exam trap is treating them as mandatory procedures or a checklist completed once - they are decision heuristics applied continuously, and they can appear to conflict (for example 'start where you are' versus 'optimize and automate'), requiring judgement.
Methods, by contrast, are situational. Candidates should recognize the planning architecture - a vision and mission explaining purpose, a strategy that sets direction, objectives that make it measurable, and tactical and operational plans that sequence the work. Common approaches include top-down (coherent but detached from reality), bottom-up (grounded but fragmented) and a combination of both, which is usually the best answer. Lean contributes pull-based, demand-driven planning and waste elimination; Agile contributes iterative planning with feedback; DevOps contributes flow and automation; portfolio and roadmap techniques connect strategy to delivery.
Traps: assuming one method is 'correct' for everything; assuming guiding principles are only for project teams; confusing a roadmap (outcome-oriented, revisable) with a project plan (task-oriented, fixed).
Rule of thumb: choose the method that fits the type of work and degree of uncertainty - predictive planning for stable, well-understood work, iterative planning for uncertain work - then apply the guiding principles to keep it honest.