Project Story (v.2)

2025-01-26 Sunday (Updated on 2025-11-09 Sunday)

Intro

NB: Previously this document described the "version 1" of "Project Story". You are now reading the version 2.

Finding the right granularity to document project is challenging. Some documents, like contractual agreements, offers, and orders, are standardized. Yet project documentation itself varies widely. This is generally a good thing since projects can vary greatly. But what if there was an approach that worked in (almost) every case?

Getting started

I call this approach "Project Story". This is how it works:

• Create a directory into any shareable space that all relevant stakeholders can access.
• Add a starting point. Everything that is known, agreed and discussed in the beginning of the project. The idea is to capture the starting point and add information that is known at the time. E.g.:
  • Basic details
  • Goal
  • Stakeholder contact info
  • Budget
  • First tasks

Once you feel comfortable that you have collected the most relevant parts of your project you are done with the first part. Everything that happens after the first part is an update. An update can be about anything:

• Design proposal
• Decision of any kind
• Technology selection
• Meeting or discussion
• Strategy change

Instead of documenting each update separately, it makes sense to keep smaller updates batched to time-bound reports.

What is worth adding?

In order to determine if something is worth adding an update is to ask: "in case of a conflict, does the current story accurately describe how things went if I do not add this update?"

Project Story is about:

• Understanding which updates are worth writing down
• Keeping the tone professional and shareable between all relevant stakeholders
• Confidentiality: although the document is not public, it should aim to include only relevant content.

Note: Project Story can be started in the middle of the project as well.

What does Project Story solve?

One of the most common requests towards any project is to provide a summary of what was done, how it was done and what was the result. This request might come at any stage of the project. Project Story approach makes it rather trivial to provide an answer to such requests. It is matter of removing the entries that are not relevant. It is also possible to rephrase or summarise some of the key moments if necessary.

Another benefit of Project Story is to provide backing of your work. In some cases the past events are viewed differently between you and other parties. E.g. stakeholder might consider that some of the decisions were not followed through. Project Story can be used to construct the series of events with ease.

Most importantly, at least to me personally, Project Story solves most of the meta-work related to project work. Various types of documents starts to pile up: meeting memos, workshop notes, ideas, drafts and all sorts of collaborative documents. Project Story solves one major issue by streamlining the what, why, when and by whom. Sounds simple, but without clear framework things eventually becomes bloated and keeping them organised feels too much work. It does not limit or prevent any other type of notes, but it supports that the right ones are collected.