2010-01-01
Getting Things Done with Remember the Milk
I’ve been using Remember the Milk to help me get things done for over a year now. Recently, I wanted to make the application work better for me while getting back to some of the basic principles of GTD. To start out, I read some of the GTD-inspired posts on the Remember the Milk forum, in particular one by klketom. Through a little trial and error, I came up with a set of tags, dynamic lists, and a process that I’m quite happy with.
To collect
I collect tasks on the Inbox list. This is where tasks go that I send from email or Twitter (through a direct message). When I add tasks directly through the web or iPhone client, I usually organize them right away. Of course, potential tasks also pile up on my desk, in my memory, and on paper notes.
To process
As I process the stuff of my life, I move all clear tasks to RTM. Anything that doesn’t need follow-up I file away or toss out. I add notes to tasks, to be sure I remember why I want to do the task. I add a link to any supporting documentation.
Processing rules include:
- New tasks get assigned to a project or a duty.
- Due dates are for committed tasks, not just random dates. I can, of course, commit myself to a date, without anyone else involved.
- Do the Now list today.
- Do the Next list as time allows.
- Every project has at least one next task (_next).
- Every project tag has one item on the Projects list; these main project tasks reflect the outcome of the project.
- Every project has a due date.
- Due dates are for real, dated commitments. Do not use them simply to mark next tasks.
- Top priority indicates tasks that are not committed but that I want to do right away. This lets me add tasks to the Now list without making spurious deadlines.
- Lower priority tasks get added to the Next list, making them equivalent to next tasks. I know, the markup is redundant; I might not need the _next tag. In practice, I tend to use the _next tag for task sequences, as in projects, while I use priority for duties unrelated to other tasks.
To organize
Static lists reflect the immediacy of actions to take. The lists are static because it takes a deliberate action by me to put tasks on one of them, and a task can be on only one static list at a time.
- Inbox, for new tasks to tag & process; list should be empty after daily processing.
- Tasks, for everything to do that is not on another static list; in other words, these are active tasks that are ready to get done.
- Projects, for current projects; this is really a metalist, or a static list of tasks that each represent a dynamic list of tasks.
- Someday, a holding tank for bright ideas; these tasks are not planned to get done anytime soon.
- Waiting, a holding tank for next steps that I can’t take until an event happens over which I have no control; for example, I’m waiting for a response from someone.
Dynamic lists reflect current work lists based on next actions. The lists are dynamic because based on search criteria [in brackets below]. The application automatically includes only outstanding tasks in searches, so I don’t have to filter on completion status.
- Now, a high priority work list of things to do right away. The search picks up any outstanding task that is due within the next three days, is overdue, or has top priority. [
(dueBefore:"3 days" OR priority:1)] - Next, a work list of upcoming deadlines & next actions; priority is an alternative to next action, especially for duties. The search picks up any outstanding tasks that are due within a week, are next actions, or have priority, except for tasks on the Now list. [
(dueWithin:"1 week" OR tagContains:_ OR (NOT priority:none)) NOT (dueBefore:"3 days" OR priority:1)] - 😮—the oh list, a set of tasks that need prioritization; I go here when I need more to do or when doing weekly review. The search picks up active tasks that have no priority or due date, with the exception of next actions or errands.  [
(list:Tasks AND priority:N AND due:never) NOT (tagContains:_ OR tagContains:@errands)] - 😦—the sad list, for unprocessed tasks, as a safety net for tasks that might slip through the cracks; in review, I clean up anything on this list. The search picks up tasks with no tag, no project, or no duty (in other words, no reason to do them), along with tasks that somehow I’ve tagged as a goal but put on the Someday list; the search excludes errands, which I consider doing whenever I’m out and about. [isTagged:false OR NOT (tagContains:. OR tagContains:+ OR tagContains:@errands) OR (tagContains:gtd-soon AND list:Someday)]
Tags are the drivers behind the dynamic lists. I avoid tagging tasks with keywords that have no corresponding dynamic list.
- Projects get tagged with a period (.); for example, .renovation. Every task related to a project gets tagged, including the task on the Projects list. I define a project as an outcome (as listed on the Projects list) with a due date & multiple related tasks.
- Duties get tagged with a plus sign (+); for example, +citizen. Semantically, duties are any of the many roles I play in society. Many recurring tasks are related to duties.
- Next tasks get tagged with an underscore (_) or gtd-soon. The former is all-purpose; the latter, reserved for explicit goals coming out of GTD review & planning.
- Contexts get tagged with an at sign (@); for example, @phone. Contrary to the precepts of GTD, I do not use contexts profusely to organize tasks, because my GTD system for work is separate. In addition, almost everything I do is on line. Contexts are especially useful for grouping tasks when the active lists get long. I do not conflate GTD context with RTM location, also indicated by an at sign but separately implemented in the application.
2009-07-14
Hard to Use Health Information Systems
At three recent medical visits, the nurse or physician made comments to me on their health information system (the same one). I doubt they knew that I worked in the domain. The thrust of all three of their comments was that their need to interact with the system impeded the flow of their work and the personal attention they wanted to give to their patients. For example, before administering a medication, one has to
- Scan the patient’s bracelet.
- Confirm the patient’s identity.
- Scan the medication bar code.
- Confirm the choice of medication.
- Confirm that, yes, one actually has just administered the medication to the patient.
The caregivers agreed that it was important to keep good records; one of them said that, in her thirty years’ experience, she had always kept paper records. Had she forgotten how hard it was to keep paper records, more often after the fact than at the point of care? Could it be the very length of their experience that made it hard for them to adapt to the use of electronic medical records? Might it be that the technology is still too immature to support ease of use? Would there be a way to make their existing system easier to use, through training, reconfiguration, or redesigned work flow?
2009-05-28
First Take on the Guide to the Business Analysis Body of Knowledge (BABOK)
This is my first foray into the body of knowledge (*BOK) genre. If there’s one thing this guide is not, it’s an invitation to become a business analyst. The text is anything but inspiring. Maybe its purpose is to serve as a source document for the CBAP exam also produced by the International Institute of Business Analysis (IIBA). One needs to become a member of this institute in order to read the guide, if not sit for the exam.
I don’t pretend that the following comments are systematic. They might even show my ignorance of some of the commonly understood backdrop to the profession. You can take them as simple notes on my first reading of the document.
The Good
I like the idea of summarizing the body of knowledge of a profession. It would be interesting to look at the history of the genre and to critique the Guide to the BABOK as an instance of the genre.
The Bothersome
An unresolved tension between the stated purposes of the guide and of the BABOK reveals itself throughout the document. The stated purposes are:
- To define the profession of business analysis
- To serve as a baseline that allows
- Business analysts to discuss what they do in common terms
- Training and certifying bodies to ensure that business analysts attain the skills they need to be effective
- People who work with and employ business analysts to know what to expect from the latter
- To provide a framework for
- A normative description of business analysis tasks
- An understanding of how these tasks deliver value to an organization
The tension between these purposes arises on one hand from the implicit need of this document both to describe and to prescribe the concepts and tasks that a business analyst performs and, on the other hand, from the abstraction of these concepts and tasks from any given theory of organizational behavior or practical methodology.
The text is, on the whole, descriptive of the tasks that a business analyst does. The tone is heavy and overly formal. Excessive use of the passive voice makes for dense and sometimes confusing reading. For example, “It is expected that at some point while performing elicitation that sufficient material will have been elicited from the business experts to allow analysis activities to begin.”
Oddly, in the midst of many of the descriptions, the authors switch to unmarked verb forms, either for fragmentary infinitive phrases or for the imperative mood. This mood switching maintains the confusion between descriptive and prescriptive purposes, with no transition. If some of the text is prescriptive and some of it, simply descriptive, the authors could have more clearly indicated that such is the case. I would expect to find imperative mood rather in procedural writing, which this document is not.
One final point that struck me as I read is the organizational role of the business analyst. The document clearly states that a “business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be.” And, of course, the presumed actor of all of the tasks described is definitely the business analyst, whose profession the authors intend to stake out in this guide. Nevertheless, the authors do not engage in any discussion of the various manifestations of the role of business analyst in different organizational settings or methodologies. What are the advantages of having specialized business analysts as opposed to having the role filled by other professionals? What is the nature of the adaptations that teams need to make to the BABOK to successfully perform business analysis in the full range of possible adaptations? How does one do business analysis in an agile environment?
International Institute of Business Analysis | The Guide to the Business Analysis Body of Knowledge
Posted from Diigo. The rest of my favorite links are here.
Rich Analysis 