Skip to main content

Leadership: How to Set Direction and Priorities

· 42 min read
AI Playbook author

Leadership is not simply the ability to manage people, approve work, attend meetings, or communicate confidently. One of the most important responsibilities of a leader is to create direction.

Direction tells people what the organisation is trying to achieve, why the goal matters, which problems deserve attention, what should be done first, what should not be done, how success will be measured, and who is accountable for delivering the outcome.

Without clear direction, even highly capable teams can become busy without becoming effective. They may complete projects, build technology, produce reports, attend governance meetings, and deliver presentations while making little progress against the organisation's most important objectives.

Strong leaders prevent this by continuously ensuring that people, funding, technology, leadership attention, and specialist capability are focused on the highest-value problems.

This is especially important in a large organisation such as a professional-services firm, where different business units may compete for the same Data and AI resources. Audit, Tax, Deals, Consulting, Risk, Finance, Human Resources, Marketing, Operations, Technology, and other internal functions may all have legitimate priorities.

The leader's role is not to satisfy every request. The leader's role is to make disciplined choices.

Setting direction and priorities therefore requires a combination of strategic thinking, commercial judgement, client understanding, data and technology awareness, risk judgement, resource allocation, stakeholder management, communication, governance, and the courage to stop low-value work.

The quality of these decisions determines whether the organisation's strategy becomes real or remains a collection of intentions.


1. What setting direction really means

Setting direction means translating broad organisational ambition into a small number of clear, actionable priorities.

An organisational strategy may contain statements such as:

  • Become an AI-enabled firm.
  • Improve client experience.
  • Increase productivity.
  • Grow revenue from Data and AI services.
  • Strengthen trust and quality.
  • Modernise internal operations.
  • Build industry-leading capabilities.
  • Improve employee experience.
  • Develop responsible and secure AI.

These are useful ambitions, but they are not yet operational directions.

A leader must translate them into choices such as:

  • Which business areas will receive investment first?
  • Which client problems will the firm prioritise?
  • Which capabilities should be built centrally?
  • Which capabilities should be purchased from technology partners?
  • Which solutions should be reused across service lines?
  • Which initiatives must meet a higher governance threshold?
  • Which projects should be accelerated?
  • Which experiments should remain small?
  • Which programmes should be stopped?
  • Which outcomes must be achieved this quarter or year?

For example, "become an AI-enabled firm" is too broad to guide daily decisions.

A clearer direction might be:

Over the next 12 months, we will prioritise reusable AI capabilities that improve professional productivity, strengthen client delivery, and create measurable commercial value. We will focus first on knowledge-intensive workflows with strong executive sponsorship, accessible data, repeatable demand, and manageable risk.

This statement begins to guide action. It tells teams that not every possible AI use case is equally important.

A stronger version might also identify priority themes:

  1. AI-assisted client delivery.
  2. Firmwide knowledge search and retrieval.
  3. Automated document analysis.
  4. Risk and compliance intelligence.
  5. Client-facing industry solutions.
  6. Reusable AI platforms and governance controls.

The purpose of direction is to create alignment and reduce confusion.


2. Direction is a continuous leadership activity

Direction is not set once during an annual strategy workshop and then left unchanged.

Every day, the leader checks whether teams are working on the most important problems.

This involves constantly comparing strategic priorities, current portfolio activity, emerging client demand, available capacity, delivery performance, commercial results, technology developments, regulatory changes, operational risks, and organisational dependencies.

A priority that was correct six months ago may no longer be correct today.

For example:

  • A new regulation may create urgent compliance requirements.
  • A major client may request a capability that could become a repeatable market offering.
  • A technology vendor may release a capability that removes the need to build internally.
  • A project may fail to produce measurable value.
  • A competitor may introduce a new service.
  • A data-access problem may make a planned initiative temporarily impractical.
  • A successful pilot may need rapid funding to scale.
  • A high-profile AI incident may require stronger governance controls.

Leadership direction must therefore remain stable enough to create confidence but flexible enough to respond to evidence.

The leader should not change priorities impulsively. However, the leader must also avoid protecting outdated decisions simply because time or money has already been invested.


3. The leader's core responsibilities

A leader setting direction and priorities normally performs six core responsibilities:

  1. Understanding the strategic context.
  2. Defining the most important outcomes.
  3. Evaluating and prioritising initiatives.
  4. Allocating resources.
  5. Communicating choices.
  6. Reviewing progress and adjusting direction.

Each responsibility requires a different form of judgement.


4. Understand the strategic context

Before deciding what teams should work on, the leader must understand the organisation's strategic environment.

This includes understanding the firm's regional strategy, global organisational priorities, service-line growth plans, industry trends, client demand, revenue and margin objectives, risk and regulatory expectations, current technology capability, data maturity, workforce capability, competitive pressure, partner and alliance opportunities, existing commitments, delivery capacity, and financial constraints.

A leader cannot set useful priorities in isolation from these factors.

4.1 Understand the regional strategy

The leader should be able to explain how Data and AI supports the wider regional strategy.

For example, if the regional strategy focuses on growth in financial services, expansion of managed services, improvement in audit quality, increased productivity, development of technology alliances, or growth in digital consulting, then the Data and AI portfolio should visibly support those priorities.

A portfolio that is technically impressive but disconnected from regional growth plans is unlikely to receive sustained executive support.

The leader should ask:

  • Which regional objectives can Data and AI materially accelerate?
  • Which objectives depend on improved data or automation?
  • Where can AI create differentiation?
  • Where can AI reduce cost or improve quality?
  • Which industries are strategically important?
  • Which services could become more scalable through reusable technology?
  • Which priorities require central capability rather than local experimentation?

4.2 Understand the business model

The leader must understand how the organisation makes money.

In a professional-services firm, value may be created through increasing revenue, increasing win rates, improving delivery margins, reducing delivery effort, improving utilisation, increasing engagement size, creating recurring managed-service revenue, reducing risk, improving quality, increasing client retention, enabling premium pricing, or reusing intellectual property across clients.

This understanding allows the leader to challenge vague claims about value.

For example, a team may say:

This AI tool will save consultants a significant amount of time.

The leader should ask:

  • How much time?
  • Across how many people?
  • Does the saved time reduce cost, increase capacity, or improve quality?
  • Can the capacity be converted into additional revenue?
  • Will people actually use the tool?
  • Is the workflow frequent enough to matter?
  • What is the cost of developing, operating, securing, and supporting it?
  • Does the benefit exceed the total cost?

Without commercial understanding, a leader may approve initiatives that create technical output but no meaningful organisational value.

4.3 Understand client needs

Direction should be grounded in real client problems.

The leader should maintain regular contact with client partners, account leaders, industry leaders, sales teams, delivery teams, product leaders, client executives, risk stakeholders, and technology partners.

This helps the leader distinguish between genuine market demand and internal enthusiasm.

Important questions include:

  • What problems are clients repeatedly discussing?
  • Which problems are clients willing to pay to solve?
  • Where are clients struggling to move from experimentation to production?
  • Which sectors face urgent regulatory or operational pressure?
  • Which capabilities are competitors offering?
  • What concerns prevent clients from adopting AI?
  • Where could the firm combine industry expertise, data, technology, risk, and transformation capability?
  • Which client problems appear across multiple industries?
  • Which use cases can become reusable offerings?

The best direction often emerges from repeated patterns rather than isolated requests.

For example, if multiple clients need help with AI governance, enterprise knowledge assistants, regulatory document analysis, customer-service automation, model risk management, data modernisation, or AI operating models, then these may deserve investment as strategic capabilities rather than being treated as separate client projects.


5. Define outcomes before initiatives

Weak planning starts with projects.

Strong leadership starts with outcomes.

A project is an activity. An outcome is a measurable change.

Examples of activities include:

  • Build a chatbot.
  • Create a data platform.
  • Implement a vector database.
  • Launch an AI academy.
  • Develop a dashboard.
  • Conduct a proof of concept.
  • Deploy an agentic workflow.

Examples of outcomes include:

  • Reduce the average time required to review regulatory documents by 40%.
  • Increase proposal win rates by 5%.
  • Reduce time spent searching for internal knowledge by 30 minutes per employee per week.
  • Generate £10 million in qualified AI opportunities.
  • Reduce manual audit-testing effort while maintaining or improving quality.
  • Increase reusable solution adoption across five service lines.
  • Ensure all high-risk AI systems complete required governance assessments before production.
  • Reduce the time required to onboard a new client from four weeks to two weeks.

Outcomes create accountability.

The leader should insist that every major initiative is connected to a defined problem, a target user or client, a measurable outcome, an accountable owner, a delivery timeframe, a value hypothesis, a risk assessment, and a clear decision point.

A project should not be approved simply because the technology appears promising.


6. Start with the business problem, not the technology

One of the most common leadership challenges in Data and AI is that teams begin with technology.

They may say:

  • We should build an AI agent.
  • We should use generative AI.
  • We need a knowledge graph.
  • We should implement a large language model.
  • We need a new data lake.
  • We should create a digital twin.
  • We need to use machine learning.
  • We should build a chatbot.

These statements describe technologies, not problems.

The leader should redirect the discussion by asking:

  • What business or client problem are we solving?
  • Who experiences the problem?
  • How is the problem managed today?
  • How often does it occur?
  • What is the cost of the current process?
  • What causes the problem?
  • What would improve if the problem were solved?
  • What evidence shows that the problem is important?
  • Why is the current solution inadequate?
  • What is the simplest intervention that could improve the outcome?

The correct answer may not require AI.

The problem might be solved by improving the process, changing a policy, integrating existing systems, improving data quality, providing better training, implementing workflow automation, using rules-based logic, purchasing an existing product, creating a standard operating procedure, clarifying accountability, or removing unnecessary approval steps.

Strong leaders do not measure success by how much AI is used. They measure success by whether important outcomes improve.


7. The core questions leaders should ask

A disciplined leader repeatedly asks a small number of powerful questions.

7.1 What business or client problem are we solving?

This question prevents technology-led activity.

A strong answer should explain the current situation, the affected user or client, the pain or opportunity, the root cause, the business impact, the urgency, and the scale of the problem.

Weak answer:

We want to use generative AI to improve productivity.

Strong answer:

Approximately 1,500 professionals spend an average of 45 minutes per engagement searching across fragmented policy, methodology, and sector documents. This delays delivery, increases duplicated work, and creates a risk that teams use outdated guidance.

The second answer makes the problem visible and measurable.

7.2 Who owns the outcome?

Every important priority needs one accountable owner.

Many initiatives fail because responsibility is distributed across committees.

A project may involve business sponsors, technology teams, data owners, risk teams, product managers, delivery teams, vendors, and transformation teams. However, one individual must remain accountable for the outcome.

The leader should ask:

  • Who has the authority to make decisions?
  • Who is responsible for achieving the business result?
  • Who can resolve cross-functional blockers?
  • Who owns adoption after launch?
  • Who owns the budget?
  • Who accepts the operational risk?
  • Who reports progress to leadership?

The technology lead should not automatically own the business outcome.

For example, if an AI system is intended to improve Tax engagement delivery, the accountable owner should usually be a business leader from Tax rather than only an engineering manager.

7.3 What measurable value will this create?

Value must be specific.

Possible value categories include:

Financial value — revenue growth, margin improvement, cost reduction, reduced external spend, increased utilisation, increased sales conversion, reduced delivery leakage, faster cash collection.

Client value — faster response, better experience, improved quality, better insight, lower risk, greater transparency, reduced cost, improved compliance.

Employee value — reduced administrative burden, faster access to information, better decision support, increased capability, improved employee experience, reduced repetitive work.

Risk value — reduced regulatory risk, improved auditability, better control effectiveness, reduced model risk, improved data protection, better traceability, improved consistency.

Strategic value — new market entry, differentiated capability, intellectual-property creation, improved alliance position, reusable platform capability, stronger client relationships, improved reputation.

The leader should ensure that value is quantified wherever possible.

7.4 Is AI genuinely necessary?

AI introduces complexity. It may require specialist skills, model evaluation, security and privacy controls, human oversight, monitoring, change management, ongoing model updates, vendor management, explainability, regulatory assessment, additional infrastructure, and higher operational costs.

AI should therefore be used where it offers a meaningful advantage over simpler approaches.

The leader should ask:

  • Could a standard workflow solve the problem?
  • Could deterministic automation solve it?
  • Could existing software already provide the capability?
  • Does the problem involve uncertainty, complex language, prediction, pattern recognition, or unstructured data?
  • Does AI materially improve speed, quality, cost, scale, or user experience?
  • Is the additional risk justified?
  • Can the output be adequately evaluated?
  • Is human review required?
  • What happens when the model is wrong?

The purpose is not to discourage AI. The purpose is to use it responsibly and economically.

7.5 Can we reuse an existing capability?

Large organisations often build the same capability multiple times.

Different teams may independently create document-ingestion pipelines, retrieval-augmented generation platforms, AI governance questionnaires, prompt-management tools, model-evaluation frameworks, redaction services, identity controls, logging and monitoring, client knowledge assistants, data-quality frameworks, and Responsible AI templates.

Duplication wastes money and creates operational inconsistency.

The leader should ask:

  • Has another team solved a similar problem?
  • Can we use an existing platform?
  • Can we adapt a previous solution?
  • Can this be built as a reusable component?
  • Can multiple service lines share the capability?
  • Is there an approved vendor product?
  • Can a global asset be reused regionally?
  • Can a regional capability be offered globally?
  • Are we creating unnecessary technical variation?

Reusability should be a standard prioritisation criterion.

7.6 What should we stop doing?

This may be the most important leadership question.

Organisations usually have more ideas than capacity. New priorities are often added without removing old ones.

This creates overloaded teams, slow delivery, fragmented attention, repeated delays, poor quality, employee frustration, unclear accountability, excessive work in progress, and projects that remain permanently unfinished.

A leader must create space for important work by stopping less valuable work.

The leader should ask:

  • Which initiatives no longer support the strategy?
  • Which projects have weak sponsorship?
  • Which pilots have failed to demonstrate value?
  • Which activities are duplicated?
  • Which products have low adoption?
  • Which projects cannot access the required data?
  • Which investments have become unnecessary?
  • Which work can be paused?
  • Which service can be retired?
  • Which meeting or report no longer supports a decision?

Stopping work is not failure. Continuing low-value work because of sunk cost is a greater failure.


8. Reviewing the Data and AI portfolio

A Data and AI portfolio is the complete collection of initiatives, products, platforms, experiments, client offerings, capability-development programmes, and governance activities currently receiving organisational resources.

The leader should review the portfolio regularly rather than managing each project in isolation.

A portfolio review should answer:

  • What work is currently active?
  • Why was it approved?
  • What stage is it in?
  • What value is expected?
  • What value has been delivered?
  • What is the delivery confidence?
  • What risk is involved?
  • What dependencies exist?
  • What resources are being used?
  • What decisions are required?
  • Should the work start, continue, scale, pause, or stop?

8.1 Portfolio categories

The portfolio can be grouped into categories such as:

Client-facing growth initiatives — create revenue, strengthen client relationships, or develop market offerings (AI transformation services, industry-specific AI products, AI governance advisory, data modernisation services, managed AI services, client-facing analytics platforms).

Internal productivity initiatives — improve the efficiency of employees or business processes (knowledge assistants, proposal automation, document summarisation, research support, internal service-desk automation, finance and HR automation).

Quality and risk initiatives — strengthen controls, quality, compliance, and trust (AI model governance, data lineage, automated control monitoring, regulatory intelligence, audit-quality analytics, privacy and security controls).

Foundational platforms — enable multiple use cases (enterprise AI platform, data platform, identity and access management, model gateway, evaluation framework, observability platform, data catalogue, reusable integration services).

Capability-building initiatives — improve the organisation's skills and delivery maturity (AI academies, leadership education, engineering standards, communities of practice, certification programmes, delivery playbooks, product-management training).

Research and experimentation — explore emerging opportunities (agentic AI, multimodal models, synthetic data, small language models, on-device AI, quantum machine learning, advanced simulation).

Each category serves a different purpose and should be evaluated differently.

A foundational platform may not directly generate immediate revenue, but it may reduce the cost and risk of dozens of future use cases. An experiment may have uncertain value but be justified if learning is strategically important.


9. Decide what should start, continue, scale, pause, or stop

Every initiative should receive an explicit portfolio decision.

9.1 Start

An initiative should start when the problem is important, the outcome supports strategy, there is a credible sponsor, the value hypothesis is clear, required data is accessible, delivery capability exists, risk appears manageable, there is a clear first milestone, the proposed solution is proportionate, and the initiative has sufficient priority relative to alternatives.

Starting does not always mean committing to full delivery. It may mean approving discovery, a design phase, a limited proof of value, a controlled pilot, a technical feasibility assessment, or a client co-creation exercise.

9.2 Continue

An initiative should continue when it remains strategically relevant, progress is credible, the value case remains valid, risks are controlled, dependencies are manageable, the sponsor remains engaged, and evidence supports further investment.

Continuing should not be automatic. Every review should confirm that the original assumptions still hold.

9.3 Scale

An initiative should scale when the pilot has demonstrated measurable value, users are adopting the capability, the solution is reliable, the operating model is defined, security and governance controls are complete, support arrangements exist, unit economics are acceptable, demand exists across multiple teams or clients, technical architecture can support larger volumes, and funding exists for production operation.

Scaling too early can turn a promising experiment into an expensive failure.

The leader should distinguish between a successful demonstration, a successful pilot, a production-ready solution, and a scalable organisational capability. These are not the same.

9.4 Pause

An initiative should be paused when a critical dependency is unresolved, data is unavailable, the sponsor is changing, a strategic decision is pending, a vendor capability may replace planned development, risk questions require investigation, capacity is needed for a higher-priority initiative, or the initiative may become valuable later.

A pause should include the reason for pausing, the conditions required to restart, the owner, a review date, and the treatment of the existing team and assets.

9.5 Stop

An initiative should stop when the problem is no longer important, the value case is weak, adoption is consistently low, delivery costs exceed likely benefits, risk is unacceptable, the initiative duplicates another capability, technology has made the solution obsolete, the sponsor is absent, the team cannot demonstrate progress, the work does not support current strategy, the initiative cannot scale, or evidence disproves the original assumptions.

A leader should communicate stopping decisions respectfully and clearly.

The message should explain what was learned, why the decision was made, what will happen to the assets, how people will be reassigned, whether the idea may be reconsidered later, and how the decision protects organisational focus.


10. A practical prioritisation framework

Leaders need a consistent way to compare initiatives.

A practical framework can score each initiative against the following dimensions:

  1. Strategic alignment.
  2. Business value.
  3. Client value.
  4. Urgency.
  5. Reusability.
  6. Feasibility.
  7. Data readiness.
  8. Sponsorship.
  9. Risk.
  10. Cost.
  11. Time to value.
  12. Organisational readiness.

10.1 Strategic alignment

  • Does the initiative support a declared regional priority?
  • Does it strengthen an important service line or industry?
  • Does it contribute to growth, quality, trust, or productivity?
  • Would senior leadership recognise this as strategically important?
  • What strategic objective would be affected if the initiative did not proceed?

10.2 Business value

  • What financial value is expected?
  • How will the value be measured?
  • Is the value direct or indirect?
  • How confident are we in the assumptions?
  • When will the value appear?
  • Is the value large enough to justify leadership attention?

10.3 Client value

  • Does the initiative solve a real client problem?
  • Is there evidence of willingness to pay?
  • Does it improve the client experience?
  • Can it strengthen an existing relationship?
  • Can it create differentiation?
  • Is the need present across multiple clients?

10.4 Urgency

  • Is there a regulatory deadline?
  • Is there a contractual commitment?
  • Is there an immediate client opportunity?
  • Is the organisation currently exposed to risk?
  • Will delaying reduce the value?
  • Is a competitor moving quickly?
  • Is there a limited market window?

10.5 Reusability

  • Can the capability support multiple use cases?
  • Can it be reused across service lines?
  • Can it be used across industries?
  • Can it be reused across regions?
  • Does it create intellectual property?
  • Does it reduce future delivery effort?

10.6 Feasibility

  • Is the technology sufficiently mature?
  • Do the required skills exist?
  • Can the solution integrate with current systems?
  • Is the delivery timeframe realistic?
  • Are key dependencies understood?
  • Can the output be evaluated?

10.7 Data readiness

  • Does the required data exist?
  • Is the data accessible?
  • Is the data accurate?
  • Is the data legally usable?
  • Is ownership clear?
  • Is data lineage available?
  • Are there privacy or residency constraints?
  • Is the volume sufficient?

10.8 Sponsorship

  • Is there a senior business sponsor?
  • Does the sponsor own the affected process?
  • Will the sponsor drive adoption?
  • Can the sponsor resolve organisational barriers?
  • Is the sponsor willing to fund the initiative?
  • Is the sponsor accountable for benefits?

10.9 Risk

  • What happens if the solution is wrong?
  • Does it affect regulated activity?
  • Does it use confidential or personal data?
  • Could it create legal, ethical, reputational, or operational harm?
  • Is human oversight possible?
  • Are controls proportionate?
  • Is the residual risk acceptable?

10.10 Cost

  • What is the full lifecycle cost?
  • What is the implementation cost?
  • What are the cloud and model costs?
  • What are the licensing costs?
  • What support is required?
  • What is the change-management cost?
  • What is the opportunity cost of using scarce specialists?

10.11 Time to value

  • How quickly can the first measurable benefit be achieved?
  • Can the initiative be delivered incrementally?
  • Is there a useful minimum viable product?
  • Are there long procurement or integration delays?
  • Can learning be generated quickly?

10.12 Organisational readiness

  • Are users ready to change their behaviour?
  • Is the process sufficiently standardised?
  • Is leadership aligned?
  • Is training available?
  • Is the operating model clear?
  • Does the organisation have capacity to absorb the change?

11. Weighted scoring

The leader can use weighted scoring to compare initiatives.

CriterionWeight
Strategic alignment15%
Business and client value20%
Urgency10%
Reusability10%
Feasibility10%
Data readiness10%
Sponsorship10%
Risk5%
Cost efficiency5%
Time to value5%

Each initiative may be scored from 1 to 5.

However, scoring should support judgement rather than replace it.

A project with a high numerical score may still be rejected because it creates unacceptable regulatory risk, depends on unavailable data, conflicts with another strategic decision, requires scarce expertise needed elsewhere, creates excessive concentration with one vendor, or cannot be operated securely.

The leader should use both analytical scoring and executive judgement.


12. Resolve competing priorities across business units

In a large firm, every service line believes its requirements are important.

Audit may prioritise quality, compliance, evidence, consistency, regulatory confidence, and efficiency of audit procedures.

Tax may prioritise regulatory intelligence, document analysis, tax research, compliance automation, client advisory, and knowledge management.

Deals may prioritise speed, due diligence, market intelligence, financial analysis, document review, and value-creation opportunities.

Consulting may prioritise client delivery, new propositions, industry solutions, transformation programmes, technology implementation, and managed services.

Internal functions may prioritise cost reduction, employee experience, finance automation, recruitment, learning, internal support, and knowledge access.

The leader must make choices across these competing demands.

12.1 Do not allocate resources equally

Equal allocation may appear fair, but it is often strategically weak.

Different areas may have different growth potential, regulatory urgency, readiness, value opportunities, levels of sponsorship, and reuse potential.

Resources should be allocated according to strategic importance and expected value, not organisational symmetry.

12.2 Use shared decision criteria

Every service line should be evaluated using common criteria. This reduces political decision-making.

The leader can explain:

All initiatives will be assessed against strategic alignment, measurable value, urgency, feasibility, reusability, sponsorship, data readiness, and risk.

This does not eliminate disagreement, but it makes decisions more transparent.

12.3 Separate mandatory work from discretionary work

Some work is mandatory: regulatory requirements, security remediation, legal commitments, contractual obligations, critical platform maintenance, and high-severity risk treatment.

Other work is discretionary: growth experiments, new productivity tools, emerging technology research, and optional feature development.

Mandatory work should be identified first. Remaining capacity can then be allocated to strategic growth and improvement.

12.4 Protect enterprise priorities

Business units may favour local solutions that optimise their own performance.

The leader must protect enterprise interests.

For example, five service lines may request separate knowledge assistants. It may be better to invest in one common AI platform, shared security controls, shared document ingestion, shared identity management, shared evaluation, and service-line-specific user experiences.

The leader should encourage local innovation while preventing unnecessary duplication.

12.5 Escalate only true trade-offs

Not every disagreement requires executive escalation.

Teams should resolve trade-offs using agreed principles wherever possible.

Escalation is appropriate when two initiatives need the same scarce resource, strategic objectives conflict, risk ownership is unclear, funding authority is exceeded, business units cannot agree on an enterprise standard, a decision affects multiple executive stakeholders, or the organisation must accept significant residual risk.

A good escalation includes the decision required, the available options, the benefits and risks of each option, the recommendation, the consequence of delay, and the proposed owner.


13. Allocate leadership attention

Funding is not the only scarce resource. Leadership attention is also limited.

Senior leaders can only personally sponsor a small number of priorities effectively.

The leader should decide which initiatives require direct executive involvement, which can be delegated, which decisions need rapid escalation, which stakeholders require active alignment, which programmes are strategically sensitive, which projects may affect reputation or regulation, which initiatives need external visibility, and which teams require coaching or intervention.

Leadership attention should be concentrated where it has the greatest leverage.

High-attention initiatives may include major client opportunities, firmwide transformation, high-risk AI use cases, strategic platforms, cross-service-line programmes, programmes facing serious delivery problems, and capabilities with major commercial potential.

The leader should avoid spending excessive time on small operational issues that should be resolved by empowered teams.


14. Allocate funding

Funding decisions reveal the organisation's real priorities.

A strategy without aligned funding is only a statement of intent.

Funding should normally be divided across strategic platforms, client growth, internal productivity, risk and compliance, capability development, research and experimentation, and product operation and maintenance.

The leader must avoid allocating all funding to new projects while neglecting maintenance, monitoring, security, user support, model evaluation, data quality, change management, product ownership, and technical debt.

A useful funding model may distinguish between:

EnvelopePurpose
RunOperate existing platforms and products
ImproveEnhance quality, reliability, adoption, or efficiency
GrowCreate new commercial or strategic value
ExploreControlled experimentation

The leader should also reserve a limited amount of capacity for emerging priorities. Without contingency, every urgent opportunity disrupts existing commitments.


15. Allocate specialist resources

Data and AI work often depends on scarce specialists such as AI architects, machine-learning engineers, data engineers, data scientists, cloud architects, cybersecurity specialists, model-risk experts, privacy professionals, Responsible AI specialists, product managers, industry subject-matter experts, user-experience designers, change managers, and commercial specialists.

The leader should not allow every project to request a complete dedicated team.

Instead, resources can be organised through shared platforms, expert pools, communities of practice, architecture review boards, reusable delivery patterns, temporary specialist assignments, standard solution components, and strategic vendor partnerships.

The leader should understand where bottlenecks exist—for example many projects waiting for security review, overloaded data engineers, weak product management, AI governance dependent on one specialist, or repeatedly delayed cloud architecture decisions.

Priority setting should include removing these systemic bottlenecks.


16. Create a clear priority hierarchy

A large organisation needs multiple levels of priorities.

LevelContentExamples
1. Strategic outcomesFew highest-level organisational objectivesGrow Data and AI revenue; improve delivery quality; increase productivity; strengthen trust; build reusable AI capability
2. Strategic themesRelated areas of activityAI-enabled professional services; industry AI solutions; data modernisation; Responsible AI; workforce capability; enterprise AI platforms
3. Portfolio prioritiesSpecific programmes or capability areasEnterprise knowledge assistant; AI governance service; document intelligence platform
4. Quarterly outcomesWhat must be achieved in the next periodLaunch two client pilots; complete platform security approval; train 300 practitioners
5. Team commitmentsDeliverables owned by individual teamsSprint and release commitments traced to quarterly outcomes

The hierarchy ensures that daily work can be traced to strategic intent.


17. Translate strategy into quarterly priorities

Annual strategy can feel too distant for teams. Quarterly priorities create focus.

A good quarterly priority should include the outcome, the owner, the target measure, the deadline, the strategic reason, the major dependencies, and the decision required at the end.

Example:

By the end of Q2, demonstrate that the enterprise knowledge assistant can reduce average information-search time by at least 25% across two service lines, while meeting security, privacy, accuracy, and adoption thresholds. The Chief Knowledge Officer owns the business outcome, supported by the Data and AI platform team.

This is stronger than:

Build a knowledge assistant in Q2.

The first statement defines value, scope, quality, accountability, and decision criteria.


18. Establish decision rights

Priority conflicts often arise because decision rights are unclear.

The organisation should define who has authority to decide which initiatives enter the portfolio, which receive funding, which platforms become standards, which risks can be accepted, which products can go live, which initiatives should stop, which exceptions are permitted, and which resources can be reassigned.

A possible structure may include:

RoleOwns
Executive committeeStrategic priorities and major investment decisions
Data and AI portfolio boardPrioritises initiatives, tracks value, manages cross-functional dependencies
Business sponsorBusiness outcome and adoption
Product ownerProduct roadmap and user value
Technology ownerEngineering quality, architecture, and operation
Risk ownerAcceptance of business and operational risk
Data ownerData quality, access, and permitted use

Clear decision rights reduce delay and committee dependence.


19. Communicate priorities clearly

A priority that is not understood is not a priority.

Leaders must communicate priorities repeatedly and consistently.

People should understand what matters most, why it matters, how priorities were selected, what is changing, what remains unchanged, what will not be pursued, how their work contributes, and how decisions will be reviewed.

19.1 Use simple language

Avoid vague statements such as "accelerate AI transformation," "drive digital innovation," "unlock synergies," "enable a data-driven culture," "leverage strategic capabilities," or "deliver AI at scale."

Translate them into practical meaning.

For example:

During the next six months, we will prioritise three areas: client-facing AI governance services, reusable document-intelligence capabilities, and internal knowledge search. Other new AI proposals will require evidence that they are more valuable or urgent than these priorities.

19.2 Explain the trade-offs

People are more likely to accept decisions when they understand the trade-offs.

For example:

We are delaying the local chatbot programme because the enterprise knowledge platform can meet most of the same need and will reduce duplicated cost, security review, and support effort.

19.3 Repeat the direction

Leaders often assume that saying something once is enough.

Direction should be repeated through leadership meetings, portfolio reviews, town halls, written updates, team objectives, funding decisions, hiring decisions, performance discussions, project approvals, and recognition and reward.

Consistency between words and resource decisions is essential.


20. Create a regular leadership cadence

Direction becomes real through operating rhythm.

Daily

Review urgent delivery or risk issues; check whether major decisions are blocked; speak with key sponsors; resolve resource conflicts; challenge emerging work that lacks alignment; reconfirm immediate priorities with the leadership team.

The purpose is not to micromanage delivery. It is to prevent teams from losing focus.

Weekly

Cover progress against top priorities, decisions required, emerging risks, new client opportunities, resource constraints, cross-team dependencies, changes in strategic context, and initiatives requiring intervention.

The meeting should focus on decisions rather than status reporting.

Monthly

Cover portfolio performance, financial performance, benefits realisation, adoption, risk status, capacity, new proposals, start/continue/scale/pause/stop decisions, and strategic balance across the portfolio.

Quarterly

Assess whether strategic assumptions remain valid, whether priorities should change, which initiatives delivered outcomes, which capabilities should scale, which work should stop, how funding should be reallocated, and what the next quarterly outcomes should be.

Annually

Define strategic direction, investment themes, capability priorities, target outcomes, talent requirements, platform roadmap, governance expectations, financial envelope, and measures of success.

Annual planning should provide direction, not create an inflexible list of projects.


21. Design portfolio meetings around decisions

Many portfolio meetings become lengthy status updates.

A strong meeting should be organised around decisions.

Each initiative should present:

  1. The outcome being pursued.
  2. Current evidence.
  3. Progress against milestones.
  4. Value delivered.
  5. Key risks.
  6. Required decision.
  7. Management recommendation.

Possible decisions include approve discovery, approve pilot, approve production funding, continue with conditions, reallocate resources, escalate a risk, merge with another initiative, pause, stop, or scale.

Detailed project reporting can be provided separately. Executive meeting time should focus on matters requiring judgement.


22. Use evidence, not optimism

Teams naturally become attached to their projects. They may highlight technical progress, positive user comments, successful demonstrations, interesting features, and future potential.

The leader should ask for evidence: adoption data, usage frequency, time saved, error rates, user satisfaction, revenue generated, cost avoided, model performance, operational incidents, sales pipeline, conversion rates, delivery margin, quality improvement, risk reduction, and client willingness to pay.

The leader should distinguish between interest and adoption; adoption and value; technical success and business success; a demonstration and a scalable product; a pilot sponsor and a long-term owner; potential value and realised value.


23. Define clear success and exit criteria

Every initiative should have success criteria. It should also have exit criteria.

Success criteria may include minimum adoption, minimum financial benefit, maximum error rate, required user satisfaction, required security approval, required model performance, required number of paying clients, required delivery margin, and required time saving.

Exit criteria may include no sponsor after a defined period, data cannot be accessed, adoption remains below target, cost exceeds an agreed threshold, risk cannot be reduced, technical performance remains inadequate, a better existing solution becomes available, or commercial demand is not demonstrated.

Exit criteria make stopping decisions more objective.


24. Balance short-term and long-term priorities

Leaders must balance immediate delivery with future capability.

Too much focus on short-term results may create fragmented solutions, technical debt, duplicated platforms, weak capability development, repeated reinvention, and dependence on vendors.

Too much focus on long-term platforms may create slow value delivery, loss of stakeholder confidence, excessive architecture, underused infrastructure, and limited commercial evidence.

A balanced portfolio may include short-term client wins, medium-term reusable products, long-term strategic platforms, risk and governance capability, workforce development, and controlled experimentation.

A useful principle is:

Deliver immediate value in a way that builds reusable long-term capability.

For example, a client document-analysis engagement can be designed to create a reusable ingestion component, an evaluation framework, a redaction service, a reference architecture, a delivery playbook, and a commercial case study.

The client receives value, while the organisation strengthens future capability.


25. Balance central control and local innovation

Data and AI portfolios often face tension between centralisation and decentralisation.

Centralisation provides standards, security, reusability, cost control, shared platforms, governance, and enterprise visibility.

Decentralisation provides speed, local ownership, industry relevance, client proximity, experimentation, and flexibility.

The leader should avoid choosing one extreme.

A federated model can provide:

Central ownership of core platforms, security standards, model access, identity, monitoring, governance, architecture patterns, reusable components, and vendor relationships.

Local ownership of use-case discovery, client relationships, industry expertise, process redesign, user adoption, business outcomes, and local experimentation within guardrails.

The leader's direction should make these boundaries clear.


26. Manage urgent requests without losing focus

Senior leaders frequently receive urgent requests: a major client wants an AI demonstration; a partner requests a custom tool; a regulator announces a new requirement; a competitor launches a new product; a senior executive wants immediate experimentation; a service line requests specialist support.

Not every urgent request is strategically important.

The leader should assess the consequence of not acting, whether there is a real deadline, whether this is a one-time request or a repeatable opportunity, which existing priority would be delayed, whether the request can be handled through a small discovery team, whether there is an existing asset that can be reused, who will own the outcome, and what decision will be made after the urgent work.

The leader should make the trade-off visible.

For example:

We can support this client request, but doing so will delay the document-intelligence release by three weeks. The client opportunity is worth approximately £2 million and may create a reusable industry proposition. I recommend temporarily assigning two specialists while protecting the core platform team.

This is better than simply adding more work to already overloaded teams.


27. Common leadership failure modes

27.1 Too many priorities

When everything is important, nothing is prioritised.

Symptoms: long strategic priority lists; every service line receiving equal attention; teams working across many initiatives; constant context switching; slow delivery; difficulty explaining what matters most.

Correction: limit the organisation to a small number of strategic outcomes and clearly rank initiatives.

27.2 Technology-first direction

Symptoms: strategy organised around tools and vendors; projects approved because a technology is fashionable; weak problem definitions; unclear users; no measurable value.

Correction: require every proposal to begin with a business problem, target outcome, and accountable owner.

27.3 Failure to stop work

Symptoms: old pilots remain active indefinitely; products with low adoption continue to receive funding; teams protect sunk costs; new priorities are added without removing existing work.

Correction: introduce regular stop, pause, merge, and retire decisions.

27.4 Political prioritisation

Symptoms: projects are approved based on seniority or influence; decision criteria are inconsistent; teams do not understand why funding was allocated; enterprise interests are weakened by local pressure.

Correction: use shared criteria, transparent trade-offs, and portfolio-level governance.

27.5 Weak sponsorship

Symptoms: technology teams own business transformation; users are not prepared for change; decisions remain unresolved; benefits are not measured; adoption is low.

Correction: require a senior business owner who is accountable for the outcome and adoption.

27.6 Confusing delivery with value

Symptoms: success is measured by launch dates; teams celebrate features rather than outcomes; benefits are assumed rather than measured; production systems remain underused.

Correction: track value, adoption, quality, risk, and commercial impact after launch.

27.7 Constantly changing direction

Symptoms: priorities change after every executive conversation; teams repeatedly restart work; leaders respond to trends without evidence; employees lose confidence.

Correction: define stable strategic principles, use formal review points, and change priorities only when evidence justifies it.

27.8 Excessive central control

Symptoms: slow approvals; local teams cannot experiment; central teams become bottlenecks; solutions lack industry relevance.

Correction: create clear guardrails and allow decentralised delivery within them.

27.9 Excessive decentralisation

Symptoms: duplicate tools; inconsistent governance; higher cost; fragmented data; multiple vendors solving the same problem; difficult support and maintenance.

Correction: centralise shared capabilities while preserving local ownership of business outcomes.


28. Practical example: prioritising three AI initiatives

Assume the organisation is considering three initiatives.

Initiative A: Internal knowledge assistant — help employees find methodology, policy, and industry knowledge. Benefits: productivity, consistency, faster onboarding, reduced duplication. Challenges: large data estate, access-control complexity, accuracy requirements, change management.

Initiative B: Client-specific due-diligence tool — automate document analysis for a major Deals client. Benefits: immediate revenue, strong client relationship, faster delivery, potential reusable capability. Challenges: tight deadline, client-specific integration, confidential data, possible limited reuse.

Initiative C: Experimental autonomous AI agent — explore multi-agent automation for internal operations. Benefits: strategic learning, future productivity, innovation positioning. Challenges: unclear business owner, uncertain value, high operational risk, limited evidence.

A weak leader may approve all three.

A stronger leader may decide:

  • Start Initiative B with a controlled delivery team because the client value and urgency are high.
  • Continue Initiative A as a strategic platform priority, protecting its core team.
  • Limit Initiative C to a small research experiment with strict time, cost, and risk boundaries.
  • Require Initiative C to identify a specific business process and sponsor before further investment.
  • Reuse components from Initiative B within Initiative A where appropriate.
  • Review all three after eight weeks using defined evidence.

This decision balances immediate revenue, long-term capability, and strategic learning.


29. A daily leadership checklist

Every day, the leader should ask:

Direction — Are teams clear about the most important outcomes? Has anything changed that affects our direction? Are new requests consistent with the strategy? Are leaders communicating the same priorities?

Portfolio — Which initiatives need a decision? Which initiatives are drifting? Which work no longer appears valuable? Are we carrying too much work in progress? Is a successful initiative ready to scale?

Value — What measurable value has been delivered? Are teams measuring outcomes or only activity? Is adoption increasing? Are our financial assumptions still credible?

Ownership — Does every priority have one accountable owner? Are sponsors actively involved? Are decisions being delayed because ownership is unclear?

Resources — Are scarce specialists working on the highest-value problems? Are teams overloaded? Are we funding maintenance and adoption as well as development? Should resources be moved?

Risk — Are any initiatives creating unacceptable risk? Are high-risk AI systems receiving sufficient oversight? Are data, privacy, security, and regulatory concerns being addressed early?

Focus — What should we stop? What should we simplify? What should we reuse? What decision am I avoiding?


30. A weekly portfolio discussion template

A weekly leadership discussion can use the following structure.

  1. Strategic changes — new client demand, regulatory developments, competitive activity, organisational changes, technology developments.
  2. Top priorities — for each: intended outcome, current status, evidence of value, key risk, decision required.
  3. Resource conflicts — scarce specialists, funding pressure, leadership attention, vendor capacity, platform dependencies.
  4. New requests — for each: problem, sponsor, value, urgency, reuse potential, recommended decision.
  5. Stop or pause candidates — low adoption, weak sponsorship, limited value, duplicated capability, unresolved dependency, strategic misalignment.
  6. Communications — what teams need to know, what executive stakeholders need to understand, what client messages are required, what decisions need written confirmation.

31. A one-page priority statement

A leader should be able to summarise the direction on one page.

The statement should include:

  • Our ambition — what the organisation wants to become or achieve.
  • Our priority outcomes — three to five measurable outcomes.
  • Our focus areas — the capabilities, markets, industries, or problems receiving investment.
  • Our decision principles — how initiatives will be assessed.
  • What we will not prioritise — the categories of work that will not receive significant investment.
  • Measures of success — how progress will be evaluated.
  • Leadership ownership — who is accountable for each outcome.

Example:

Our Data and AI priority is to create measurable client growth, improve professional productivity, and strengthen trust. We will invest in reusable capabilities that serve multiple clients or service lines. We will prioritise initiatives with strong business ownership, accessible data, measurable value, and manageable risk. We will not fund isolated technology experiments without a defined problem, sponsor, and decision pathway. Success will be measured through revenue, adoption, productivity, quality, reuse, and risk outcomes.


32. Behaviours of leaders who set direction well

Leaders who set direction effectively demonstrate several consistent behaviours.

  • They simplify complexity — turn a large number of competing ideas into a small number of understandable choices.
  • They remain outcome-focused — repeatedly connect activity to business, client, employee, or risk outcomes.
  • They ask difficult questions — challenge weak assumptions, unclear ownership, and unproven value.
  • They make trade-offs visible — explain what will be delayed, reduced, or stopped when a new priority is approved.
  • They protect focus — prevent teams from being distracted by every emerging request or technology trend.
  • They use evidence — change direction when evidence shows that assumptions are wrong.
  • They communicate repeatedly — recognise that alignment requires consistent explanation.
  • They act with courage — stop politically supported or technically interesting work when it no longer creates sufficient value.
  • They remain curious — seek input from clients, employees, specialists, and external partners.
  • They connect strategy and execution — ensure that objectives, budgets, teams, governance, and performance measures all support the same direction.

33. Final leadership principle

The purpose of direction is not to control every action.

It is to give people enough clarity to make good decisions without constantly seeking senior approval.

A well-directed organisation allows employees to ask:

  • Does this support one of our priorities?
  • Does it solve an important problem?
  • Does it create measurable value?
  • Is there a clear owner?
  • Can we reuse something that already exists?
  • Is the risk acceptable?
  • Is this more important than the work already committed?
  • What should we stop to create capacity?

When these questions become part of the organisational culture, prioritisation is no longer performed only by senior leadership. It becomes a shared discipline.

The strongest leaders do not create the largest number of initiatives.

They create clarity.

They focus the organisation on the few problems that matter most.

They allocate resources deliberately.

They challenge activity that lacks purpose.

They stop work that no longer creates value.

They ensure that strategy, people, funding, technology, and execution move in the same direction.

That is how leadership turns ambition into meaningful organisational results.

Discussion

Comments

Share feedback or questions about this page. No account required.

Loading comments…