# Consulting *Cases*

Projects that run as cases: working into a real situation, building a recommendation and pitching it to faculty and company representatives. A selection of them is here, more will follow.

> Project page: https://clemenshoeller.at/en/projects/consulting-cases
> Category: business/cases

## Key facts

- **Format** · Cases with pitch
- **Institution** · WU Vienna
- **Period** · 2023 — 2026
- **Scope** · from across my studies
- **Status** · growing

## /01 How these courses work

A large part of my studies ran not as lectures but as cases: you receive a real starting situation, work into it, develop a recommendation and pitch it at the end to faculty and in some courses to company representatives. Most ran as team work, some on my own.

The format is harder than an exam and more instructive, because three things have to work at once: the **analysis** has to hold, the **recommendation** has to be workable, and both have to land in twelve to fifteen minutes so that an audience without prior knowledge can follow. If one of the three fails, the rest does not save it.

The cases below differ deliberately, because they train different muscles: organizational analysis, technical solution design, academic reading, product development, ethics in system design, semantic modeling, project costing, marketing planning, company valuation and interaction design.

## /02 The cases

*Transformative Management · Group project*

### Erste Hub: from innovation island to transformation engine

**Situation** — Erste Group built an innovation unit, Erste Hub, that deliberately sat outside the usual routines. That very separation is what made it successful, among other things in building the George platform. With the move to the shared campus and after the pandemic, fixed routines and approval paths are returning, and hybrid work is weakening the informal culture that defined the Hub.

**Core tension** — The same separation that made the Hub strong now limits its impact on the rest of the bank. Scaling without being absorbed is the problem.

**Approach** — Analysis along the Hub's own history, then an external comparison with organizations facing the same problem: DBS Bank as innovation culture inside an incumbent bank, the ÖBB Open Innovation Factory as an innovation space at the organizational boundary, plus research on innovation labs as organizational catalysts.

**Recommendation** — Four directions: position the Hub as a driver for the organization rather than a protected exception, actively protect flexible innovation space inside the campus, design a hybrid innovation rhythm, and translate the Hub's routines into learning opportunities for the whole bank.

**Learned** — That culture is not a side effect of structure but depends on it. The Hub was not innovative because different people sat there, but because different rules applied. Roll the rules back and the culture goes with them, however much you invoke it.

**Skills gained:** Organizational analysis · Benchmarking · Change management · Stakeholder communication · Actionable recommendations · Presenting in English

*Digital Markets and Strategies · Group project*

### The Good, the Bad, and the Unhirable

**Topic** — Recommender systems for job applicants in online labor markets. The core of the problem is information asymmetry: whoever hires sees profiles, not performance.

**Why it hurts** — The applicant pools are enormous, search costs correspondingly high, and **60%** of posted jobs end in no contract at all. A recommender system here would not be a convenience but the difference between a working market and one running empty.

**Analysis** — We worked out why classic recommendation logic fails here, along three gaps: there is only **one** evaluation per application and no shared ratings, which breaks collaborative filtering. A model has to distinguish **three** outcomes rather than two, namely hired and successful, hired and unsuccessful, and not hired. And applications form a **sequence**, not independent single cases.

**The exercise behind it** — Reading an academic paper so that you understand its construction and not just its result, then presenting it in fifteen minutes to an audience that has not read it.

**Learned** — To not just retell a method but examine where its assumptions break. The three gaps were not listed in the paper; they only emerged from thinking through what the data actually looks like.

**Skills gained:** Literature reviews · Academic writing · Recommender systems · Analytical thinking · Presenting in English

*Marketing and Innovation · Group project*

### StudyGo: learning that fits the commute

**Target group** — Students and pupils between 15 and 30 in European cities who commute daily. The starting point was a persona with a customer journey rather than a product idea.

**Core observation** — Studying while commuting rarely fails because of motivation but because of structure: the trip is fragmented, restless and hard to plan, and classic learning material is none of those things.

**Solution** — An app that breaks the user's own route into learning-ready segments, adapts content automatically to time, movement and situation, and builds on the user's own course materials rather than third-party content.

**What came with it** — Not just the concept but the path to it: a customer journey, a growth path from learner-driven usage toward integration with university platforms, and an effort estimate with roles, hours and cost for a realistic first build.

**Learned** — That a product idea only holds once it solves a structural problem instead of asserting a motivation problem. The sentence “studying while commuting fails on structure, not on willpower” was the turning point of the whole presentation.

**Skills gained:** Persona & customer journey · Product conception · Requirements & solution design · Effort estimation · Teamwork · Presenting in English

*Value-Based System Engineering · Group project*

### When an AI plays pastoral care

**Task** — A competitive analysis of an AI service offering spiritual guidance: a system people talk to about guilt, illness and deeply personal matters. Analyzed using the value-based engineering methodology.

**Approach** — Identify three value bearers (scripture-grounded answers, pastoral conversation, personalization including memory), derive value qualities and core values, and break one of them down into ethical and concrete system requirements. Among other things we tested how the system responds to a confession-like disclosure.

**The prioritization** — Three core values came out of it: knowledge, dignity and privacy. **Dignity** was prioritized, weighed against truth and freedom along fixed criteria: end in itself or means, moral weight, harm if violated, negotiability. It was then unfolded into eight qualities, from recognition as a person to protection from spiritual coercion, and every requirement paired with the threat it defends against.

**Why it sticks** — Because the method forces you to phrase **dignity** as a requirement rather than an attitude. “The system should be respectful” is not a requirement; “the system must visibly separate quotation, interpretation and advice” is one. That translation is exactly the work.

**Learned** — To translate values into checkable requirements. Since then I distrust any requirement you cannot test: “should be trustworthy” is a statement of intent, not a specification.

**Skills gained:** Value-based engineering · Ethics in system design · Requirements analysis · AI evaluation · Analytical thinking

*Semantic AI Technologies for KM · Group project*

### Building an ontology from scratch

**Task** — Design an ontology for fitness and exercise from the ground up, following the classic ontology engineering process. Not populating it, but first constructing it properly.

**First step** — Determine scope, specifically by asking who would actually use it: beginners who need an overview; advanced athletes who want to improve performance; and fitness facilities that want to understand their members' preferences.

**Competency questions** — From that, six concrete questions the ontology has to be able to answer, such as: how many calories does a given session burn? Which exercises suit beginners? Which goals has a person set and achieved? Those questions are the yardstick for every later design decision.

**Only then the model** — Check existing vocabularies instead of reinventing everything, enumerate terms, define classes and taxonomy, define object and datatype properties, set constraints. The result is around 20 classes, from UserProfile and WorkoutRoutine through Sets, Repetitions and RestIntervals to goal types such as WeightLoss and EnduranceImprovement.

**Learned** — That the competency questions are the actual design. Until you know which questions the model has to answer, every class is a matter of taste; afterwards it is a decision you can justify. What becomes of such a model once real data runs into it is under populating a knowledge graph and proving where it came from.

**Skills gained:** Ontology engineering · OWL / RDF · Competency questions · Taxonomy & constraints · Database design · Requirements & solution design

*Applications of Semantic AI in KM · Group project*

### Populating a knowledge graph and proving where it came from

**Task** — Populate an existing ontology with real instances while keeping it traceable where every single statement came from. Nothing is designed here; what gets tested is the other half of the craft, namely whether a model can absorb reality without it becoming unclear what it rests on. Designing for the same subject area was its own course: building an ontology from scratch.

**Model** — Four connected classes with at least five properties each and explicit data types: **UserProfile**, **FitnessGoal**, **Routine** and **Exercise**, linked through object properties such as hasGoal, includesExercise and isAssignedTo.

**Population** — Instances via two routes: from tabular data through declarative mappings and from free text. Plus a provenance file recording which statement came from where. Everything delivered as Turtle.

**Why it matters** — Because it is the same technique the data layer of [AURORA](/projekte/aurora) builds on. A knowledge graph is only worth something when it stays traceable where every edge came from.

**Learned** — That a knowledge graph lives or dies by the origin of its statements. Instances are quickly generated; the question of which row of which source produced an edge decides whether the graph can still be trusted later.

**Skills gained:** Semantic modeling · Declarative mappings · Provenance · Turtle / RDF · Database design · Analytical thinking

*Projektmanagement · Group project*

### Community Fitness Challenges: costing a project end to end

**Idea** — An app that creates a sense of community and competition through shared fitness challenges. The proposal addresses universities, health organizations and fitness brands as sponsors.

**What it was really about** — Not the idea but its planning: context and SWOT analysis, a work breakdown structure down to work-package level, and for each package an estimate of cost and duration. Five phases, from market research through backend and frontend to leaderboard, reward system, quality assurance and launch.

**The result** — A plan over **24 months** and **€304,700**. What is interesting is not the sum but how it comes about: €277,000 from the work packages, plus a ten percent reserve and a two-month buffer, both stated separately instead of folded into the estimates. A buffer that is hidden cannot be discussed.

**Risk and control** — Per risk a probability, an impact and a countermeasure, from budget overrun to the product flopping. For control a **RACI matrix** across five roles and **earned value analysis**: cost and schedule indices compared the value of completed work against what it had cost and taken.

**Learned** — That a number in a project plan is a claim you have to justify. The exercise is not to estimate cheaply but traceably. And that an index below 100 percent explains nothing; it asks a question.

**Skills gained:** Work breakdown structure · Effort & cost estimation · SWOT · Project management · Teamwork · KPI definition & reporting

*Seminar aus Business Information Systems · Solo project*

### "Black Mirror" as a seminar: human dignity in the interface

**Setting** — The final seminar of the specialization unofficially carries the name of the Netflix series: it tests visions of the future from science fiction against posthumanist perspectives and findings from cognitive science. The assessment is deliberately not a paper but an **artistic artefact** of your own choosing, from a collage to a film.

**My choice** — Instead of an image, a decision you can walk into: an interactive customer-journey website that leads through scenarios in which an AI system passes judgment on people. At every station you decide yourself, and afterwards you see what your choice meant for the person affected.

**Why this format** — A poster asserts a stance, a scenario produces one. Someone who has clicked that efficiency comes before empathy talks about human dignity differently afterwards than someone who has looked at a chart about it. The interaction here is not packaging but the argument itself.

**The core** — Dignity and empathy are not properties of a model but of the interface in front of it: what gets asked, what gets withheld, which option is missing. A technically identical system can be dignified or humiliating through its interface alone.

**Learned** — That ethics does not get added at the end but sits in the design of the interaction, and that science fiction is a usable tool for it: it lets you think a system through to its conclusion before it exists. In the master's program the same idea came back to me as a methodology, in value-based engineering.

**Skills gained:** Interaction design · Scenario design · Ethics in system design · HTML/CSS/JS · Academic writing · Presenting in English

*Finanzierung · Solo project*

### Coca-Cola: what the share is worth in twelve months

**Task** — An analyst report with a concrete twelve-month price target. So not describing how the company is doing, but naming a number and defending it.

**Derivation** — Via the dividends: a growth rate of **1.19%** from the previous years' payouts, and a forecast annual dividend of **€1.80** from the quarterly one. The discount rate comes from the CAPM, with a beta of 0.54 for a stock that runs considerably calmer than the market, and lands at **6.48%**. From that a price target of **€34**.

**Plus the context** — Key figures for the financial year, the five-year price history, market position in more than 200 countries and the competitive landscape. The price target does not stand alone but next to what makes it plausible or implausible.

**Why it is here** — Because it shows the other half of the toolbox. Most projects on this page work with systems and models; this one works with a valuation model and assumptions you have to disclose for the number to mean anything at all.

**Learned** — That any valuation is only as good as the assumptions it discloses. The risk-free rate and the market risk premium were set; the growth rate was the one number everything hinged on, and naming it mattered more than computing the result to two decimal places.

**Skills gained:** Equity valuation · Dividend discount model · Financial analysis · Disclosing assumptions · Excel · Data analysis & statistics

## /03 And the ones that did not make it onto this page

These too are a selection, not a list. There are further group projects and individual submissions: process models, IT governance analyses, distributed systems, IT law and a fair amount of smaller work that together says more about the range than any single title.

And more keep coming; my studies run until 2027. What ends up here depends on whether there is something to show that goes beyond “took part”.

If a particular case is of interest, feel free to [just ask](/#kontakt). Much of it can be shared, it is simply not all publicly posted.

## /04 What it trains

- **Structure under time pressure.** A week before the pitch you always know too much and have too little structure. The work is reducing the material to the three statements that actually carry.
- **Presenting in English.** Not as a language exercise but as a clarity exercise: in a second language an audience forgives no convoluted sentences.
- **Delivering as a team.** Four to five people, different ideas of what makes a good slide, one shared result. That is the part no exam teaches.
- **Recommendations somebody could act on.** The difference between an analysis and a consultation is the last step: what exactly should this company do differently on Monday?

> **On the submissions** — Each case states at the top whether it ran as team work or on my own. For the team projects the names of my colleagues are left out, and the full submissions are not public because they are not mine alone.

## /05 Related projects

These projects connect more tightly than the tiles on the home page suggest. Here are all the others, sorted by how closely they relate to this one:

- [AURORA](https://clemenshoeller.at/projekte/aurora)
- [Zotter Marketing Plan](https://clemenshoeller.at/projekte/zotter-marketingplan)
- [AI Talent Gap](https://clemenshoeller.at/projekte/ai-talent-gap)
- [Healthcare Fraud Detection](https://clemenshoeller.at/projekte/fraud-detection)
- [Prompt Injection](https://clemenshoeller.at/projekte/prompt-injection)
- [LLMs & Creativity](https://clemenshoeller.at/projekte/llms-kreativitaet)
- [AI Automations](https://clemenshoeller.at/projekte/ki-automatisierungen)
- [Google vs. ChatGPT](https://clemenshoeller.at/projekte/google-vs-chatgpt)
- [This Website](https://clemenshoeller.at/projekte/diese-website)
- [VWA: Origin of the Internet](https://clemenshoeller.at/projekte/vwa)

---
*German version: https://clemenshoeller.at/projekte/consulting-cases.md*
*Group and individual projects from my studies at WU Vienna: Erste Group's innovation culture, an AI warning-system consortium, recommender systems, product concepts, ontologies, project costing, marketing planning, company valuation and an interactive ethics scenario.*