Skip to main content

GTD

In my previous post, I mentioned I have been using GTD. In fact, I’m a big fan of it.

I have worked for many years as a programmer, then as a systems analyst, also as an architect. Of course you have a lot to do in this positions! But it was when I occupied the Project Manager and the Consulting Manager positions that my to do list exploded. It seems that in these positions you substitute some big tasks for a plethora of small tasks. You have some tasks to solve problems with development, another set of tasks to solve problems with analysis, with infrastructure, with architecture, with you stakeholder management needs, with your project bureaucracy, with updates on workplans, with status reports…

Basically, David Allen (the author of GTD) suggests keeping everything out of your mind – you make a mental dump on lists. Then you organize the lists: you identify the “next action” for each item (e.g.: for an item like “Fix the car” you probably have a next action of calling Dad and get the mechanic’s number). You keep these next actions in context lists, so when you’re in “email mode” you can execute a lot of these items.

This is just a quick overview. You have to read more about it to start understanding its power.

GTD is particularly well suited for this situation: managing a lot of items while maintaining focus. I suggest you to learn a little bit more about its principles:

  • “Getting Things Done” by David Allen is the bible of the method;
  • www.davidco.com is David Allen company’s website where you’ll find a lot of free material. Read the “coaches’ corner” articles!
  • http://www.43folders.com/ is a very good blog where Merlin writes about personal productivity much based on GTD.

Comments

Popular posts from this blog

TimeTo

I just licensed a new software for my personal organization system: TimeTo . It tries to conciliate your schedule with you to-do list, automatically scheduling your tasks based on priorities and deadlines. It has helped me in maintaining the concentration on what I’m doing at each time and how much time I spend on doing each type of task. Additionally, I have a very powerful way to complete my timesheet. I can tell you exactly what I was doing at a specific time in the past. It is not easy to conciliate it with GTD and I still keep my lists on my Palm but I have improved my focus and I’m achieving more. I suggest you to give it a try.

An experience in customer care

After some months desiring a DVR (VCR-like equipment with a high capacity hard disk) I found a Sony HDD250 for 20% of the regular price in a prestigious US store. The price was due a small scratch and a missing manual. I bought it! Back to Brazil I downloaded the manual and installed the cables but…the remote control did not work - it was of another equipment. OK, I should have noticed that but… I was VERY frustrated. The wrong side of customer care: 1. I wrote BestBuy. In a canned answer they suggested me to phone the store attendant or returning the equipment. They neither tried to understand my problem. 2. I talked to Sony (I have two of their “universal” remote controllers). Answer: if the code was not in the manual I could not operate the DVR. They suggested me buying a replacement control from a company that …did not sell it. In another demonstration of “customer care”, their product forum has many complaints about not being possible to manually setting the clock - and no answer

Priorities & MoSCoW

One of the most important tasks a PM has on a software development project (maybe in all projects) is setting priorities. Usually time and money is shorter than everybody would like and you have to choose what to develop and what not to develop. It takes communication skills, a lot of negotiation and, at the end; everybody is a little bit frustrated… If your team is developing software iteratively and incrementally (and you should… but that’s a theme for another post), you have to prioritize each iteration sub-scope. To make scope more clear, at my company we adopt the MoSCoW list. I believe it originally has roots on DSDM (although it is used similarly on SCRUM, UP and it has elements of Cockburn’s actor-goal list) and it is a very powerful tool. Simply stated, it is a list of requirements (or actor-goals, or use case titles…) each one prioritized with a letter MSCW (Must, Should, Could and Won’t – that’s the origin of MoSCoW list name). I simplify the explanation to my clients, key-u