Recently I mentioned Inbox Zero, a method of keeping your email inbox organized and uncluttered. Another useful organizational method I practice is what I call “Paper Zero”. Paper Zero is not using zero paper; instead it is a commitment to:
- Organize the papers you have
- Throw away transitory papers (recycle if possible)
- Transcribe important papers into an electronic format (and then throw them away)
I use a good amount of paper at work while doing such tasks as taking notes during meetings, jotting down mental reminders while debugging or marking up project schedules. So I am not anti-paper; until we all have take anywhere, instant on tablet computers with the visceral feedback of pen on paper, I will not abandon my notepad and trusty Pilot G-2 Gel pen (size 07 usually). Sometimes ad-hoc notes, sketches and diagrams are a necessity. In addition, for the sake of my eyes, I don’t like reading long documents on the screen. So printouts can be handy as well.
There are however, many problems with paper. First, its physical dimensions. Papers quickly pile up, cluttering your desk and closing your workspace in around you. Second, paper is inherently volatile. Papers can be torn, ripped, spilled on and just plain lost. Third and perhaps most importantly, papers are inherently information silos when compared to electronic documents. Papers are hard to organize, hard to search, hard to relate to other documents and for the most part single user experiences.
Digitizing your notes is not a revelatory suggestion and the benefits of having your information in an electronic format should be pretty apparent. A typical objection to applying this idea to notes at work is that as notes they are not important enough to spend the time transcribing into digital documents. My response is that they if they are so unimportant, why don’t you toss them and save yourself the desk/filing space? If they are important enough not to toss, then they are important enough that someone else should be able to know about them. Based on my handwriting at least, that implies electronic format.
Another way of looking at that question is to ask could someone pick up on your tasks where you left off from if you were unexpectedly sick or out of the office? No such transition is ever perfect, but it would certainly be helped if the other person doesn’t have to try and decipher your hand writing and filing system. If you are deliberately keeping important information to yourself to be more powerful or save your job, well then you need more than Paper Zero to help you. At least in my field, we value problem solving and effective information sharing, not hoarding.
The final benefit of transcribing important notes into an electronic format is not immediately obvious. When you transcribe notes, which were written while you were thinking about a certain situation with the entire context already loaded into your mind, you are forced to lay out your thoughts logically, exposing your assumptions and gaps in knowledge.
So even if you don’t care about anybody else, by transcribing your notes you can be more effective and have a better grasp of your subject material. In fact, this technique was frequently suggested to me by various college professors as a way to better understand and retain material prior to an exam. I didn’t always follow this advice, but the concept of it stuck with me and has proved useful outside of the classroom, in the quotation mark surrounded “real world” of the workplace.
If you’ve worked on a software development project, there is a good chance you’ve either used or done everything to avoid using Microsoft Project. I avoid MS Project when I can and have developed my own Excel-centric task management system. However, as my system grows to meet the needs of my projects it is eerily converging on Project itself. Is there any escape or I am bound to run so far away from Project that I run right back into it again?
A complete project in MS Project is in many ways a thing of beauty to behold. Tasks are joined to resources, timelines and other tasks as dependencies. You can adjust someone’s allocation and watch the timeline warp and wriggle in response. You also have the comfort of being able to produce solid, comforting diagrams which show your progress and plans to your non-Project blessed co-workers. Then your project moves along just as you planned, with satisfying milestones along the way to the anticipated successful solution.
With these happy sentiments in mind, why did I spin up my own system for task management and project planning? There are 2 major problems I see with Project, the “buy-in” cost and adaptability. Buy-in cost is the amount of time and effort it takes to get your project into MS Project. Project planning is important, but the mechanics of entering your tasks, setting up resources and linking up dependencies is quite clumsy. By itself however, the buy-in cost would be a reasonable investment if it were not for the second major problem with Project, adaptability.
Changing out resources, redefining tasks and dependencies, adding or deleting entire chains of tasks happens all the time during projects, yet represent great pain points in Project. I remember a specific project I was on where a failed attempt to change a few dependencies cost my project manager literally days to recover from.
Beyond changes to the project itself, Project is restrained in the meta and supporting information you can easily attach to tasks. If you really dig into Project, you can set a lot of this up, but again, based on past experiences, Project does not end up being the definitive source of information about a task. So you have other documents, spreadsheets, etc. which all then try to refer to the tasks in Project, leading to synchronization head-aches and disconnects.
One possible answer to these problems is to spend the time to really learn Project, to deep dive into it and hope to mediate the pain points with your newfound guru status. However, at this point you are likely to be stuck (consciously or not) running your actual project in such a way that matches up with the constraints (and capabilities) of your project management tool.
To avoid this inversion of priorities, I have been experimenting with my own system of task management and project planning. The foundation of my system is Excel and so far it is quite primitive in comparison with Project. Nevertheless, I have enjoyed growing my system to create capabilities I find lacking, rather than growing my project to use capabilities I received by default.
I haven’t had to test how my system scales to a large project yet, but even with a small to medium sized project, I do look at parts of Project with envy. I have to laugh when I see my spreadsheet layout inching closer and closer to a Project style look. While MS Project is over weight for my current purposes, it was not developed out of the blue, but in response to certain scenarios that occur while on a project. The problem lies in trying to solve every one of these at once and in the process making solving any of them individually that much more difficult.