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 to my 'To Do' list that I actually can't do. This is because I am waiting on someone, or do not have all the information I need, or don't have the tools to do it, and so on.
These 'Can't Dos' clog up my day and forever carry over, making my 'To Do' list get depressingly longer and longer. I now get rid of them. 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.
I use DevonThink(DT) for my personal knowledge management. DT is extremely powerful and can be used in so many ways. I thought I would offer my simple set up as an example of how I use DevonThink and hope people find it useful.
A good place to start is how I divide my data between databases.
Deciding on databases
It has taken a bit of trial and error to get my databases right, but data is easy to move about in DT on the road to getting it right. The key elements on deciding how to split my information were:
Do I want to sync the data?
Is it an ‘area’ of work where I need everything together?
Does the data share a common tagging schema?
Databases I have include:
Work (used for all work stuff)
Birds (holds lots of notes about my bird watching hobby - the feathered ones)
Newsletter (I write a monthly village newsletter)
Village Hall (I am on the management committee)
Reference (reference materials and personal stuff like car insurance documents, purchase receipts, vacation info, manuals, guides)
Thoughts (collection of quotes, snippets, and ideas)
Cookbook (collection of recipes)
Yes, I could have all in one giant database broken down into major groups as above, but the tagging schemas are different in several databases (see below) and the schemas make sense when in that database. Groups in the databases are generally only two or three deep, and I try to make group names understandable and as unique as possible. It stops (for me) lots of groups with the same name being confusing in a search list.
Do I want to sync the data?
Yes, I know I could sync everything everywhere, but why, when I don’t need it on my iPhone or iPad? There is plenty of room, but why sync gigabytes of data when I don’t need to? I don’t sync Work to my devices as it contains very confidential information. It could be safely encrypted etc. but it is far safer not to have it on my iPhone in the first place. I want Cookbook and Reference on my iPhone for ideas when shopping and insurance details if I have a car accident. Newsletter stays on my MacBook as that is the only place I work on it.
Is it an ‘area’ of work?
An ‘area’ of work is what I am going to be doing when I open my MacBook, drink a coffee, and get going. Work pretty much speaks for itself. When working on the Newsletter, I only need all the newsletter information, like past issues, details for publishing, ideas for future issues, etc. You might argue that Birds could go into Reference, but I have a specific tag schema relating to bird classification and it gives me a classification view from the tag list without lots of other tags messing it up. Another consideration on grouping of data is if I want to use replicants (they only work within the same database)
Does the data share a common tagging schema?
I am a bit OCD and hate messy tag lists. Tagging in Work relates to the type of document (proposal, report, agenda etc.) and its status (final, draft, in review, waiting on someone). Tagging in the Newsletter is the month and the information’s source. For my Cookbook, the schema is ingredients. I don’t want to have pumpkin next to proposal in my tag list, which is why they sit in different databases. For this reason, I do not unify tags but have them listed in each database only. Another reason for not unifying tags is both Village Hall and Work have an agenda tag. Unifying, I got two agenda tags, and I was never sure which was which. When working in a database, it is easy to remember the particular tag schema for that database. Not keeping to a tag schema ends up being ‘garbage in, garbage out’ and having difficulty finding anything based on tags. Was it tagged vacation or holiday?
Workflow
Now I have my databases, how do I get information into them and process it?
The Global Inbox is my clearing house
All new information, whether from my iPad in DevonThink to Go (DTTG) or DT on my MacBook, gets sent, shared or dragged into the Global Inbox. Smart rules based on a tag then move it into the Inbox of the appropriate database for processing when I am working in that ‘area’. I can add these simple tags in the sorter when clipping, when saving in finder, when sharing to DTTG, or in the Global inbox itself.
Simple Smart rules
Simple smart rules look for the simple tag and move the item into the correct database, deleting the tag as soon as it is moved. So tagging an item newsletter moves it to the Newsletter Inbox. Similarly, cookbook into Cookbook.
The local DB Inbox
When I am working in an ‘area’ and have that database (and usually the Reference DB) open, I will further process anything in the database’s Inbox. Workspaces can be your friend here for opening what databases are needed (or just have the lot open). If you put a database in favourites and it is closed, clicking on the favourite will open it.
Items in the database’s inbox might be further tagged, moved into the right group (using the move shortcut ctrl-command-M or using ’see also & classify), or discarded to stop the garbage pile getting too big. On some databases, like Work, I have a few additional smart rules that try to auto tag based on the file name and/or contents when the item arrives in the database inbox. This allows for targeted rules appropriate to that database. For example; if the name contains ‘plan’ it is tagged plan. I did get excited with trying to automate as much as possible based on content, but got a lot of ‘false positives’. A report from someone might reference a ‘proposal’ and got tagged proposal when it wasn’t. Sometimes, human oversight is the fastest way to do it right.
There are lots of examples on their forum where people use rules to rename bank statements and such things when scanned.
My end of year review
Over the Christmas period, with a beer in hand, I will go through some of my databases (particularly Reference) and decide what can go. I don’t need the car insurance documents from three years ago or the manual for the old fridge. Doing the occasional review is good for keeping the garbage in check. It makes searching more efficient if the results list is not filled with irrelevant stuff. I think of my databases like my house. I don’t want them to look like the worst hoarders home on TV, with piles of old newspapers and junk everywhere.
In Summary
Overall, my workflow is simple. When I have an item and save or share it, I add a tag for the ‘area’/database it needs to end up in. When I am next working in that ‘area’ the item(s) are sitting in that database’s inbox, waiting for final review and processing. The final review stage doesn’t take any time, ensures everything is correct and, importantly, makes me think “do I really need this?”
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.
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).
Before the meeting, get participants to privately identify or brainstorm any risks in their own words.
Everyone presents their risks and these are put on a board or post-its or whatever.
Risks that are the same or have same root cause can be combined.
Triage the risks and decide if anything is going to be done about them. 1It 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
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.
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. ↩︎
This may be to remove the risk or to mitigate its impact. Not all risks can be neutralised totally ↩︎
By tagging these you can easily generate a 'live' risk log without the need of a separate list ↩︎
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.
If they are late, you have the right to change your plan. ↩︎
This communicates that bad stuff can happen (it will). ↩︎
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. ↩︎
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.
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)
Days' schedule
Notes
Actions from a meeting
Day's goal
The 'can dos' I would like to get done
The 'to dos' I could do if by some miracle I got the five main ones done
A 'to do' moved to tomorrow
A 'to do' moved into the future
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.
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.
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:
Put them in project assumptions (you assume they won’t happen)
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 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:
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.
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. ↩︎
Risks will bite you if you do nothing about them. ↩︎
