The Greatest Habit

When in an emotional situation, old advice is to take ten breaths to compose yourself. This is good advice and sounds simple, but it is incredibly difficult to remember to do when a crisis occurs. Too often after the event, we kick ourselves that we didn't take a deep breath or two instead of biting back or getting angry.

It is much better to develop a two-breath habit that you can do all the time. Why two? People will hardly notice the pause. If you are worried about the time gap, start with one. Do it before doing anything. Take two breaths before speaking, before drinking your first cup of coffee, before getting into the car, before anything. Doing it this way soon makes taking two breaths a natural habit without thinking.

Those few seconds will enrich your life. It will let you clear your mind of work and give your children your full attention when they ask a question. It will give you time to stop yourself from snapping back at your partner and avoid that row that should not have happened. It will stop you from shouting back when someone shouts at you and help you stay calm. It will give you time to think in a stressful situation and deliver a measured response. It will give you time to decide if you are going to join in with a colleague's unkind gossip or remain neutral. It will keep on giving.

The greatest habit is to breathe at least once before opening your mouth.

Better Risk Meetings

I have lost count of the hours of my life I have lost in risk meetings where someone has ground through the risk log line by line. Each risk having to be explained in detail, as the description was ambiguous, and then the ensuing discussion (ego fight) over what the probability and impact should actually be and who knows best. Ten minutes later, once everyone had agreed to leave everything as it was, the next risk would go through the same treatment. While all this went on, one thing wasn't happening - nobody was doing anything about them.

Years a go, I came across a useful expression:

Get the frogs off the log

Risk only disappear if you take action. Risk meetings need to be about taking action not grinding through a risk log.

A better approach.

Concentrate on creating action plans and getting these into your plan, sprint log or product back log (as executing any action will take effort).

  1. Before the meeting, get participants to privately identify or brainstorm any risks in their own words.
  2. Everyone presents their risks and these are put on a board or post-its or whatever.
  3. Risks that are the same or have same root cause can be combined.
  4. Triage the risks and decide if anything is going to be done about them. 1 It is important to agree if effort is going to be spent or not. If not, stick the risk in the bin and don't waste anymore time on it.2
  5. For the remaining risks, brainstorm and agree an action plan3. It is important that all stakeholders agree who is doing what and commits.

The action plans should then be fed into the project plan or product backlog 4 as they may have a material impact on the effort or project timeline. The project owner can then decide when or if they are going to spend that effort. Impact and probability can play a part in making that decision.

Where an action plan mitigates a risk, but doesn't completely prevent it, a contingency budget and project plan B should be developed for when or if the risk strikes.

Tackling risks has a cost that needs to be met and be clearly visible to all.


  1. They may already be being dealt with. ↩︎

  2. Participants can bring a risk again to a later meeting, either in a different disguise, or because the project environment has changed and it has become relevant. ↩︎

  3. This may be to remove the risk or to mitigate its impact. Not all risks can be neutralised totally ↩︎

  4. By tagging these you can easily generate a 'live' risk log without the need of a separate list ↩︎

Three Plans

For all my projects, I have always needed three plans.

Why three?

The first is the plan on a page. This one gets used for most reporting and is waved about at project board meetings. The trick with this one is prudence. Only put essential information on it as the more there is, the harder it is to understand. IT consultancies are masters at producing incredible plan pictures that look good, but nobody has a clue what they mean. The things a one page plan should highlight are:

  • The key sequence of events (e.g. sprints or phases to a release)
  • The key milestones (especially the customer's deliveries1)
  • The range of possible release dates (never give a single date2)

The plan needs to be quick and easy to update, so you always have the latest version handy. I find a spreadsheet is good for this. You can use the grid lines to line everything up and then turn them off to look good.

Copy the area needed and paste it as a picture into a slide or document. Always send out your plan as a picture or PDF so people can't fiddle with it.

I have wasted too many hours messing about with boxes and aligning them when doing it directly in a slide software (like PowerPoint). Even worse, if the receiver has their slide size set differently, it royally screws it up.

The second plan is the detailed plan, created in suitable project planning software3. The trick with this one is getting the level of detail right. Too much, and maintaining it becomes a cottage industry. Too little, and important dependencies and schedule risks will be missed. A rule of thumb is to be able to allocate all the resources and have enough detail that it could generate an accurate budget. Also detailed enough to see the impact of adding people's holidays or sudden absences. It doesn't need to go into infinite detail, but enough to feel confident about achieving deadlines. For agile projects, you can roughly pencil in what could go in which sprint and the sequencing of backlog items. A sort of sketched out version of the product backlog. This plan is never shared. The detail would allow people to pick holes, get unrealistic expectations, or have some genius of a manager take the contingency away. It is your private master plan to rule the world. Look after it.

The third plan is the team plan. For a very short horizon, it details what everyone is doing. In Agile, it is the sprint backlog and the burn down chart. In Waterfall, it is a day-by-day team plan.

It is detailed enough to identify within a day, at most, that the plan is drifting. Projects don't overrun because of big delays but from the cumulative effect of lots of little ones4. Slippage must be jumped on immediately and only detail will identify when a tiny slip is happening. This can be as trivial as a delayed meeting or a short network outage slowing work down. Time lost is never recovered unless you work longer hours and you probably do that already. With the amount of change that goes on in a project, a horizon of over two to three weeks is pointless, something Agile projects have recognised for ages.


  1. If they are late, you have the right to change your plan. ↩︎

  2. This communicates that bad stuff can happen (it will). ↩︎

  3. For me, this has been MS project. Do yourself a favour; go on a course and learn how to use it properly. It will save hours of heartache. ↩︎

  4. Brooks, "The Mythical Man-Month" ↩︎

Can Do not To Do

Reading recently, I came across this and it resonated with me:

"To Do lists are not lists of things to do. They are lists of things you can do." (from "The Blank Screen" by William Gallagher)

Too often I have put things on my 'to do' list that I can't actually do because I am waiting on someone, do not have all the information, don't have the tools to do it, etc. These 'can't dos' clog up my day and carry over, making my list get depressingly longer and longer.

I now get rid of them as I am never going to able to do them. I shunt them to a 'someday' file which I periodically review. They could become a 'can do', but more often than not they simply disappear.

A ‘To Do’ List Journey

For most of my long career, I used my own version of the Bullet Journal Method to plan my day using a pen and notebook. It worked well. Each morning I would copy out my Outlook work calendar onto a page, together with my goal for the day, and not more than 5 'can do' tasks to attempt to get done (a 'can do' task is where you have everything you need to do it and are not waiting on anything). I settled on 5 tasks as it gets depressing if, day after day, you see lots of failed completion. I needed to be realistic about what I could do., which is not much on a normal manic, frequently interrupted, working day. I was a project manager after all. If all else failed, and my day got shot to bits, I focussed on just getting my goal for the day done. This was nothing huge and could be as simple as wanting to talk to a team member. Writing out the day's calendar allowed for quick changes with a stroke of the pen rather than lots of mouse clicks. I could re-plan my day in seconds. I also recorded notes or actions against my paper version which then got pushed into the next day or future list when I reviewed everything at the end of my day.

An end of day review was important to identify meetings I needed to schedule, forward plan new tasks, collate notes into my journal, and contemplate how much of a disaster the day had been. It gave me thinking time on how I might handle people problems, work out what I was going to say to them, and cheer myself up with what small victories I had achieved.

A typical day looked something like this:


(Yes, I know my handwiriting is awful)

  1. Days' schedule
  2. Notes
  3. Actions from a meeting
  4. Day's goal
  5. The 'can dos' I would like to get done
  6. The 'to dos' I could do if by some miracle I got the five main ones done
  7. A 'to do' moved to tomorrow
  8. A 'to do' moved into the future
  9. A done one!

Working in an office or at my home desk, it was easy enough to always have my notebook with me. Then everything changed.

I retired.

Carrying a notebook with me around the house and garden soon fell apart. If I left my notebook in the kitchen, by the time I found it I would forget what I needed to put in it. I needed to move to an electronic list as I nearly always had my phone handy.

I tried Things 3 as it seemed simple and looked elegant. It didn't last long. I don't know why now, but I really wanted to be able to have tasks divided into ones I would do in the morning and and ones in the afternoon. You could do it with tags, but tags were a pain to add. Things wouldn't let me put headings in my 'Today' list. I created a workaround with a task labelled '<---- Afternoon ---->' but it irritated me aesthetically, really jarred for some reason.

Then I discovered Noteplan. It had recently been launched and I loved that I could almost reproduce my bullet journal and have the morning/afternoon the way I wanted. Having my calendar right next to my 'to do' list also won me over. Noteplan has one weak feature which is repeating tasks. There are two ways round this. For repeats with a big time gap or odd pattern, I put them in my calendar as an 'all day' event. There weren't many of these, so they didn't clutter my calendar up. Calendar apps allow for all sorts of crazy repeats and you can copy them off the calendar view within Noteplan. There is an arguement that all repeating tasks should be in a calendar rather than on a to do list. I am not convinced. For repeating tasks that happen, say, every Monday, I created a Monday template that had them in and used that as a base for my Monday list.

I happily used NotePlan for over a year. Like all good apps, it was continually developed. In other words, it got more complicated. Some good stuff like year lists, quarter lists, month lists, and week lists. I found all this additional whizzy stuff started to clutter up the interface. And, as most of my use was on my iPhone or iPad, it got in the way. I also have fat fingers and found tasks were regularly toggling between done and not done if I didn't press in precisely the right place. It started to annoy me.

Time for a rethink.

What did I really need my 'to do' list to do? Was the dividing stuff into morning and afternoon that critical (as morning things frequently spilled into the afternoon)?

It is always worth having a step back and really thinking hard about what you need an app to achieve, rather than what bells and whistles it has. The lure of bells and whistle to a techie can be overwhelming.

I experimented with going back to Things 3 and ran both in parallel for a few weeks to work out which annoyed me least. I found there was much of Noteplan, the note part, I hardly used. Retired, why did I need to have meeting notes? All my useful reference stuff is stored in DevonThink as it handles a wide variety of document types and is not limited to text. I am techie enough to write most of my own notes in markdown, but everyone else sends me their stuff and it isn't (like my car insurance documents).

Things3 won, for now. Recurring tasks are easy, though week/month planning is not so good. I still hanker a little after Noteplan.

Finding stuff

I have always had some sort of folder system for holding all the bits of information, project documents and important personal details. However, it was always a nightmare to find anything, particularly if it was a year or two old (like that really good CV I wrote or my killer project plan). I would end up doing a global search and painfully trawling through the many results. A huge waste of valuable time.

A while back I came across the Johnny Decimal system and the logic of it appealed to me. In his system you divide everything into ten or fewer areas and these areas into categories, giving you a two-digit number. Finance/Tax would be 11 (the first digit saying it is in the finance area and the second digit is the category of tax). Subfolders for tax (say the years) are then given a sequential number so you end up with 11.01 representing tax for 2019 (or 11-01 as computers often hate periods in filenames). For more details please visit the website.

I dutifully created a big mind map of all the types of stuff I wanted to squirrel away and quickly found that this was the Achilles heel of the Johnny Decimal system (or at least my interpretation of it). You can make it far too complicated and have a lot of folders. The big problem with a lot of folders is:

When you have lots of folders, a new item can often belong in several places.

Retrieving an item was no easier either, as what I was looking for could logically be in multiple locations too. Remembering the numbers (what 10.01 was) also became a big problem and I had to frequently consult my mindmap for reference, which rather defeated the objective of an easy-to-find organisation system.

More recently I came across an article where the person explained his simple implementation of the 'PARA' system. All folders for his projects started with a 'P', his areas with an 'A' etc. I had a lightbulb moment. Why not use letters instead of Johnny's numbers? At the same time, it became obvious to condense everything down into the PARA sections, ending up with four top folders rather than the potential Johnny Decimal's ten (I had eight). It simplified things a lot. For example:

  • PW for work projects (Projects Work). I could then either number or name the subfolders for individual projects
  • AF for my finance area (Area Finance)
  • AP for my personal area (Area Personal) with health records, family details and the like
  • RN for general notes (Resource Notes)
  • RS for software resources (Resource Software)
  • ....and more

Best of all, I could remember them! It was better but I still had too many potential locations where I could file something new. The answer to this was to think carefully and create a very flat structure with as few folders as possible. The good old keep-it-simple principle. Originally I had a group of folders like:

  • AF-Tax (in a true JD hybrid this would be AF-01 Tax)
  • AF-Invoices
  • AF-Statements
  • RS-Devonthink
  • RS-Affinity
  • RS-Java

This, on the whole, did work but, looking at the folders, some only had one or two documents in them, which seemed a waste. I could simplify it further. What I do now is put all things to do with finance in AF-Finance. Yes, one big bucket. I use tags to label the 'type' of a document- #tax, #invoice, #statement and can use this to filter things down quickly. Similarly a single RS-Software folder with tags for the type of software. You might want to keep subfolders. My big mindmap is now much smaller and easy to understand. I hardly ever look at it.

The last A of PARA is 'archive'. I generally have an end-of-year routine where I move things into an archive for that year. Projects, once finished, go into the year in which they started. What I decided to do was to keep my two-letter designation of a folder when I moved it into the archive. Project PW-21 Client X Warehouse stayed as 'PW-21 Client X Warehouse' when I moved into the 2022 archive. How did this help? For every year in my archive, there will be AF- (finance area) folder(s) with all financial information for that year and PW-xx folders for every finished work project. I can globally search for 'AF-' and get all finance folders for all years. Similarly 'PW-' will give me all completed work projects by the year I started them.

This is my simple hybrid of PARA and JD with area/category letters rather than numbers. The key is that a folder carries its two letters (and number - if being a JD purist) where ever it goes or whatever application it resides in.

Showstoppers

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\document_name.md) 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.