One transformation programme, three working views

A retained 2019–2020 modelling example. Reading guide repaired 1 October 2026.

A university is changing its digital services. Strategy colleagues care about objectives and outcomes; operations colleagues care about services and the people using them; project teams care about the changes they must deliver. How can these conversations stay connected without making everybody work from the same crowded picture?

Purpose

This example applies a graph data model to that question. It draws on public University of East London material, including its annual report, with guessed projects, services and other details. It is a toy model and an interview-era working proposal, not a record of the university’s actual programme or a current assessment of it. The original principle remains: suggest, listen and change through discussion with the people who know the organisation.

Back to the Library’s modelling guide · Library

Historical background: Data models for project portfolios — 7 May 2020.

Start with the kinds of thing, before looking at the named examples. These boxes are visual groups in the drawing; they are not an organisational chart or a demonstrated class hierarchy. The overview omits relationship labels: the file guide explains the differences between the saved schemas.

Choose a way in

• Understand the model choices: compare the two schemas and two instance drawings. The filenames are retained, but the old guide’s general-versus-specific ranking is corrected against their actual contents.
• Read a role’s view: operations, strategy, or projects below. Each pairs a relationship diagram with a named consultation example.
• Inspect the working material: original notes and tables, sponsorship questions, three spreadsheet input iterations, or the December 2019 print version (PDF).

From schema to particular names

A schema proposes kinds of things and relationships; an instance graph fills those roles with particular names. The preserved Cypher input declares 150 nodes and 236 relationships, using 13 node labels and 15 literal relationship types. Two relationship spellings differ only by a trailing underscore; the file guide explains that inconsistency. Nodes have supplied id and name properties; relationships are typed, without corresponding id or name properties in that input.

The three views below are saved illustrations. They help frame conversations about the same example; they do not update one another on this page. A drawn enable or deliver link records a modelling assumption, rather than proving a benefit or assigning a real organisation’s decision rights.

Operations: services and consumers

Conversation: which consumers use which services, who operates them, and which project outputs must an operations team accept?

The relationship diagram keeps the kinds of thing visible.

The consultation example supplies names. Its HR and Health & Safety nodes both point through accept to Project_6. Those entries are prompts to discuss and correct, not evidence that these teams accepted an actual project.

Strategy: objectives and outcomes

Conversation: which outcome is supposed to serve an objective, which programme delivers it, and which services does it enable?

Follow Business_Change_4: four strategic objectives point to it through are_delivered_by; the digital transformation programme points to it through deliver; it points to Moodle and Lecture_capture through enable. The placeholder outcome needs a meaningful description before this could guide a decision.

Projects and the services they enable

Conversation: how do the proposed projects sit within programmes, and how do their intended service changes relate to the outcome discussed by the strategy team?

Inspect the wide project schema at full size.

Here the same Business_Change_4, Moodle and Lecture_capture reappear. Project_4: System_Change_2 points to Moodle, while Project_3: System_Change_1 points to Lecture_capture. Shared names let the conversations meet; the picture supplies neither delivery dates nor a proof that the projects achieve the outcome.

Zoom out, or keep the neighbourhood small

The full drawing retains breadth, at the cost of legibility. Choose an editable source to inspect individual labels.

The retained pared-back neighbourhood picture narrows attention; it is not established as a computed one-step ego view. Connected neighbours are not automatically members of the same group; a smaller view also leaves relationships out.

Read, edit or run

The pictures and explanations can be read here. The GraphML files retain editable drawings; the file guide distinguishes their structures and formatting. The Cypher text is the historical database input. It creates records rather than maintaining a live programme or calculating a schedule; its compatibility with current Neo4j versions has not been checked. Opening a GraphML drawing and loading a database are separate steps. No database was run for this reading-guide repair.

Original working notes

The following proposals, challenges and tables are retained from the original example. They mix public-source names, guesses and interview preparation. Read dated references and evaluative phrases in that historical context, not as verified or current statements about the university. The table itself records the author’s caution that much of the proposed approach could be wrong and needs stakeholder discussion.

Compare the model files · Return to the Library