On a project, you can come across risks that, if they happened, would be complete showstoppers, stopping the project dead in its tracks. They will force you to either rethink the project or give it up. It is important to identify showstoppers as they call for entirely different handling. You can only handle them in two ways:

  1. Put them in project assumptions (you assume they won’t happen)
  2. Dump them at the feet of the client or project sponsor (as they are miles outside of your control)

It is really important to get the project sponsor to realise these are his to deal with, as they are beyond the responsibility of the project. So what do showstoppers look like? Examples include:

  • Product build is based on an OS that the supplier upgrades to an incompatible version (this has happened to me when SAP completely changed the architecture of their CRM solution)
  • Client’s company gets taken over or hits economic problems (had this one too)
  • Software built on top of a client’s system that falls out of support (pretty common with desktops not being capable of upgrade)
  • Mass resignations by team members due to pay dispute (has happened with offshore teams where rival offered more money)

You might be inclined to ignore showstoppers. If you can’t do anything about them, why bother? Remember, these are too big for you to control, so pass them up the chain of command. The project sponsor has to deal with project assumptions turning out false (and you can even put in the assumption that they will deal with them). Ignoring them doesn’t make them go away. If a risk doesn’t happen and you ignored it, doesn’t mean it couldn’t have bitten you. If you sail in a dodgy boat and get across the channel, it doesn’t mean you couldn’t have sunk. You were just lucky. Deal with every risk and make sure every risk has an owner.

Test driven planning

Test driven planning uses the same approach as test driven development to craft and know when your project plan is complete.

Test driven development

Any coder, no matter what the software, should always do test driven development. Why? Because it makes you think about the program and all the things that it needs to do. It helps you:

  • Understand the full scope of the program
  • Draw out the questions that need to be answered
  • Highlight areas of complexity
  • Understand the programming patterns to use

Only when you have a complete picture should you begin to code. The tests, in effect, become the specification for the program. Once the program passes the tests, you are done.

Test driven planning is the same.

How it works

You draw up a list of 'tests' (a checklist) your plan must pass before it is complete. This works equally well for a product backlog. Typical tests you might include:

  1. Is the full scope of the project included?1
  2. Are all the risks and their resolving actions included?2
  3. Have all the people and resources been identified?3
  4. Is every task covered by a real person?4
  5. Is there sufficient contingency for unforeseen events?5
  6. Has the critical path been identified?6
  7. Are people on the critical path covered in case of illness or loss?7
  8. Is there time for meetings and non-project activity?8
  9. Are people's holidays included?9
  10. Have several people and your team checked the plan?10
  11. Does it meet the project's constraints?11
  12. Has project management time been included?12

Hopefully, you get the idea. Do not release your plan into the wide world until it has passed all the tests. You wouldn't put untested software into production. A plan is the same.

  1. Work back from a finished product to identify all the things that need to be done. This includes not only the use cases/stories but also all the technical activities, user acceptance, documentation and so on. ↩︎
  2. Risks will bite you if you do nothing about them. ↩︎
  3. Not generic resources but real people. ↩︎
  4. Find out now if you have a resourcing problem. ↩︎
  5. Or suitably hidden, so some management genius doesn't take it out! ↩︎
  6. How fast you can really do it. ↩︎
  7. Very important if one name appears frequently. ↩︎
  8. The best you will get is 80% full project availability. ↩︎
  9. Don't go live in August or Christmas, nobody is a round. Allow for slow downs over these periods. ↩︎
  10. It is not your own private work of fiction. They need to buy into it. Better is to have everyone involved in drawing it up. ↩︎
  11. If it misses a must hit deadline or overspends, you need to go round again and work out options. ↩︎
  12. For big projects, there can be project office staff. ↩︎

Frustrations with markdown editors

I have a simple need - to have markdown work flawlessly on both MacOS and IOS. There are many flavours of markdown and I like to use Multimarkdown (MMD) as it is the most comprehensive. My use cases are:

  1. To be able to have inline images with the text1
  2. In preview, to be able to navigate to other markdown notes by clicking local2 or wiki links
  3. To support the same style of metadata (and hide it in preview) - either YAML style (separated by dashes) or MMD style (top of document with a blank line)

There are lots of markdown editors, but many either have their own flavour or support CommonMark (e.g. Typora) and don't have the full coverage of Multimarkdown but even this doesn't support Wiki links. Wiki Links are often a feature of individual editors.

Editor Local links Wiki links styles on image links MMD meta YAML meta IOS MacOS Flavour
IA writer No Yes Yes No Yes Yes Yes MMD
Typora Yes No No No Yes3 No Yes CommonMark
ByWord No No Yes Yes Yes Yes Yes MMD
Macdown Yes No No No No No Yes Hoedown
Marked 2 Yes Yes 4 Yes Yes Yes No Yes MMD
VSCode Yes No No No Yes No Yes CommonMark
MMD Composer No No Yes Yes Yes No Yes MMD
1Writer Yes Yes Yes Yes No Yes No MMD
DevonThink Yes Yes Yes Yes Yes? Yes 5 Yes MMD
Obsidian Yes Yes No No Yes Yes Yes Obsidian

TextMate - uses Marked 2 for preview

My current set up is to use either DevonThink or Marked 2 on MacOS with MMD style metadata and 1Writer on IOS. My markdown documents are in the iCloud 1Writer folder and indexed into DevonThink.

Update June 2022: IA Writer now supports wikilnks but local links remain a problem.

  1. I find html embedded in markdown ugly and it makes the document difficult to read. Multimarkdown has a good solution using reference links with styles - [image ref]: \path_to\image.jpg style="float:left; width=50%;"  ↩

  2. Local is where the link reference is [document name](\path_to\ not a http reference  ↩

  3. Shows as greyed block in preview  ↩

  4. Using custom pre-processor  ↩

  5. Documents have to be in a Devonthink database replicated to Devonthink to go  ↩

Why I switched to Obsidian from Bear.

When I first got the Bear app, I loved it. The beauty of the interface wowed me. I soon started entering all my notes and used it as my main note keeper. As it grew and I used it, cracks started to appear.

My frustrations with Bear

1. No note locking

The first one was the inability to 'lock' a note to prevent accidental update. This became very irritating for all the recipes I had stored in Bear. While cooking, using my iPad, it was too easy to enter edit mode when scrolling a recipe and accidentally change something. I don't want to change those notes. Why can't I lock them?

2. No high-level separation

As I added more notes, my second gripe surfaced. There was no higher level of organisation. Evernote, OneNote, DevonThink and many other note apps have a top 'notebook' separation. I could have a notebook that only contained my recipes and their related tags. In Bear, everything was jumbled together, creating a very long list of tags that was soon unmanageable, especially on my iPhone. Bear's answer to this is nested tags. I tried arranging my tags into hierarchies like '#cookbook/meat' but this fell down as searching using a screen keyboard on iPad or iPhone involved too many clicks to switch between the various screen displays. There are wildcards you can use but these are equally tedious to enter. Anyway, for me, tag hierarchies rather break the point of having tags and their purpose of helping to find things. I might want all recipes with '#meat+#summer+#quick'.

3. My notes were locked away in Bear

I have used markdown for a long time and one of the things I love is the ability to access my documents from different applications. A markdown note saved in DevonThink could be accessed from IA Writer or in VS Code. With iCloud sync, they were similarly available in various IOS apps. I am a keen birdwatcher and have copious notes on bird identification and on what I have seen. This has built into a personal bird wiki. I tried setting this up in Bear, but with all my recipes in there too, it was a mess.

4. I couldn't share my notes

My partner is a good cook and it would have been great to have a shared recipe book of notes. Bear did not allow two different apple IDs to access the same set of notes. I could export them, transfer, and then import them regularly into her version of Bear, but this soon got tedious and you could guarantee the recipe for tonight was one I hadn't copied yet. I would also have to remember to re-transfer any recipe I had amended.

5. I could only look at one note at a time

Back with my bird notes wiki, I often wanted to see more than one note at a time in order to compare two similar looking birds when out in the field. Bear only displays one note at a time. This was not a real killer as, provided I had added backlinks, I could quickly switch between notes, but it added to my frustrations with the Bear app.

My move to Obsidian

Initially was I wasn't overwhelmed with Obsidian. I found it a bit clunky and couldn't see any point in having the note graph other than it looking pretty. It did, however, have features that made me want to persevere.

A. Preview locked notes

Switching between edit and preview mode on a note has stopped me accidentally amending my cookbook when merrily cooking dinner. The ability to lock notes is more important than you realise, especially when you have a cat that likes walking across your keyboard when you are away making a cup of tea.

B. Vault/notebook level of organisation

My cookbook is in its own vault (Obsidian's equivalent to a notebook). Only tags relevant to my cookbook show up there making it a dream to find things. Similarly my bird notes are in their own vault with a completely different set of tags.

C. My notes are outside Obsidian

My partner can now share my cookbook (and doesn't even have to use Obsidian). The cookbook vault is on a shared drive (I use OneDrive) so both of us can add, amend and get the latest copy of everything. A single unified cookbook for us. I can maintain my bird notes wiki in a dedicated folder through Obsidian, or any other markdown editor, and view it how I want on my iPad or iPhone. I often capture notes using Drafts and, using its powerful actions, I can fire them into the relevant vault. Best of all, I can secure notes both with Time Machine and version control them with GIT.

D. Workspaces make life easier

I have different workspace layouts for my cookbook to my bird wiki. The cookbook workspace has the note in preview, the related note (recipe) cloud, and the master index all on one screen. The bird wiki has two panes (one on top of the other) to compare two birds at once and works well on my iPhone's screen.

E. It even works on Windows

I can view all my notes on my work Windows PC via vaults synced either through OneDrive or iCloud (using the windows iCloud app). I have the freedom to use Obsidian on my PC or to use other editors like VS code, Typora etc. It has made note capture so much easier and my notes are readily accessible on all the platforms I use.

I really want to love Bear for its beauty, but found it just did not work for me. Obsidian has its weaknesses too, but at least my notes are free to roam in the future.