How to build a digital transformation course: a complete guide for lecturers

Central question: What changes when an organisation moves from digitizing information to transforming how it creates and captures value?

Start by making the boundary of the subject explicit. Digital transformation is not a synonym for installing software. Lecturers need students to distinguish digitization of information, digitalization of activities and processes, and transformation that changes value propositions, operating models, capabilities or organisational identity. This gives the rest of the course a test: what exactly is transforming, for whom, and to what business end?

What this concept covers

• Digitization, digitalization and digital transformation as distinct levels of change.
• Technology as an enabler rather than the objective of transformation.
• Business outcomes, value creation and organisational renewal.
• Legacy processes, assets, capabilities and constraints.
• Transformation as an ongoing capability rather than a one-off programme.

Learning outcomes

By the end of this concept, students should be able to:

• Distinguish digitization, digitalization and digital transformation.
• Diagnose whether a proposed initiative is efficiency improvement or business transformation.
• Identify the business outcome and organisational boundary of a transformation.
• Explain why technology adoption alone may not create strategic value.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Open with five initiatives and ask students to classify each as digitization, digitalization or transformation.
• Require students to state the business problem before naming a technology.
• Use a before-and-after operating model sketch rather than a technology list.
• End with a one-sentence definition students can apply across later cases.

Case-style example

HarborSure Insurance processes 1.2 million claims a year. Management proposes a $6 million document-scanning project that cuts average handling time from 9 days to 6, while a second proposal costing $18 million would redesign claims around self-service, automated triage and usage-based products. Students classify both initiatives, calculate the implied annual time saving, and defend which proposal is genuinely transformational. They discover that scale of spend does not determine transformation - the change in value creation does.

Where students struggle

Students often equate novelty, spend or AI use with transformation. Push them to identify a changed customer proposition, operating model, decision process or capability, not merely a newer tool.

Reading and a quick check

Use Vial (2019) to anchor the definition debate. Quick check: ask students to name one technology-heavy initiative that is not transformational and one low-technology change that could be.

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

The distinction becomes useful only when students can connect transformation to strategy. The next concept asks how an organisation decides what it is trying to become and why.

Central question: How should leaders translate competitive intent into a transformation ambition that is specific enough to guide investment and change?

Digital transformation should be taught as strategy execution under technological change, not as a portfolio of disconnected projects. Students need to link the transformation thesis to customers, competitive advantage, economics and organisational capabilities, then turn that thesis into choices about where to focus and what not to fund.

What this concept covers

• Transformation ambition and strategic intent.
• Business outcomes, strategic priorities and value pools.
• Capability gaps and transformation themes.
• Roadmaps, sequencing and strategic coherence.
• Choice, trade-offs and explicit non-priorities.

Learning outcomes

By the end of this concept, students should be able to:

• Formulate a transformation ambition linked to competitive outcomes.
• Translate strategy into a small set of transformation priorities.
• Evaluate whether initiatives reinforce or contradict the strategic thesis.
• Explain what the organisation should stop, defer or refuse to fund.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Give teams the same company but different strategic ambitions and compare the resulting roadmap.
• Separate outcome statements from solution statements.
• Require a transformation thesis in one paragraph and a list of three non-priorities.
• Use a board-style challenge: why this problem, why now, why this organisation?

Case-style example

Northstar Hotels has $25 million available over two years. One team proposes a mobile-app rebuild expected to lift direct bookings from 38% to 50%; another proposes a digital operating platform expected to reduce room-turnaround cost by 12%; a third proposes both, requiring $34 million. Students write a transformation thesis, rank the initiatives and specify one option to defer. They discover that a coherent strategy can justify different priorities depending on whether the ambition is customer intimacy or operating leverage.

Where students struggle

Students produce aspirational language such as "become digital-first" without a measurable business consequence. Require a target customer, capability, economic outcome and time horizon.

Reading and a quick check

Use Rogers (2023), Chapters 1 and 3. Quick check: can students remove the word "digital" from their ambition and still see the strategic outcome?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

Once the ambition is explicit, students need evidence about the external forces that make change urgent or alter the feasible options.

Central question: Which external technological, regulatory, economic and ecosystem shifts are material enough to change the transformation decision?

Digital disruption is easily taught as a trend list. A stronger approach makes students decide which external signals actually change strategy. PESTLE, ecosystem mapping and competitor analysis become decision tools when students must weight evidence, identify dependencies and distinguish structural shifts from short-lived noise.

What this concept covers

• Technological change and diffusion.
• Regulatory, legal, social and environmental constraints.
• Platform and ecosystem power.
• New entrants, complementors and boundary shifts.
• Signal prioritisation, uncertainty and scenario thinking.

Learning outcomes

By the end of this concept, students should be able to:

• Evaluate external forces for materiality rather than completeness.
• Map ecosystem actors and dependencies around a transformation.
• Distinguish a trend from a decision-relevant signal.
• Defend how external evidence changes timing, scope or risk appetite.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Use a six-factor PESTLE scan but force weights to total 100.
• Map customers, complementors, platforms, regulators and data providers.
• Ask teams to delete half their trends and defend what remains.
• Run a scenario pair that changes one external assumption at a time.

Case-style example

VoltEdge Mobility is deciding whether to launch a connected fleet service in Country A. The market grows 14% a year, data-localisation rules may add $2.5 million of annual cost, a dominant mobile platform controls 62% of distribution, and a proposed subsidy could reduce customer prices by 9%. Students weight six external factors, then choose launch, delay or partner. They discover that teams can reach different conclusions from the same facts because they assign different materiality to regulation and ecosystem dependence.

Where students struggle

Students treat PESTLE as six equally important boxes. Make them weight the factors, state the evidence and explain how each material factor changes the decision.

Reading and a quick check

Use Hanelt et al. (2021) for strategy and organisational change. Quick check: which single external factor would most alter the transformation roadmap if it moved against you?

Where a simulation fits

The PESTLE Analysis Simulation fits after students know the six categories. Teams score and weight the same evidence, then negotiate a recommendation from opposing Growth Strategy and Risk Management mandates. Use it to turn external scanning into a prioritised decision rather than a list.

Where it leads

External disruption tells students why the status quo may not hold. The next step is to redesign the value proposition and business model around changed customer behaviour and ecosystem economics.

Central question: How should digital capabilities change the customer problem solved, the experience delivered and the way value is captured?

Transformation becomes commercially meaningful when it changes what customers can do, how easily they can do it or how the firm earns from serving them. This concept connects customer journeys, value propositions, platform logic, recurring revenue, data-enabled services and business-model design.

What this concept covers

• Customer jobs, pain points and journey redesign.
• Digital value propositions and service layers.
• Business Model Canvas and revenue-model choices.
• Platforms, network effects and ecosystem participation.
• Unit economics, adoption and cannibalisation.

Learning outcomes

By the end of this concept, students should be able to:

• Redesign a customer journey around a clear problem.
• Construct a digital value proposition and business-model hypothesis.
• Assess revenue logic, adoption assumptions and cannibalisation risk.
• Explain when platform or ecosystem participation is strategically credible.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Start with a customer journey before discussing channels or technology.
• Require a value proposition, revenue model and cost-to-serve implication on one page.
• Compare a digital add-on with a genuinely different business model.
• Ask which existing revenue stream the new model may cannibalise.

Case-style example

CivicPro Tools sells equipment through distributors. A proposed subscription service costs $8 million to launch, targets 30,000 customers at $38 per month and could reduce distributor sales by 6%. A second option is a free diagnostic app designed to raise replacement sales by 9%. Students calculate first-year subscription revenue, map the customer journey and choose the stronger business-model experiment. They discover that direct digital revenue can look attractive while creating channel conflict that changes the economics.

Where students struggle

Students jump to app features. Keep the sequence customer problem -> value proposition -> business model -> capability -> technology.

Reading and a quick check

Use Verhoef et al. (2021) to connect customer, business model and organisational change. Quick check: what customer behaviour must change for the proposed model to work?

Where a simulation fits

The Startup Creation Simulation is the closest portfolio fit here, not a dedicated Digital Transformation simulation. It can be reframed as a venture-style design lab in which teams define a problem, value proposition, market and Business Model Canvas, then face investor questioning about whether the new model is coherent and fundable.

Where it leads

A redesigned proposition creates new information and decision requirements. Students next examine data and AI as capabilities that support, and sometimes reshape, the model.

Central question: Which data and AI use cases create enough value to justify new capabilities, controls and changes to decision rights?

Data and AI should be taught as operating and governance choices, not a catalogue of algorithms. Students need to connect use cases to decisions, data quality, ownership, human oversight, economics and measurable outcomes. Generative and agentic AI make this especially important because deployment can move faster than organisational readiness.

What this concept covers

• Data as an organisational asset and dependency.
• Analytics and AI use-case selection.
• Data quality, ownership, lineage and access.
• Human-in-the-loop decision design and automation boundaries.
• Model risk, monitoring and value measurement.

Learning outcomes

By the end of this concept, students should be able to:

• Prioritise AI and analytics use cases by value, feasibility and risk.
• Identify the data and governance conditions a use case requires.
• Design an appropriate human oversight point.
• Specify outcome metrics that distinguish adoption from value creation.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Give students ten AI ideas and a hard capacity limit of three.
• Require every use case to name the decision changed and data required.
• Run a failure-mode workshop before discussing model sophistication.
• Ask who is accountable when the automated recommendation is wrong.

Case-style example

LumenCare Health has budget for two of four AI projects: appointment triage costing $1.8 million with expected annual savings of $1.1 million; coding assistance costing $2.4 million with $1.5 million savings; a patient chatbot costing $900,000 with uncertain benefits; and demand forecasting costing $1.2 million with expected inventory savings of $700,000. Students rank projects by value, feasibility and risk, then specify oversight. They discover that the highest headline return may not be the most deployment-ready option.

Where students struggle

Students treat AI capability as a technology purchase and underweight data quality, workflow integration, user trust and control design.

Reading and a quick check

Use Kraus et al. (2022) to broaden the management lens. Quick check: for one proposed AI use case, name the decision owner, the minimum viable data and the failure that must trigger human review.

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

Data and AI depend on an enabling architecture. The next concept moves from use cases to the platforms, cloud, APIs and legacy constraints that determine how quickly the organisation can change.

Central question: What technology architecture gives the organisation enough modularity, data access and resilience to change repeatedly rather than deliver one isolated project?

A business-facing Digital Transformation course does not need to teach cloud engineering, but it should make architecture legible to managers. Students should be able to recognise why tightly coupled legacy systems, fragmented data and vendor dependence constrain strategic options, and why modular platforms, APIs and cloud services can change the pace and economics of experimentation.

What this concept covers

• Legacy architecture and technical debt as business constraints.
• Cloud economics and operating implications.
• APIs, modularity and integration.
• Platforms, shared services and data layers.
• Build, buy, partner and vendor-lock-in trade-offs.

Learning outcomes

By the end of this concept, students should be able to:

• Explain architecture choices in business terms.
• Diagnose how legacy dependencies constrain a transformation roadmap.
• Evaluate build, buy and partner options.
• Connect modularity and APIs to experimentation speed and ecosystem strategy.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Use a simplified architecture map with five systems and two data stores.
• Ask students to trace a customer request across systems.
• Compare a fast point solution with a slower shared-platform investment.
• Require a one-page executive architecture decision, not technical diagrams alone.

Case-style example

Meridian Freight runs 14 country systems. Launching a real-time customer portal on the existing architecture costs $4 million and can go live in six months, but each new country adds $350,000 of integration. A shared API and data layer costs $11 million, takes 18 months and reduces later country integration to $60,000. Students calculate the break-even number of country rollouts and defend speed versus reuse. They discover why local optimisation can create long-term transformation drag.

Where students struggle

Students either avoid architecture as "too technical" or reduce it to cloud-versus-on-premise. Keep the discussion on strategic flexibility, integration cost, resilience and decision speed.

Reading and a quick check

Use Wessel et al. (2021) to distinguish transformation of the value proposition from IT-enabled improvement. Quick check: what architectural dependency would most constrain your preferred business-model change?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

With enabling architecture in view, students can redesign the work itself - processes, roles, handoffs and decision rights.

Central question: How should work, decision rights and organisational interfaces change when digital tools remove old constraints?

Automating a poor process can make waste move faster. This concept teaches students to map the current state, challenge unnecessary steps and redesign end-to-end work before selecting automation. The digital operating model then connects process design to roles, capabilities, governance and cross-functional ownership.

What this concept covers

• Current-state and future-state process mapping.
• Automation, workflow and exception handling.
• Decision rights and cross-functional ownership.
• Shared services, product teams and operating-model choices.
• KPIs for speed, quality, cost and customer outcome.

Learning outcomes

By the end of this concept, students should be able to:

• Redesign a process before automating it.
• Identify handoffs, bottlenecks and decision delays.
• Specify changed roles and decision rights.
• Select operating metrics tied to business outcomes.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Map a process with time, queue and error data.
• Delete or combine steps before allowing technology solutions.
• Assign ownership for end-to-end outcome, not functional activity.
• Use a failure scenario to test exception handling.

Case-style example

ArborBank onboards small-business customers through 17 steps, six handoffs and an average 11-day cycle. Forty percent of applications require rework, and manual checks cost $42 per case. A straight automation plan costs $3 million and targets 7 days; a redesigned process costs $4.5 million and targets 3 days with rework below 15%. Students estimate annual rework savings at 80,000 applications and choose a design. They discover why process simplification can dominate automation alone.

Where students struggle

Students start with robots, workflow software or AI. Require them to remove non-value-adding work and clarify decision rights first.

Reading and a quick check

Use Cöster et al. (2023), chapters on organisation and processes, as practical support. Quick check: which step exists only because of the current organisational design rather than a customer or control need?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

A new operating model still needs a mechanism for learning under uncertainty. The next concept introduces experimentation and agile delivery as governance for unknowns, not as ritual.

Central question: How can an established organisation test transformation hypotheses quickly without abandoning strategic discipline or control?

Digital transformation contains uncertainty that cannot be eliminated through planning. Students need a disciplined language for hypotheses, minimum viable experiments, evidence thresholds and scale decisions. Agile methods are useful when taught as a way to shorten learning cycles and make evidence visible, not as a collection of ceremonies.

What this concept covers

• Hypothesis-driven innovation and testable assumptions.
• Minimum viable experiments and evidence thresholds.
• Agile teams, backlogs and iterative delivery.
• Innovation pathways inside established organisations.
• Kill, pivot, persevere and scale decisions.

Learning outcomes

By the end of this concept, students should be able to:

• Turn a transformation claim into a testable hypothesis.
• Design a low-cost experiment with a decision threshold.
• Evaluate evidence before committing to scale.
• Explain when agile delivery helps and when stable process control is more appropriate.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Convert strategic claims into "we believe / we will know if" statements.
• Give each team a fixed experiment budget and two weeks of simulated time.
• Make students pre-commit to a scale/stop threshold.
• Debrief sunk-cost bias when evidence is weak.

Case-style example

EchoHome Energy believes a digital maintenance subscription will reduce churn from 18% to 12%. A full launch costs $7 million. A six-week pilot with 2,000 customers costs $420,000; success is defined as renewal intent above 72% and service cost below $9 per customer per month. Students design the experiment, choose evidence thresholds and decide whether to scale after mock results show 75% intent but $13 cost. They discover why a positive customer signal can still fail the business-model test.

Where students struggle

Students call every project "agile" without specifying what uncertainty the iteration is meant to resolve. Ask what is being learned, by when, and what decision the evidence unlocks.

Reading and a quick check

Use Rogers (2023), Chapters 2 and 5. Quick check: what is the cheapest credible test of the assumption most likely to break your transformation case?

Where a simulation fits

The Startup Creation Simulation can support this concept as an applied innovation exercise. Startup teams turn an opportunity into a value proposition, market estimate and Business Model Canvas, then defend the model under live investor questioning. The transfer is entrepreneurial experimentation and business-model coherence, not a claim that the simulation replicates enterprise transformation governance.

Where it leads

Experiments create more possible initiatives than the organisation can fund. Students next need investment appraisal and portfolio discipline.

Central question: How should leaders allocate scarce capital across transformation initiatives with different returns, risks, dependencies and strategic value?

Transformation programmes fail when every initiative is labelled strategic and funding becomes entitlement. This concept introduces business cases, NPV and other appraisal measures, but it also teaches students to handle options, dependencies, non-financial benefits and portfolio balance. The objective is a fundable transformation portfolio, not a spreadsheet ranking in isolation.

What this concept covers

• Transformation business cases and benefit hypotheses.
• NPV, IRR, payback and profitability index.
• Capital rationing and portfolio optimisation.
• Dependencies, strategic options and risk-adjusted prioritisation.
• Stage-gates, funding tranches and benefits ownership.

Learning outcomes

By the end of this concept, students should be able to:

• Appraise transformation investments using financial and strategic criteria.
• Prioritise a portfolio under a hard capital constraint.
• Identify dependencies and option value that simple rankings miss.
• Design stage-gates linked to evidence and benefits.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Give teams more attractive projects than the budget can fund.
• Require financial appraisal plus a strategic dependency map.
• Separate sunk cost from future funding decisions.
• Ask who owns each benefit after project delivery.

Case-style example

Aster Retail has $20 million for transformation. Project A is a $7 million pricing platform with NPV $6.2 million; B is a $9 million cloud migration with NPV $3.8 million but enables C; C is a $6 million personalisation engine with NPV $7.4 million only if B is funded; D is a $5 million automation programme with NPV $4.9 million. Students select a portfolio within budget and defend whether enabling infrastructure justifies giving up a higher standalone NPV. They discover why dependency changes project ranking.

Where students struggle

Students either ignore financial discipline because transformation is "strategic" or ignore enabling capabilities because their standalone NPV is weaker. Make both types of evidence explicit.

Reading and a quick check

Use Cöster et al. (2023), the chapters on structured decisions and project portfolios. Quick check: which project would you stop first if the budget fell by 20%, and what dependency would that break?

Where a simulation fits

The Capital Budgeting Simulation fits directly after students know the appraisal measures. Each student acts as CFO, evaluates projects using NPV, IRR, profitability index and payback, then allocates a fixed $10 million budget across a portfolio. The debrief should extend the finance logic to transformation dependencies, option value and strategic fit.

Where it leads

Funding the portfolio is not the same as delivering it. The next concept focuses on leadership, governance, culture and change mechanisms that move initiatives through the organisation.

Central question: What leadership and governance mechanisms allow transformation to cross functions, challenge legacy incentives and still remain accountable?

Digital transformation changes routines, power and identity, so a project plan is insufficient. Students need to examine sponsorship, decision forums, funding authority, product ownership, capability building, incentives and cultural signals. Change management is treated as part of operating design rather than a communications workstream added at the end.

What this concept covers

• Executive sponsorship and transformation governance.
• Decision rights, escalation and portfolio forums.
• Culture, incentives and behavioural reinforcement.
• Capability building, talent and role transitions.
• Stakeholder engagement and resistance as information.

Learning outcomes

By the end of this concept, students should be able to:

• Design governance appropriate to transformation uncertainty.
• Allocate decision rights across business, technology and risk leaders.
• Diagnose incentive and capability barriers.
• Plan change actions that alter behaviour rather than only communication.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Use a governance map with named decisions, not committee names alone.
• Ask which legacy KPI rewards the wrong behaviour.
• Run a stakeholder role-play around a contested platform migration.
• Require a capability plan alongside the technology roadmap.

Case-style example

Keystone Publishing is moving from print-led product teams to cross-functional subscription squads. The plan needs $14 million and will remove three regional P&L structures. Regional leaders control 45% of current revenue and oppose central product ownership; digital revenue is growing 28% but still only 22% of sales. Students redesign decision rights, incentives and governance, then defend whether to centralise immediately or phase the change. They discover that resistance can reveal real accountability and customer-localisation trade-offs.

Where students struggle

Students frame culture as attitude and change as communication. Ask which decision right, incentive, role, routine or capability must actually change.

Reading and a quick check

Use Warner and Wäger (2019) on dynamic capabilities and strategic renewal. Quick check: what existing incentive would make a rational manager resist your roadmap?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

Governance also has to constrain harmful or fragile uses of technology. The next concept integrates cybersecurity, privacy, ethics and responsible transformation.

Central question: How should transformation teams design speed and innovation together with security, privacy, fairness and accountability?

Responsible transformation works best when risk is designed into the initiative rather than used as a late-stage veto. Students should distinguish risk appetite from risk avoidance, identify who bears harm, and build security, privacy, ethical review and sustainability considerations into use-case and architecture decisions.

What this concept covers

• Cybersecurity and resilience as transformation dependencies.
• Privacy, consent and data minimisation.
• Bias, fairness, transparency and contestability in automated decisions.
• Third-party and ecosystem risk.
• Responsible innovation, sustainability and stakeholder impact.

Learning outcomes

By the end of this concept, students should be able to:

• Identify material security, privacy and ethical risks in a transformation.
• Design controls proportionate to use-case risk.
• Evaluate trade-offs between speed, data use and stakeholder protection.
• Assign accountability for technology-enabled decisions and incidents.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Threat-model a customer journey at a business level.
• Use a data map to ask what is collected, why and for how long.
• Compare low-risk internal automation with high-impact customer decisions.
• Require an explicit risk acceptance or mitigation decision.

Case-style example

FairLend Digital wants to automate 70% of small-business credit decisions. The model could cut decision time from 48 hours to 8 minutes and save $3.2 million annually, but a pilot shows a 6 percentage-point approval gap between two customer groups and the vendor will not disclose full feature logic. Students recommend deploy, restrict, redesign or stop, then specify controls. They discover that an attractive efficiency case can become strategically unacceptable when accountability and fairness cannot be defended.

Where students struggle

Students put ethics in a final slide. Move it into use-case selection, data design, architecture and governance so it changes the decision.

Reading and a quick check

Use Elia et al. (2024) as an integrative transformation framework, paired with local privacy and AI guidance where relevant. Quick check: who can challenge an automated decision, and what evidence would they receive?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

The final concept asks how the organisation measures benefits, scales what works and keeps transformation capability alive after the initial programme.

Central question: How does an organisation move from pilots and project delivery to measurable enterprise value and a repeatable capacity for change?

Transformation should close with benefits, scaling and renewal rather than a launch event. Students need to connect leading indicators to financial and strategic outcomes, distinguish adoption from realised value, understand why pilots fail to scale, and design feedback loops that refresh the roadmap as conditions change.

What this concept covers

• Benefits maps and outcome ownership.
• Adoption, usage, operational and financial metrics.
• Scaling across products, geographies and functions.
• Technical and organisational debt created during rapid change.
• Continuous portfolio review and strategic renewal.

Learning outcomes

By the end of this concept, students should be able to:

• Design a benefits-realisation plan with owners and time horizons.
• Select leading and lagging indicators for transformation value.
• Diagnose why a pilot may fail to scale.
• Recommend when to scale, stop, retire or re-platform an initiative.

Supports the intended learning outcomes that move students from diagnosis to integrated transformation judgement.

How to teach it

• Make students trace each initiative to a business outcome and metric.
• Separate "delivered", "adopted" and "value realised" on the dashboard.
• Introduce a post-pilot capacity constraint and force reprioritisation.
• Close with a board review in which students defend the next 12 months, not the past 12 months.

Case-style example

BluePeak Manufacturing has six successful digital pilots. Predictive maintenance reduced downtime 18% at one plant, but scaling to 12 plants costs $16 million; a sales configurator raised conversion 5 points but depends on unfinished master-data work costing $4 million. The board will release only $14 million this year. Students build a benefits map, choose what to scale and define stop/continue thresholds. They discover that pilot success does not prove enterprise scalability or portfolio priority.

Where students struggle

Students report project completion as success. Require evidence of adoption, changed behaviour, operating impact and financial or strategic value.

Reading and a quick check

Use Plekhanov, Franke and Netland (2023) to revisit the field and Rogers (2023), Chapters 6 and 7, for scaling and capability. Quick check: what metric would tell you the transformation is creating value rather than merely being used?

Applied teaching activity

Use a short case, decision memo, model build or board-style critique so students leave the concept with a defensible output rather than only a framework.

Where it leads

This concept closes the lifecycle. Students should now be able to diagnose disruption, define a strategic ambition, redesign value creation, build enabling capabilities, fund a portfolio, govern change and defend a scalable roadmap.

10-week course structure

A 10-week version should compress adjacent concepts rather than delete the transformation lifecycle. Combine foundations with disruption, combine data/AI with responsibility where necessary, and keep a distinct investment and governance stage.

14-week course structure

A 14-week version creates space to separate customer and platform work, give architecture its own session, stage Startup Creation across more than one teaching block, and add a fuller investment and responsible-technology debrief.

The Startup Creation Simulation is not a Digital Transformation simulation in a narrow sense. It is the closest current portfolio fit for the innovation and new-business-model part of the course. Students move from an opportunity and customer problem to a value proposition, market sizing and Business Model Canvas, then test the commercial logic in a live funding market where investor teams question assumptions and negotiate investment amount and ownership.

Why it fits here

By Session 8, students already know strategy, customer journeys, business models, data/technology capability and experimentation. The simulation gives them a contained environment in which a proposed digital business model has to survive evidence, investor criteria and scarce capital rather than remain a slide-deck idea.

What students do

• Startup teams: identify an opportunity, define the customer problem and solution, build the value proposition, estimate TAM/SAM/SOM, complete a Business Model Canvas and prepare a funding pitch.
• Venture-capital teams: define an investment thesis, set screening criteria and prepare an Investment Process Document before seeing the final pitches.
• Pitch and negotiation: startup teams defend market sizing and unit economics under questioning; both sides negotiate investment amount and percentage ownership, producing an implied post-money valuation.
• Reflection: the cohort compares funded and unfunded ventures, funding amounts, ownership and valuations, then reconnects the result to assumptions and business-model quality.

Recommended course placement

• Begin preparatory analysis after Session 4 if you want the venture idea to mature across the course.
• Run the main analysis, pitch and negotiation around Session 8 after experimentation and agile-delivery teaching.
• Require a post-simulation memo that translates the venture logic back into an established-enterprise transformation context.

Knowledge students should have before the simulation

• Customer problem and value proposition.
• Business-model and unit-economics basics.
• Market sizing and evidence quality.
• Hypothesis-driven experimentation.
• The distinction between a promising idea and a fundable, scalable business case.

Delivery format

Suggested debrief questions

• Which assumption changed most after investor questioning?
• Did funding success reflect venture quality, negotiation skill, or both?
• Which part of the Business Model Canvas was least evidenced?
• What would be different if this were an enterprise transformation venture rather than an independent startup?
• Which capabilities or governance constraints would the parent organisation add?

The Capital Budgeting Simulation fits the transformation-investment stage because it forces every student to act as CFO and commit scarce capital. Students appraise competing projects using NPV, IRR, profitability index and payback, select a project with a written rationale, and then allocate a fixed $10 million budget across eight independent projects under capital rationing.

Why it fits here

Digital Transformation plans often contain more initiatives than an organisation can fund. The simulation provides a clean financial decision before the lecturer adds transformation-specific complexity such as enabling infrastructure, dependencies, staged investment, non-financial benefits and option value.

What students do

• Review three project briefs, discount rates, expected cash flows and qualitative risks.
• Calculate NPV, IRR, profitability index and payback for each project.
• Select the strongest project and submit a reasoned justification.
• Move to a second decision in which they allocate a fixed $10 million budget across eight projects.
• Review value generated, the optimal portfolio and comparative class position, then explain why their portfolio differed.

Recommended course placement

• At the end of Session 9 after the financial appraisal methods and transformation business-case logic.
• Before students finalise their capstone transformation portfolio.
• Follow immediately with a debrief that introduces dependencies and asks when a lower standalone NPV project may still be necessary.

Knowledge students should have before the simulation

• Cash-flow and discount-rate basics.
• NPV, IRR, profitability index and payback.
• Capital rationing and opportunity cost.
• The difference between project return and portfolio value.

Delivery format

Suggested debrief questions

• Which financial measure influenced you most, and when did it conflict with another measure?
• Which project did you reject despite an attractive feature?
• How would the decision change if one project enabled two others?
• What benefit owner and stage-gate would you add before funding a transformation initiative?
• Which portfolio assumption would you revisit first if the budget fell by 20%?

Grading with the Startup Creation Simulation

The Startup Creation Simulation can support assessment of opportunity, business-model and investment reasoning. It records team-level submissions and negotiated outcomes; it does not automatically establish individual contribution.

• Quality and evidence behind the customer problem, value proposition and market sizing.
• Internal coherence of the Business Model Canvas, unit economics and use of funds.
• For investor teams, quality and consistency of investment criteria and prioritisation.
• Pitch and negotiation reasoning, including the trade-off between investment amount, ownership and implied valuation.
• Individual post-simulation reflection that translates venture decisions back to enterprise transformation.

Grading with the PESTLE Analysis Simulation

The PESTLE Analysis Simulation gives teams the same market-entry decision but opposing mandates. Factor scores, weights, written rationales and the negotiated recommendation can support assessment when combined with a lecturer-defined rubric.

• Evidence quality behind factor scores.
• Materiality and prioritisation, including whether weights total 100 for a defensible reason.
• Ability to distinguish a technological trend from a decision-relevant external force.
• Quality of negotiation and revision when the opposing team challenges an assumption.
• Individual reflection on which factor changed the recommendation and why.

Grading with the Capital Budgeting Simulation

The Capital Budgeting Simulation provides individual evidence of calculations, project selection, written justification and portfolio value. Use the score as evidence about the decision, not as the academic mark by itself.

• Accuracy and interpretation of NPV, IRR, profitability index and payback.
• Quality of the single-project selection and written justification.
• Portfolio construction under the fixed $10 million budget.
• Ability to explain why a financially attractive project may still be rejected in a transformation portfolio once dependencies or risk are added in the debrief.
• Individual CFO-style memo connecting the simulation result to a broader transformation investment case.

The platform records decisions, submissions and comparative outcomes that can support academic judgement. That evidence does not replace the lecturer's judgement and should not be treated as proof of which individual student made which argument unless the specific product evidence explicitly supports that attribution.