Managing performance connects a viable business model with effective people leadership and disciplined project delivery. This guide teaches ecosystem relationships, value creation and capture, leadership models, employee development, team communication and project planning tools. Its 20 original practice questions and 60 concepts follow the E2 allocation: 30% Business Models and Value Creation, 40% Managing People Performance and 30% Managing Projects. The supplied blueprint covers Objective Tests from January 2026 to January 2027 and applies on 16 October 2026; later versions are outside this guide. Citations establish syllabus relevance; worked explanations use established subject knowledge. This representative preview is not a full-length mock or official question set.
What this guide covers
Practise CIMA E2 with 20 original questions and 60 concepts on business models, people and projects.
Business Models and Value Creation
1. Ecosystems coordinate interdependent complements
A business ecosystem brings together participants whose complementary contributions enable a customer outcome. Unlike a simple sequence of purchases and sales, value depends on connections among offerings, information and incentives. An orchestrator may coordinate participation without owning the contributors. Competition can still exist within and between ecosystems. To recognise the model, identify the customer outcome, the required complements and the dependencies that prevent one participant delivering it alone. Having many suppliers is insufficient: the important distinction is how their contributions interact and are coordinated.
Worked example: An electric-vehicle service combines cars, charging access, payment processing and route information. A charging outage weakens the vehicle proposition even though the manufacturer does not own the chargers, showing why partner coordination affects the customer's overall experience.
Common mistake: Treating every supplier network as an ecosystem overlooks whether complementary offerings actually depend on coordinated participation to create customer value.
Official syllabus reference: [1]
2. Ecosystem roles and dependency bottlenecks
Ecosystem analysis distinguishes users, complementors, suppliers, orchestrators and institutions that shape participation. One organisation can perform several roles. Map the flows of services, data, money and permissions rather than listing organisations alone. A bottleneck arises where an essential contribution has limited substitutes or inadequate capacity, constraining the whole proposition. The appropriate response might be developing alternatives, supporting the participant or redesigning dependencies. A participant's small revenue share does not prove low strategic importance when the service cannot function without its contribution.
Worked example: A home-energy platform has many appliance suppliers but only one provider of an essential connection protocol. Management prioritises an alternative integration route because failure at that small provider would prevent customers connecting otherwise compatible equipment.
Common mistake: Ranking ecosystem importance solely by spending can miss a low-cost participant whose unique capability constrains the entire customer offering.
Official syllabus reference: [1]
3. Ecosystem governance balances access and trust
Ecosystem governance establishes participation rules, decision rights, data permissions, quality requirements and dispute mechanisms. Open access can attract complementary innovation, but uncontrolled entry may weaken service quality or confidence. Restrictive rules can protect users while discouraging contributors if compliance is costly or decisions appear arbitrary. Governance therefore needs a defensible balance between access, interoperability and assurance. Regulation and societal expectations form part of the environment, but the applicable obligations depend on the activity and jurisdiction; ecosystem participation does not remove each organisation's responsibilities.
Worked example: A payments platform publishes interface requirements, tests new applications and explains suspension and appeal procedures. Developers can innovate within known boundaries, while merchants gain confidence that an application's access to transaction information is controlled and reviewable.
Common mistake: Assuming openness requires unrestricted access confuses accessible participation rules with the absence of safeguards, accountability or quality assurance.
Official syllabus reference: [1]
4. APIs, scalability and network effects
Application programming interfaces enable systems to exchange information through defined requests and responses. Common interfaces reduce the cost of connecting participants, while scalable infrastructure supports higher activity without redesigning every connection. Network effects arise when participation increases value for other users, either within one group or across complementary groups. They differ from economies of scale, which concern unit costs. Technology enables these effects but does not guarantee them: congestion, poor matches or low-quality participation can reduce value as a network grows. Assess actual participant benefits alongside technical capacity.
Worked example: A booking platform exposes an availability API that hotels can connect to once. More participating hotels improve customer choice, and more customers attract hotels. However, inaccurate listings can weaken those benefits even when the platform handles traffic successfully.
Common mistake: Calling every fall in unit cost a network effect confuses production efficiency with additional value created by other participants.
Official syllabus reference: [1]
5. Ecosystem transition costs and dependency risk
Moving from a traditional market model into an ecosystem can require integration spending, new contracts, retraining and changes to established revenue streams. Benefits may depend on partners joining together, creating coordination risk before sufficient participation exists. Dependence on an orchestrator can expose contributors to changed fees, access conditions or data restrictions. Evaluate transition costs separately from ongoing operating costs, and examine switching options, interoperability and exit arrangements. A promising future network can still destroy value if migration disrupts existing customers faster than the new proposition becomes viable.
Worked example: An equipment seller shifts toward a connected maintenance platform. It budgets for sensor installation and support training, retains conventional servicing during migration and negotiates data portability so customers can continue operating if the platform partnership ends.
Common mistake: Comparing only steady-state margins overlooks migration disruption, partner coordination costs and the possibility that adoption develops more slowly than expected.
Official syllabus reference: [1]
6. The four connected value mechanisms
A business model explains how an organisation defines, creates, delivers and captures value. Defining identifies stakeholders and their needs; creating assembles capabilities and activities; delivering makes the offering accessible and usable; capturing establishes revenues, costs and surplus distribution. These mechanisms must reinforce one another. A compelling promise can fail through inadequate resources, difficult access or uneconomic pricing. Analyse the complete chain and identify the principal weakness before recommending change. The model describes how the organisation works economically and operationally, whereas a single product feature describes only part of its offering.
Worked example: A remote bookkeeping service promises timely accounts, creates value through trained staff and automation, delivers through a client portal and captures value through monthly fees. Slow document onboarding would primarily weaken delivery despite capable accountants and attractive pricing.
Common mistake: Equating a business model with its pricing method leaves customer needs, operational capabilities and delivery arrangements unexplained.
Official syllabus reference: [1]
7. Stakeholder salience and conflicting needs
Defining value starts by identifying stakeholders, understanding their claims and deciding whose needs require priority. A salience lens considers power, legitimacy and urgency rather than assuming every visible demand has equal importance. Also examine dependency: employees, partners or communities may enable the proposition despite limited bargaining power. Ranking guides attention, but does not erase duties or justify disregarding adverse effects. Translate stakeholder needs into explicit requirements, identify conflicts and test whether the proposed arrangement remains attractive enough for essential participants to continue contributing.
Worked example: A transport platform hears strong investor demands for growth, but driver departures threaten service availability. Management evaluates drivers' income predictability alongside investor returns, then revises scheduling and fees because the growth proposition depends on sustained driver participation.
Common mistake: Treating stakeholder ranking as permission to ignore lower-power groups overlooks legitimate claims and dependencies that can undermine the business model.
Official syllabus reference: [1]
8. Value propositions connect jobs, pains and gains
A useful value proposition links an offering to a stakeholder's required outcome, problems and desired benefits. The jobs, pains and gains approach asks what the customer is trying to accomplish, what makes that difficult and what improvement matters. Features create value only when they credibly support those outcomes. Distinguish the user from the payer when their priorities differ. Test the proposition using evidence of behaviour, willingness to adopt and practical constraints, rather than relying solely on favourable opinions. Specificity helps align product design, operations and communication.
Worked example: A clinic buys scheduling software, but receptionists use it. The proposition combines fewer missed appointments for the clinic with simpler rescheduling for staff. Automatic reminders matter because they support these outcomes, rather than merely adding another software feature.
Common mistake: Listing product features as benefits skips the causal link between what the offering does and the stakeholder outcome it improves.
Official syllabus reference: [1]
9. Resource, activity and partnership alignment
Creating value requires a coherent combination of resources, capabilities, activities and external relationships. Resources include assets, data and expertise; capabilities describe the organisation's ability to combine them effectively. Activities turn those capabilities into outputs, while partnerships supply complements or access. Assess alignment with the promised customer outcome, not simply the quality of each component in isolation. A premium service may need reliable capacity and skilled judgment rather than maximum utilisation. An attractive capability that does not support the proposition can add complexity and cost without improving stakeholder value.
Worked example: A same-day repair business acquires diagnostic equipment but has no technicians trained to use it. Training and spare-parts coordination are necessary complements; equipment ownership alone cannot deliver the promised repair speed or dependable first-time resolution.
Common mistake: Assuming possession of valuable assets establishes capability overlooks the routines, skills and complementary inputs needed to turn assets into outcomes.
Official syllabus reference: [1]
10. Delivery channels and customer relationships
Delivering value covers how customers discover, evaluate, purchase, receive, use and obtain support for an offering. Channels can be direct, partner-based, physical or digital, and different stages may use different channels. Customer relationships range from self-service to dedicated assistance. Choose arrangements that fit customer needs and the economics of support. Removing human contact can reduce transaction cost but increase abandonment where decisions are complex. Examine handoffs and accessibility across the whole journey, because a strong product can lose value when purchasing or using it becomes unnecessarily difficult.
Worked example: A pension administration provider lets employers submit routine data online but assigns specialists to complex migrations. The mixed delivery model reserves expensive support for difficult transitions while maintaining convenient self-service for predictable monthly tasks and common enquiries.
Common mistake: Choosing channels solely by their transaction cost overlooks abandonment, customer capability and the support required to realise the promised benefit.
Official syllabus reference: [1]
11. Cost structures and contribution logic
A cost model explains what drives expenditure as activity changes. Fixed costs remain unchanged within a stated range and period, while variable costs change with the relevant activity driver. Contribution equals revenue less variable costs and helps show how activity supports fixed costs and surplus. Digital models may have high development costs and low incremental delivery costs, but support, capacity or partner payments can still rise with use. State the assumed range and drivers explicitly; costs can become stepped or change behaviour when capacity limits are reached.
Worked example: A service charges USD 20 per account and incurs USD 8 variable cost, leaving USD 12 contribution. With monthly fixed costs of USD 6,000, 500 accounts cover those costs, assuming capacity and unit prices remain unchanged.
Common mistake: Assuming digital delivery makes all additional users costless ignores support demand, infrastructure capacity and contractual payments linked to activity.
Official syllabus reference: [1]
12. Revenue architecture: subscription, usage and freemium
Revenue architecture specifies who pays, what they pay for, how charges vary and when payment occurs. Subscriptions charge for continuing access; usage models link charges to consumption; licensing grants specified rights; transaction models charge when exchanges occur. Freemium combines a free tier with paid features or capacity, relying on conversion or another funding source. Match the payment basis to customer value and cost drivers. Predictable subscription revenue still depends on retention, while usage pricing can improve alignment but introduce volatility and discourage consumption if customers cannot predict bills.
Worked example: A design application offers free basic editing and charges for team controls. Management tests whether paid teams generate enough contribution to fund both premium support and free-user infrastructure, rather than treating every free registration as economically valuable growth.
Common mistake: Calling free-user growth revenue success overlooks conversion, retention and the costs that paying customers must cover across the whole service.
Official syllabus reference: [1]
13. Surplus sharing and participation incentives
Capturing value involves both earning revenue and deciding how economic benefits are shared. Customers may receive lower prices or better outcomes; employees receive compensation; partners receive contractual payments; investors may receive distributions; retained funds support resilience and investment. Distinguish payments treated as operating costs from distributions of the resulting surplus, according to the stated arrangement. Sustainable sharing considers contributions, alternatives and future participation. Maximising one party's immediate share can weaken the system if essential contributors leave, reduce quality or stop investing in complementary capabilities.
Worked example: A marketplace increases its commission and initially retains more per sale. Sellers then withdraw exclusive products, reducing customer demand. Management evaluates total transaction value and seller incentives before deciding whether the higher commission actually improves long-term retained surplus.
Common mistake: Assuming the largest possible commission maximises captured value ignores how altered incentives can reduce participation and the total value available.
Official syllabus reference: [1]
14. Digital disruption and resilient model redesign
Digital disruption changes how value is produced, accessed or monetised, potentially weakening established advantages. A platform can coordinate external contributors, while a pipeline mainly organises a more linear sequence of activities. Resilience requires identifying which assumptions are threatened and testing alternative propositions, channels or revenue arrangements. Digitising an existing process may improve efficiency without changing the business model. Avoid assuming every digital entrant is a disruptive innovator in the strict theoretical sense; examine its customers, trajectory and competitive mechanism. Cannibalisation may be necessary when protecting the old model would sacrifice future relevance.
Worked example: A training company facing inexpensive online courses introduces subscription access and tutor-supported modules. It tests demand and contribution separately for each offer, recognising that moving classroom slides online alone would not address customers' changing expectations about access and pricing.
Common mistake: Describing any technology purchase as business-model disruption confuses process improvement with a change in how stakeholders receive and fund value.
Official syllabus reference: [1]
15. Build, buy and partner capability choices
Building develops capabilities internally, buying acquires ownership, and partnering obtains coordinated access without necessarily acquiring the provider. Compare strategic control, development time, available skills, integration difficulty, commitment and intellectual-property arrangements. Building can preserve distinctive knowledge but delay entry. Buying can accelerate access while creating valuation and integration risks. Partnering can limit initial commitment but increase dependency and require strong governance. The preferred route follows the capability's importance and the organisation's constraints; speed alone does not establish that an acquisition is feasible or that an external arrangement is sufficiently controllable.
Worked example: A retailer needs fraud screening before a seasonal peak. It partners with an established provider for immediate coverage while building internal expertise to manage rules and supplier performance. Acquisition is unnecessary because ownership is not essential to the initial objective.
Common mistake: Selecting acquisition whenever speed matters overlooks integration time, ownership requirements and whether a partnership can provide adequate capability sooner.
Official syllabus reference: [1]
16. Investment, incubation and acceleration
Investment can provide financial exposure and access to emerging capabilities without full ownership. Incubation supports an early idea while the team develops its proposition, capability and evidence of demand. Acceleration generally helps an existing venture develop faster through concentrated support, connections or market access. Terminology varies across programmes, so inspect the actual arrangement. These routes differ from buying a mature capability: experimentation and uncertainty remain central. Set learning milestones and decision points so additional funding depends on evidence, while ensuring the parent organisation can absorb or collaborate with successful ventures.
Worked example: An insurer incubates an untested claims-assistance idea until a pilot demonstrates user demand. It later joins an accelerator to gain distribution partners. A minority investment funds expansion without implying that the insurer now controls the venture's operating decisions.
Common mistake: Treating incubation, acceleration and acquisition as interchangeable overlooks the venture's maturity, ownership rights and the uncertainty each route retains.
Official syllabus reference: [1]
17. Digital operating models and end-to-end ownership
A digital operating model specifies how people, processes, data and technology organise work to deliver the business model. End-to-end process ownership reduces failures at departmental handoffs, while shared data definitions and modular systems support coordinated decisions and adaptation. Cross-functional teams can shorten feedback loops when they have clear responsibilities and access to users. Technology alone cannot resolve contradictory objectives or unclear decision rights. Assess the operating model by service outcomes, reliability and responsiveness, and retain appropriate controls as work becomes more automated and distributed across organisational boundaries.
Worked example: An online lender replaces separate departmental queues with a team responsible for the application journey. Shared status data exposes missing documents immediately, while clear approval rights preserve credit control. The improvement comes from coordinated work design as well as software.
Common mistake: Assuming a new application creates a digital operating model overlooks process ownership, common data definitions and the authority needed to resolve handoffs.
Official syllabus reference: [1]
18. Digital workforce design and human–robot boundaries
Building a digital workforce combines attraction, retention, skills development, leadership and job redesign. Decompose work into tasks before deciding what to automate: repetitive rule-based processing differs from judgment, relationship management and unfamiliar exceptions. Define human review points, escalation routes and responsibility for automated outputs. On-demand specialists can fill capability gaps, but knowledge transfer, access and continuity need deliberate design. An employer-of-choice proposition includes meaningful development and credible careers, not merely recruitment messaging. Incentives and culture should support experimentation and learning without rewarding avoidable process failures or concealed automation errors.
Worked example: A finance team automates invoice matching and trains staff to investigate exceptions and improve supplier data. Temporary developers document the rules and transfer knowledge to permanent employees, allowing the organisation to maintain the robots after the implementation contract ends.
Common mistake: Planning automation only as headcount substitution overlooks exception handling, retained expertise and the new capabilities required to maintain dependable operations.
Official syllabus reference: [1]
Managing People Performance
19. Power, authority and ethical influence
Authority is the accepted right attached to a role to make specified decisions. Power is the capacity to influence behaviour and can arise from expertise, rewards, sanctions, personal identification or legitimate position. Formal authority therefore does not guarantee effective influence, and influence can exist without managerial rank. Ethical leadership examines how that influence is used, including transparency, fair treatment and handling conflicts of interest. Choose influence methods suited to the issue: technical credibility may persuade specialists more effectively than hierarchy, while formal authority remains relevant to accountability and decisions.
Worked example: A project leader can allocate work through formal authority, but an experienced engineer persuades the team to change an unsafe design through expert power. The leader evaluates the evidence openly rather than treating disagreement as a challenge to personal status.
Common mistake: Equating authority with all organisational influence overlooks expert and referent power, which can operate independently of formal reporting relationships.
Official syllabus reference: [1]
20. Delegation and empowerment require decision boundaries
Delegation assigns a task and sufficient authority to another person while the manager retains accountability for appropriate oversight. Effective delegation specifies the result, decision limits, resources, reporting and circumstances requiring escalation. Empowerment goes further by giving people meaningful discretion and the capability to exercise it. Responsibility without access or authority creates frustration rather than empowerment. Match oversight to task risk and competence, and avoid taking decisions back unnecessarily after granting discretion. Delegation should develop capacity and improve responsiveness while keeping material decisions visible through proportionate control.
Worked example: A manager authorises an analyst to resolve billing errors up to an internally agreed amount and specifies exceptions requiring escalation. The analyst receives system access and weekly feedback, so the responsibility is supported by practical authority and learning opportunities.
Common mistake: Calling an assignment empowerment while retaining every approval creates responsibility without discretion and usually increases delay rather than ownership.
Official syllabus reference: [1]
21. Trait and behavioural leadership approaches
Trait approaches examine characteristics associated with leadership, such as confidence, integrity or cognitive ability. Behavioural approaches examine what leaders do, including task structuring and attention to relationships. These perspectives answer different questions: possessing a characteristic does not specify the behaviour needed in a particular situation. Task-oriented behaviour can clarify standards and coordination, while relationship-oriented behaviour can support trust and participation. Neither provides a universally superior style. Use the distinction to diagnose whether a recommendation concerns selection characteristics, observable conduct or adaptation to circumstances rather than mixing them together.
Worked example: A technically confident supervisor still gives ambiguous instructions. Recruiting for confidence would not directly fix the problem; setting explicit responsibilities and checking understanding would change the relevant behaviour. The example separates a personal characteristic from an observable management practice.
Common mistake: Assuming a desirable personality trait guarantees effective leadership overlooks what the leader actually does and whether it suits the task.
Official syllabus reference: [1]
22. Situational leadership uses task-specific readiness
Situational leadership adapts direction and support to the follower's competence and commitment for a particular task. A willing novice usually needs explicit guidance, while a capable employee may need participation or discretion rather than detailed instruction. Assess the actual assignment, because expertise in one area does not establish readiness in another. Adjust support as demonstrated capability and confidence change. This approach treats leadership behaviour as adaptable; it should not become a permanent label attached to an employee. Its practical value lies in matching the immediate leadership response to the identified development need.
Worked example: A senior accountant can independently prepare familiar reports but is new to leading supplier negotiations. Her manager delegates the reporting work while rehearsing negotiation preparation with her, adjusting support by task rather than applying one style to both responsibilities.
Common mistake: Using job seniority as a substitute for task competence can lead to premature delegation when an experienced employee faces unfamiliar work.
Official syllabus reference: [1]
23. Fiedler's contingency model matches leader and situation
Fiedler's model examines the fit between a relatively stable leadership orientation and situational favourableness. The situation depends on leader–member relations, task structure and position power. In the model, task-oriented leaders tend to fit very favourable or very unfavourable situations, while relationship-oriented leaders tend to fit intermediate situations. This differs from approaches that ask a leader to change style readily. A practical response may involve restructuring the task, strengthening legitimate authority or changing the leadership assignment. The model is an analytical framework, not a guarantee of individual effectiveness.
Worked example: A project has unclear tasks, mixed team trust and limited managerial authority. Rather than simply instructing a task-oriented leader to become relationship-oriented, management considers clarifying deliverables and decision rights to improve the fit between the leader and the situation.
Common mistake: Treating Fiedler's model as advice to switch styles daily misses its assumption that leadership orientation is comparatively stable.
Official syllabus reference: [1]
24. Transactional and transformational leadership
Transactional leadership clarifies expected performance and links it to contingent rewards or corrective action. Transformational leadership develops commitment through purpose, intellectual challenge, role modelling and attention to individual development. The approaches can complement one another: a team may need reliable operating standards and motivation to question outdated processes. Vision without resources and accountability can disappoint, while incentives alone may not generate commitment to uncertain change. Identify the mechanism in the scenario rather than assuming an inspiring speech proves transformation or that all reward systems prevent meaningful leadership.
Worked example: During a service redesign, a director explains how improved access will benefit customers, invites staff to challenge old assumptions and coaches emerging leaders. She also sets clear delivery milestones, combining transformational development with transactional clarity about performance expectations.
Common mistake: Assuming transformational leadership removes the need for explicit standards overlooks the operating discipline required to turn shared purpose into results.
Official syllabus reference: [1]
25. Distributed leadership in virtual teams
Distributed leadership allows influence and responsibility to move toward relevant expertise rather than remaining entirely with one formal leader. In virtual teams, this can improve decisions across locations and time zones, provided decision rights and coordination are clear. Shared records, explicit handoffs and accessible discussion channels reduce dependence on informal office contact. The formal leader still supports integration, resolves conflicts and maintains accountability. Distributing leadership does not mean every decision requires consensus or that the most vocal person should decide; authority should reflect the issue, competence and agreed governance.
Worked example: A global implementation team lets local specialists lead jurisdiction-specific configuration discussions while a central owner controls shared architecture. Decisions are recorded with reasons and owners, allowing colleagues in later time zones to continue work without reopening settled technical questions.
Common mistake: Interpreting distributed leadership as leaderless consensus overlooks the need for decision ownership, integration and visible accountability across dispersed work.
Official syllabus reference: [1]
26. Performance management, SMART objectives and MBO
Performance management is a continuing cycle of agreeing expectations, enabling work, reviewing evidence and improving results. Management by objectives aligns individual commitments with organisational goals through agreed outcomes. SMART objectives make expectations specific, measurable, achievable, relevant and time-bound, but a measurable target can still be strategically unhelpful. Define both the desired result and relevant quality or behavioural boundaries. Regular conversations allow obstacles and changed assumptions to be addressed before a formal appraisal. The objective should clarify accountability without implying control over factors the employee cannot reasonably influence.
Worked example: A reporting analyst agrees to deliver the monthly dashboard within three working days, with reconciled source totals and documented exceptions. The manager supplies system access and reviews bottlenecks monthly, connecting a clear target with the resources needed to achieve it.
Common mistake: Treating SMART wording as proof of a good objective overlooks strategic relevance, conflicting incentives and whether the employee controls the result.
Official syllabus reference: [1]
27. Target gaming and balanced behavioural controls
Targets influence how people allocate attention and effort. A narrow measure can encourage gaming, short-termism or local optimisation when employees improve the indicator without improving the underlying objective. Balanced measures combine relevant dimensions, such as speed and quality, while clear definitions and evidence checks reduce manipulation. Excessive measurement can itself create bureaucracy and confusion, so select a manageable set with explicit trade-offs. Participation in target setting can improve understanding and commitment, but does not remove the need to challenge easy targets or assumptions that no longer reflect operating conditions.
Worked example: A warehouse rewards orders dispatched, so staff send incomplete orders quickly and create later rework. Adding complete-and-correct delivery alongside timeliness changes the incentive, while tracking rework helps determine whether the revised measures improve the intended customer outcome.
Common mistake: Assuming accurate measurement prevents dysfunctional behaviour overlooks employees' ability to optimise a valid indicator while weakening the broader organisational objective.
Official syllabus reference: [1]
28. Appraisal methods: BARS, objectives and 360 feedback
Different appraisal methods capture different evidence. Results-based appraisal compares outcomes with agreed objectives. Behaviourally anchored rating scales describe observable behaviours at defined performance levels, helping assess how work is performed. Multisource or 360-degree feedback gathers perspectives from relevant colleagues, managers or customers and is often useful for development. None is automatically comprehensive: outcomes may reflect external conditions, behaviours require relevant anchors, and feedback can reflect limited observation or relationships. Select methods for the role and purpose, and combine evidence where one source cannot adequately represent performance.
Worked example: A team leader meets budget targets but colleagues report poor handoffs. Results data establish delivery, behavioural anchors assess coordination practices, and structured peer feedback identifies where others experience problems. The combined evidence supports a more specific development discussion than one overall score.
Common mistake: Treating a 360-degree average as an objective verdict overlooks differences in observation, purpose and the quality of the underlying feedback.
Official syllabus reference: [1]
29. Appraisal bias and evidence calibration
Appraisal bias can distort judgments even when managers intend to be fair. Halo effects allow one favourable feature to influence unrelated ratings; horns effects do the reverse. Recency bias overweights recent events, while leniency, severity and central tendency distort rating distributions. Similarity bias favours people who resemble the assessor. Use role-relevant criteria, evidence from the full review period and examples supporting each judgment. Calibration discussions can improve consistency, but forced distributions are not proof of accuracy. Separate observed behaviour from assumptions about personality, motive or potential.
Worked example: A manager initially rates an analyst highly across every category because of a polished presentation last week. Reviewing dated evidence reveals repeated missed deadlines earlier in the year, allowing communication skill and delivery reliability to be assessed separately.
Common mistake: Believing a confident assessor is unbiased overlooks systematic judgment errors that require structured evidence rather than stronger personal conviction.
Official syllabus reference: [1]
30. Vroom's expectancy, instrumentality and valence
Expectancy theory distinguishes belief that effort can produce performance, belief that performance produces an outcome, and the value attached to that outcome. These are expectancy, instrumentality and valence respectively. In the familiar multiplicative representation, a weak link can substantially reduce motivational force. Diagnose the missing link before changing rewards: training and resources address expectancy; credible reward delivery addresses instrumentality; reward choice addresses valence. The framework explains perceived relationships rather than guaranteeing behaviour, because people can value several outcomes and face competing demands or constraints.
Worked example: Employees value promotion and believe they can meet the targets, but previous promotions appeared unrelated to results. Publishing clear criteria and applying them consistently addresses instrumentality; another training course would not directly repair the performance-to-promotion relationship they distrust.
Common mistake: Increasing a reward's value will not necessarily motivate employees who doubt either their ability to perform or management's promise to deliver it.
Official syllabus reference: [1]
31. Herzberg's hygiene factors and motivators
Herzberg distinguishes hygiene factors associated with dissatisfaction from motivators associated with satisfaction and engagement in the work itself. Pay administration, supervision and working conditions commonly illustrate hygiene factors; achievement, recognition, responsibility and growth illustrate motivators. Removing an irritating condition does not necessarily make work meaningful. Job enrichment changes the depth of responsibility and learning, whereas job enlargement can merely add similar tasks. The model is a useful diagnostic lens, not a universal prediction that pay never motivates. Assess employees' actual experiences and avoid using enrichment language to disguise unsupported workload increases.
Worked example: A finance team receives reliable equipment and clearer expense procedures, reducing frustration. The manager then gives analysts ownership of improvement investigations and recognition for implemented ideas, addressing achievement and responsibility rather than assuming better equipment alone creates lasting enthusiasm.
Common mistake: Claiming that hygiene factors are unimportant overlooks how poor conditions can create dissatisfaction even when the underlying work offers responsibility and achievement.
Official syllabus reference: [1]
32. Capability, conduct, discipline and grievances
Poor performance can arise from capability gaps, inadequate resources, unclear expectations or conduct. Diagnose the cause using evidence before selecting a response. Capability problems may need training, support and defined improvement expectations; conduct concerns require an appropriate investigation and proportionate process. A grievance is an employee's concern or complaint and needs a route that can examine it fairly, particularly where the immediate manager is involved. Applicable procedures vary by employer and jurisdiction. Clear notice, an opportunity to respond, impartial consideration and records support sound decisions without presuming a particular legal timetable.
Worked example: An employee repeatedly misses a reporting deadline after a system change. Investigation shows access permissions were removed. Restoring access addresses the cause; if the employee also complains about the manager's treatment, that concern receives its own fair review.
Common mistake: Treating every shortfall as misconduct bypasses the distinction between unwillingness, missing capability and organisational barriers that prevent satisfactory performance.
Official syllabus reference: [1]
33. GROW coaching converts reflection into action
GROW structures coaching around Goal, Reality, Options and Will or Way forward. Establish the desired outcome, explore current evidence, generate possible approaches and agree a specific commitment. Effective questions help the employee examine assumptions and take ownership rather than merely accept the coach's preferred answer. Coaching is particularly useful when someone can develop judgment through reflection and practice. It does not replace direct instruction where essential knowledge is missing. A concrete action, timing and review point make the conversation assessable while preserving the employee's responsibility for carrying it out.
Worked example: An analyst wants clearer presentations. She identifies that questions derail her opening explanation, considers rehearsal and a structured summary, then commits to practising with a colleague before Thursday. The coach schedules feedback after the next presentation to examine what changed.
Common mistake: Calling a sequence of instructions coaching misses the employee-led exploration and commitment that distinguish GROW from straightforward task direction.
Official syllabus reference: [1]
34. Mentoring develops longer-term professional judgment
Mentoring uses a more experienced person's perspective to support broader development, professional identity and career decisions. Coaching often focuses more tightly on a particular performance goal, though the approaches can overlap. A mentor can explain organisational patterns, share experience and challenge assumptions without making the mentee's decisions. Clarify purpose, confidentiality boundaries, conflicts and expectations at the outset. Effective mentoring broadens access to insight rather than creating dependence or an exclusive sponsorship network. Its value should appear in stronger judgment, wider perspective and development choices, not merely in the frequency of meetings.
Worked example: A newly appointed finance manager discusses cross-functional influence with an experienced manager outside her reporting line. The mentor shares how competing priorities are negotiated and asks her to evaluate options, while leaving the actual stakeholder decisions with the mentee.
Common mistake: Expecting a mentor to secure promotions or decide every difficult issue confuses development support with patronage and weakens independent professional judgment.
Official syllabus reference: [1]
35. Schein's three levels of organisational culture
Schein distinguishes visible artefacts, espoused values and underlying assumptions. Artefacts include rituals, language and physical arrangements; espoused values are stated principles; assumptions are deeply embedded beliefs about how things work. Contradictions between statements and rewarded behaviour reveal where the operative culture may differ from official messaging. Diagnose patterns across decisions rather than inferring culture from one poster or incident. Changing symbols alone rarely changes assumptions if incentives, selection and leadership conduct remain unchanged. Culture affects performance by shaping what employees consider acceptable, safe to discuss and likely to be rewarded.
Worked example: A company displays posters inviting challenge, but managers promote employees who never question forecasts. Staff learn that agreement is safer than candour. Changing meeting language helps little until leaders welcome evidence-based disagreement and stop penalising those who raise inconvenient facts.
Common mistake: Using stated values as a complete description of culture overlooks underlying assumptions revealed by everyday rewards, sanctions and leadership decisions.
Official syllabus reference: [1]
36. Diversity, equality and inclusive work design
Diversity concerns differences among people; equality concerns fair treatment and opportunity; inclusion concerns whether people can participate and contribute effectively. Identical processes can produce barriers when employees have different access needs or circumstances. Examine job-related criteria, recruitment channels, meeting practices and development opportunities for avoidable exclusion. Adjustments should address the relevant barrier while preserving necessary performance requirements. Legal duties vary by jurisdiction, so distinguish the management principle from specific statutory claims. Better inclusion can improve information and decisions, but diverse membership alone does not ensure that minority perspectives are heard.
Worked example: A promotion process relies on informal evening networking, limiting access for some carers. The employer introduces transparent criteria and structured development discussions during working hours, improving access to evidence-based assessment without reducing the competence required for the role.
Common mistake: Equating fairness with identical treatment overlooks barriers that prevent people with different needs from accessing the same genuine opportunity.
Official syllabus reference: [1]
37. Workplace safety and prevention controls
Managing the work environment includes physical and psychosocial hazards, such as unsuitable equipment, excessive workload and persistent intimidation. Identify hazards, understand who may be affected and select controls that address the source where practicable. Eliminating or redesigning hazardous work generally offers stronger prevention than relying only on personal vigilance or training. Employer and employee responsibilities interact, but management cannot create a sound environment merely by telling individuals to be careful. Use reports, work patterns and consultation to evaluate controls, while recognising that exact legal duties depend on the applicable jurisdiction.
Worked example: A finance department's month-end process repeatedly requires overnight work because inputs arrive late. Management changes upstream deadlines and capacity allocation rather than relying solely on resilience training, addressing the workload source while retaining a route for employees to report concerns.
Common mistake: Treating wellbeing as an individual coping problem can leave excessive workload and harmful work design untouched despite repeated evidence of strain.
Official syllabus reference: [1]
38. Tuckman's development stages and leadership responses
Tuckman's model describes forming, storming, norming, performing and, in the extended model, adjourning. Early orientation gives way to challenges over roles and influence, followed by shared expectations and more effective task coordination. Leadership responses should address the observed issue: clarify purpose during forming, help resolve role disputes during storming and support autonomy as coordination improves. Stages are descriptive rather than a fixed timetable. Membership changes, new objectives or pressure can return a team to earlier issues, so apparent regression should prompt diagnosis rather than automatic criticism.
Worked example: A team that previously delivered smoothly gains two specialists and begins disputing decision rights. The manager revisits responsibilities and working agreements instead of assuming the team has permanently lost capability or that more technical training will resolve the conflict.
Common mistake: Assuming teams progress once through a fixed sequence overlooks how changed membership or tasks can reopen questions of trust, roles and coordination.
Official syllabus reference: [1]
39. Belbin roles and complementary team contributions
Belbin's team-role framework describes patterns of contribution, such as generating ideas, evaluating options, coordinating effort and completing details. A team needs complementary behaviours rather than several people with identical strengths. Team roles differ from job titles and technical qualifications, and individuals may contribute in more than one way. Use the framework to identify missing behaviours or tensions, not to label people permanently or infer ability from a questionnaire alone. Strong teams combine complementary contributions with shared goals, trust and accountability; role variety by itself does not resolve poor coordination.
Worked example: A planning team generates many proposals but repeatedly misses practical details. Assigning someone to challenge feasibility and another to check completion addresses missing contributions, while keeping everyone accountable for the final plan rather than isolating them within permanent personality labels.
Common mistake: Treating team roles as fixed personality boxes restricts development and overlooks how people can change their contribution with the task and circumstances.
Official syllabus reference: [1]
40. Communication encoding, noise and feedback
Communication involves encoding meaning, transmitting it through a channel, decoding it and using feedback to check understanding. Noise includes technical disruption, jargon, assumptions, emotion and conflicting cultural interpretations. Channel choice should match complexity, urgency and the need for interaction. Non-verbal signals can add information, but their meaning depends on context and should not be treated as conclusive evidence of intention. Ask recipients to explain important implications in their own words and create space for questions. Sending a message proves transmission activity, not shared understanding or agreement.
Worked example: A controller emails that a forecast needs a 'conservative adjustment'. Different teams interpret this differently. A short discussion using numerical examples establishes the intended assumption, and a written record then gives all teams the same basis for revising their forecasts.
Common mistake: Assuming silence confirms understanding overlooks uncertainty, language barriers and reluctance to question someone who appears to have greater organisational authority.
Official syllabus reference: [1]
41. BATNA, reservation points and principled negotiation
A BATNA is the best available alternative if negotiation fails. A reservation point is the least acceptable agreement after considering alternatives and relevant costs. A zone of possible agreement exists where the parties' acceptable outcomes overlap. Principled negotiation explores interests behind positions and uses credible criteria to develop options. Knowing your BATNA strengthens evaluation but does not reveal the other party's limit. Prepare evidence, alternatives and tradeable issues, then test proposals against the complete package. A lower price may be unattractive if service, risk or switching costs make the overall outcome worse.
Worked example: A buyer can switch suppliers for USD 95 per unit, but switching adds USD 8 per unit during transition. An incumbent offer of USD 100 may therefore be preferable initially, even though its quoted price exceeds the alternative's headline price.
Common mistake: Comparing headline offers without switching costs or service differences can make an apparently stronger alternative worse than the proposed negotiated agreement.
Official syllabus reference: [1]
42. Thomas–Kilmann conflict modes
The Thomas–Kilmann framework distinguishes competing, collaborating, compromising, avoiding and accommodating using assertiveness and cooperativeness. Collaboration seeks an outcome addressing important interests on both sides, while compromise accepts mutual concessions. Avoidance may allow cooling-off or information gathering, but can leave important issues unresolved. Accommodation can preserve a relationship where the other issue matters more, while competition may suit an urgent decision requiring clear authority. No mode is universally best. Diagnose the conflict's source, stakes, urgency and relationship before choosing a response, and distinguish useful task disagreement from damaging personal conflict.
Worked example: Sales and operations dispute a delivery promise. Instead of splitting the requested date mechanically, they examine customer priorities and production options, discovering that a partial shipment meets the urgent need. Collaboration creates an option that simple compromise would have missed.
Common mistake: Calling every negotiated middle position collaboration overlooks the difference between splitting concessions and developing an option that addresses underlying interests.
Official syllabus reference: [1]
Managing Projects
43. Time, cost and quality objectives
Project objectives need explicit time, cost and quality requirements alongside the intended business outcome. These dimensions interact: accelerating delivery may require extra resources, while adding scope can increase testing and integration effort. Quality should be translated into acceptance criteria rather than left as a vague aspiration. The familiar constraint framework supports trade-off discussions but does not mean every change automatically worsens another dimension; process improvements can sometimes improve several. Evaluate proposed decisions against the actual baseline, available capacity and benefits rather than assuming finishing quickly is sufficient evidence of project success.
Worked example: A payroll implementation must complete before a stated pay cycle, remain within its approved budget and pass agreed reconciliation tests. An earlier launch is not successful if incorrect deductions require extensive rework and damage employee confidence in the service.
Common mistake: Calling a project successful solely because it finished on time ignores whether accepted quality, cost and intended business outcomes were achieved.
Official syllabus reference: [1]
44. Project life cycle and continuing justification
A project life cycle provides stages for initiating, planning, delivering, controlling and closing temporary work, though organisations use different labels. Initiation establishes purpose, feasibility and sponsorship. Planning defines scope, resources, dependencies and controls. Delivery creates outputs while control compares performance with expectations and manages exceptions. Closure confirms acceptance and transfers responsibility. Stage reviews should consider continuing business justification, not just whether documents are complete. New evidence can support revision or termination, because spending the remaining budget is justified by future benefits and costs rather than by expenditure already incurred.
Worked example: A customer portal project passes its first review because demand and feasibility appear credible. Later, a major customer changes requirements. The next stage review re-examines remaining costs and benefits instead of approving delivery automatically because development has already begun.
Common mistake: Treating stage approval as permanent business justification overlooks changed assumptions and can encourage further spending simply to defend earlier decisions.
Official syllabus reference: [1]
45. Work breakdown structures and work packages
A work breakdown structure decomposes agreed project scope into manageable deliverables and work packages. The components should collectively cover the required work without unintended overlap. Workstreams organise related effort, while work packages provide a practical basis for ownership, estimating and acceptance. Decomposition describes what must be produced; it does not alone establish activity sequence or dates. Stop at a level that supports control without excessive administration. Clear package boundaries reduce omissions and double counting, particularly where several departments or contractors contribute to the same final deliverable.
Worked example: A website migration is decomposed into content transfer, account migration, integration testing and operational handover. Each package has a defined output and owner, making it easier to identify that redirect preparation was missing before detailed scheduling begins.
Common mistake: Using a departmental task list as proof of complete scope can miss cross-functional deliverables and duplicate work at organisational boundaries.
Official syllabus reference: [1]
46. Gantt charts, milestones and dependency visibility
A Gantt chart places activities against a time axis to show planned dates, duration, overlap and progress. Milestones represent significant events or decision points and normally have zero duration. Dependencies explain why one activity constrains another; displaying bars without those relationships can conceal the consequences of delay. A baseline supports comparison with current forecasts, while updating actual progress helps identify slippage. The chart is a communication tool as well as a schedule view, but visual neatness does not demonstrate feasibility when resource availability, incomplete work or unrealistic assumptions are omitted.
Worked example: A rollout chart shows training scheduled before user acceptance testing finishes. Adding the dependency reveals that a testing delay would require training changes. A readiness milestone then gives the team a clear decision point before committing employees to attendance.
Common mistake: Reading overlapping bars as evidence of feasible parallel work ignores dependencies and the possibility that both activities need the same scarce resource.
Official syllabus reference: [1]
47. Critical-path forward-pass calculations
A forward pass calculates earliest start and finish times through a dependency network. With a time-zero convention, earliest finish equals earliest start plus duration. An activity requiring several predecessors starts no earlier than the latest predecessor finish. The earliest project finish is determined by the longest dependent route through the network, assuming the stated durations and unconstrained resources. Adding parallel branch durations incorrectly treats simultaneous work as sequential. Critical-path analysis identifies schedule constraints under its assumptions; resource shortages or changed dependencies can produce a different achievable completion date.
Worked example: Activity A takes three days, then B and C take six and four days in parallel. D requires both and takes two days. D starts at day nine and finishes at day eleven, because B determines the merge time.
Common mistake: Adding the durations of parallel branches overstates elapsed time and obscures which predecessor actually controls a later activity's earliest start.
Official syllabus reference: [1]
48. Backward passes and total float
A backward pass starts from the required or calculated project finish and determines latest permissible activity dates. Latest start equals latest finish minus duration. Where an activity feeds several successors, its latest finish is the earliest successor latest start. Total float equals latest start minus earliest start, or latest finish minus earliest finish. Zero total float identifies critical activities under the chosen finish assumption. Float belongs to the network logic and can be consumed by upstream delay; it is not automatically spare time that every activity owner can independently use.
Worked example: Two branches finish at days seven and nine before a common successor. The shorter branch can finish two days later without changing the successor's start. Its two days of float disappear if an earlier delay already consumes that flexibility.
Common mistake: Treating each activity's float as independently available contingency double counts flexibility that may be shared across connected activities on the same route.
Official syllabus reference: [1]
49. PERT three-point duration estimates
PERT uses optimistic, most likely and pessimistic duration estimates to represent activity uncertainty. The conventional expected-duration calculation is (optimistic + four times most likely + pessimistic) divided by six. It gives extra weight to the most likely estimate while allowing asymmetric extremes to affect the result. The expected value is neither a promise nor, by itself, a confidence-based completion date. Estimate assumptions should be consistent, and project-level uncertainty can be more complex than adding activity averages because paths, correlations and resource constraints can change which work governs completion.
Worked example: An activity has estimates of two, five and fourteen working days. Its PERT expected duration is six days: (2 + 4 × 5 + 14) ÷ 6. The longer pessimistic tail raises the expectation above the most likely estimate.
Common mistake: Using the simple average of three estimates ignores PERT's weighting, while treating the result as guaranteed confuses expectation with certainty.
Official syllabus reference: [1]
50. Resource smoothing and resource levelling
A logically valid schedule can still be infeasible when activities require the same limited resource. Resource smoothing adjusts work within available float to reduce peaks while preserving the intended completion date where possible. Resource levelling schedules around resource limits and may extend completion when necessary. Check qualifications as well as headcount, because specialists are not always interchangeable. These techniques complement dependency analysis rather than replacing it. After resource adjustments, review the schedule again: the practical controlling sequence may differ from the critical path calculated under an assumption of unlimited resources.
Worked example: Two non-critical tasks both need the same analyst on Monday. Moving one within its float smooths demand without delaying completion. If both tasks were critical and no substitute existed, levelling could require a later finish or an authorised resource change.
Common mistake: Assuming positive float resolves every resource conflict overlooks simultaneous demands, shared flexibility and specialist requirements that may still force a schedule change.
Official syllabus reference: [1]
51. Risk registers separate uncertainty from issues
A project risk is an uncertain event or condition that could affect objectives; an issue is a condition that has occurred and needs action. Useful risk statements connect cause, possible event and consequence. A risk register records ownership, assessment, responses and review information so uncertainty is actively managed. Sources include suppliers, technology, resources, requirements and external conditions. Distinguish threats from opportunities and avoid vague entries such as 'supplier risk' without a mechanism. Once an event occurs, manage its actual consequences while retaining any remaining uncertainty about further effects.
Worked example: Because a specialist supplier has limited production capacity, delivery may slip, delaying installation. The register names an owner and response. When the supplier confirms a missed shipment, the delay becomes an issue while uncertainty about the replacement date remains a risk.
Common mistake: Keeping a realised event only in the risk register can obscure the immediate actions required to manage its actual consequences.
Official syllabus reference: [1]
52. Risk prioritisation and response selection
Risk prioritisation considers likelihood, impact, timing and the organisation's tolerance for consequences. A likelihood–impact matrix supports structured comparison, but ordinal scores are not precise financial quantities. Select responses that address the mechanism: avoid the exposure, reduce likelihood or impact, transfer specified consequences, or accept with suitable preparation. Transfer rarely removes every responsibility or residual exposure. Assign an owner and evaluate response cost against expected protection. Reassess residual and secondary risks, because a response such as using a backup supplier can introduce new integration, quality or contractual uncertainties.
Worked example: A project reduces data-conversion risk through an early trial and reconciliation checks. Insurance might cover some financial consequences but would not restore corrupted records quickly, so the team does not confuse financial transfer with an effective operational recovery capability.
Common mistake: Treating a high matrix score as a precise monetary estimate gives ordinal judgments false accuracy and can distort response priorities.
Official syllabus reference: [1]
53. Scenario planning and actionable contingencies
Scenario planning explores distinct plausible futures and tests how project decisions perform under each. It is useful where probabilities are unreliable or combinations of events matter. Define scenarios with meaningful differences, examine consequences and identify robust actions or contingent responses. A contingency needs a trigger, owner, resources and enough preparation time to work. Scenarios are not predictions and should not be averaged into one assumed future without considering what that loses. Their practical purpose is to expose vulnerabilities and make decisions more responsive when evidence begins to favour a particular outcome.
Worked example: A rollout team considers immediate approval, a one-month approval delay and a longer redesign requirement. It identifies a reusable training package across scenarios and defines the date at which temporary operating arrangements must begin if approval has not arrived.
Common mistake: Producing descriptive future narratives without decision triggers leaves uncertainty discussed but does not establish when anyone should take a different action.
Official syllabus reference: [1]
54. Project software and decision-focused visualisation
Project software can integrate dependencies, resource assignments, budgets, risks and progress information, improving consistency and visibility. Dashboards and visualisations should answer decisions: what is slipping, which dependency matters, where capacity is constrained and what action is needed. Distinguish actual completion from expenditure or elapsed time, and display forecasts alongside baselines where useful. Automation cannot correct inaccurate progress reports or missing relationships. Set data ownership and update conventions so attractive charts reflect reliable information. Tool selection should follow project complexity and coordination needs rather than the number of features available.
Worked example: A dashboard shows spending on plan but highlights that interface testing is only half complete and controls the launch date. Management investigates delivery and remaining effort instead of assuming financial alignment proves the project is progressing according to schedule.
Common mistake: Equating a polished dashboard with reliable control overlooks the definitions, completeness and timeliness of the information feeding its indicators.
Official syllabus reference: [1]
55. Functional, matrix and projectised structures
Functional structures organise people by professional specialism, while projectised structures place substantial authority and resources with project leadership. Matrix arrangements combine functional and project responsibilities, with the balance of authority varying between organisations. Functional homes preserve expertise and career continuity; project focus can improve coordination and speed. Matrix working can access both advantages but creates potential conflict over priorities and performance assessment. Clarify allocation, escalation and decision rights rather than assuming a project title grants control over every contributor. The best structure depends on project demands and the surrounding organisation.
Worked example: An engineer reports to an engineering head for standards and to a project manager for delivery priorities. A written allocation agreement and escalation route help resolve competing assignments, making the matrix workable without pretending either manager has unlimited authority.
Common mistake: Assuming a project manager controls all assigned staff overlooks the functional authority and negotiated resource commitments common in matrix organisations.
Official syllabus reference: [1]
56. Sponsor, project manager and RACI accountability
The sponsor provides business ownership, support and direction, while the project manager integrates planning and delivery within delegated authority. Specialists produce and assure technical work, and operational owners prepare to use the outputs. A RACI matrix distinguishes who performs work, who is answerable for the decision or result, who is consulted and who is informed. Assignments should be explicit and workable, usually with one clearly accountable owner for a decision. RACI clarifies participation but does not replace competence, capacity, escalation arrangements or the governance defining who can approve material changes.
Worked example: For a data migration, technicians perform the conversion, the migration lead is accountable for completion, business users are consulted on validation and support teams are informed of timing. The sponsor remains responsible for business direction rather than approving every technical step.
Common mistake: Listing several people as jointly accountable without a decision rule can conceal ownership and delay action when the project needs a clear choice.
Official syllabus reference: [1]
57. Temporary teams, mobilisation and planned release
Project teams are temporary combinations of people whose availability and incentives may remain tied to permanent functions. Mobilisation secures actual commitments, access, role clarity and shared understanding before assuming capacity exists. As work progresses, knowledge must be captured so departures do not create avoidable dependency. Planned release coordinates remaining obligations, handover and return to operational roles. Motivation benefits from visible purpose, recognition and fair workload allocation, especially when contributors divide time between projects and routine work. Effective project leadership treats entry and exit as managed transitions rather than administrative afterthoughts.
Worked example: A testing specialist joins for six weeks, so the manager confirms availability, access and deliverables before scheduling work. The specialist pairs with an operational colleague and records test knowledge, allowing release without leaving the support team dependent on an unavailable contractor.
Common mistake: Assuming a named team member is fully available ignores competing commitments and can create a schedule that exists only on paper.
Official syllabus reference: [1]
58. Power–interest analysis and stakeholder engagement
Power–interest analysis helps tailor project engagement according to stakeholders' influence and concern about the outcome. High-power, high-interest stakeholders usually need close engagement; other groups need suitable information, consultation or assurance. The matrix is a starting point rather than a licence to ignore affected people with little power. Identify expectations, likely concerns and the decisions each group can influence. Reassess positions as the project changes, and distinguish communication volume from engagement quality. Useful engagement tests whether stakeholders understand implications and can contribute relevant information before decisions become difficult to reverse.
Worked example: A system project involves a powerful compliance director and a large user group with limited formal authority. The director receives decision-focused assurance, while users test workflows and explain operational barriers, preventing the team from confusing low authority with low implementation relevance.
Common mistake: Using low power as a reason to exclude users overlooks the information and adoption support they may contribute to successful delivery.
Official syllabus reference: [1]
59. Baseline control and evaluated change requests
A baseline is an approved reference for assessing project performance, not an assumption that change is impossible. A change request should identify the proposed alteration, reason and effects on scope, time, cost, quality, resources, risks and benefits. The authorised decision may approve, reject, defer or request further analysis. Approved changes need updated plans and communication so teams work from consistent information. Small additions can accumulate into significant scope growth, so apply proportionate control. Rebaselining should preserve visibility of why expectations changed rather than erase evidence of earlier variance.
Worked example: A sponsor requests an extra dashboard. Analysis identifies development, data and testing effort before approval. Once accepted, the team updates scope and schedule references and informs users, keeping the new commitment visible instead of informally adding work to existing expectations.
Common mistake: Quietly absorbing small additions hides cumulative scope growth and prevents informed decisions about the resources or trade-offs needed to deliver them.
Official syllabus reference: [1]
60. Closure, operational handover and benefits ownership
Project closure confirms that outputs are accepted, outstanding obligations are assigned, records and learning are retained, and temporary resources can be released. Operational handover needs ownership, support information, training and arrangements for unresolved defects. Benefits may arise after the project team disbands, so name an ongoing owner, measures and review timing. Distinguish delivering an output from realising the intended outcome: a functioning system does not automatically produce productivity gains. Closure can therefore be appropriate before every benefit is realised, provided responsibility and evidence requirements continue beyond the temporary project organisation.
Worked example: A purchasing system is accepted after testing, but expected cycle-time savings require changed working practices. Operations takes ownership of training and monthly cycle-time measures, while the project closes with support documentation and named owners for remaining minor defects.
Common mistake: Assuming system acceptance proves benefits realisation confuses delivery of an enabling output with the operational changes needed to achieve the business outcome.
Official syllabus reference: [1]