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.

1. Scan the patient’s bracelet.
2. Confirm the patient’s identity.
3. Scan the medication bar code.
4. Confirm the choice of medication.
5. 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?

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:

1. To define the profession of business analysis
2. To serve as a baseline that allows
   1. Business analysts to discuss what they do in common terms
   2. Training and certifying bodies to ensure that business analysts attain the skills they need to be effective
   3. People who work with and employ business analysts to know what to expect from the latter
3. To provide a framework for
   1. A normative description of business analysis tasks
   2. 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

tags: BABOK

Posted from Diigo. The rest of my favorite links are here.

There appears to be a serious lack of expertise in play, exacerbated by a philosophy that the clinician should adapt to the software instead of the other way around. Good software must be a solution for a problem, and if the problem is not understood by the developer, the software cannot ever hope to succeed.

This is a pointed observation, similar to ones I’ve heard on numerous occasions. It seems to me that the only way this is going to change is if the stakeholders who buy and deploy health care information systems assert or reassert their prerogative to design systems that meet their needs.

1. The fundamental issue is communication, not documentation.
   Right on. No need to document the obvious. And, with good design and user interface, what stakeholders need should, for the most part, be obvious.
2. Agilists write documentation if that’s the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation.
   I understand these better ways to include good system design, good user interface, and other ways of communicating with stakeholders, such as live training and support.
3. Document stable things, not speculative things.
   This point hits on timing of documentation activities and counters the tendency in some quarters to overdocument the development process itself.
4. Take an evolutionary approach to documentation development, seeking and then acting on feedback on
   a regular basis.
   Right on. Documentation is not written in stone. We could even extend this idea to include support for interactive documentation, some of which is contributed by stakeholders themselves during transition or production phases, as the need arises.
5. Prefer executable work products such as customer tests and developer tests over static work products such as
   plain old documentation (POD).
   Again, the focus here is to counter the overdocumentation of the development process itself. We could, however, extend this idea to the creation of executable documentation systems that include both dynamic information from the run time system and interactive documentation creation features. One of the reasons why documentation is often less than useful is that it is not integrated with the run time system that stakeholders need to interact with.
6. You should understand the total cost of ownership (TCO) for a document, and someone must explicitly choose
   to make that investment.
   Again, this point counters any tendency to simply follow prescriptions as to what documentation is needed rather than to agilely determine the specific needs for your project.
7. Well-written documentation supports organizational memory effectively, but is a poor way to communicate during a project.
   Right on.
8. Documentation should be concise: overviews/roadmaps are generally preferred over detailed documentation.
   Right on, in keeping with the principle to assume simplicity.
9. With high quality source code and a test suite to back it up you need a lot less system documentation.
   Right on.
10. Travel as light as you possibly can.
    Right on.
11. Documentation should be just barely good enough.
    Right on. This should nip in the bud any tendency of technical writers to make finely crafted topics an end in themselves.
12. Comprehensive documentation does not ensure project success, in fact, it increases your chance of failure.
    This point has no bearing on stakeholder documentation delivered as part of the system.
13. Models are not necessarily documents, and documents are not necessarily models.
    Nor does this point.
14. Documentation is as much a part of the system as the source code.
    Here is a point that I would like to see prominently at the top of the list.
    One of the necessary implications of this point is that you need to develop documentation for stakeholders with all of the skill, care, and agility that you devote to the rest of the development process. You should also integrate documentation into the run time system as much as possible, rather than deliver documentation that is both physically distant (in separate files or binders) and semantically isolated (dealing with the generic system, not the one that is actually deployed at my site, with its custom settings).
    Thus, some of the specialties that you need represented on your development team are document engineering, content management, editorial practices, and publication. Contrary to popular belief, documentation is not something just any monkey can do, especially when your system presents the need for localization.
    For a large-scale ecosystem of application development, this point also implies definite input from the environment, enterprise architecture, and software improvement disciplines in the enterprise unified process. Content needs from project to project may vary considerably, but the basic set of channels (online help, support wiki, &c) and components (topics, glossaries, &c) for documentation remain pretty constant.
15. Your team’s primary goal is to develop software, its secondary goal is to enable your next effort.
    Another point whose primary focus is documentation of the development process, not documentation deliverable as part of the system.
16. The benefit of having documentation must be greater than the cost of creating and maintaining it.
    Spot on.
17. Developers rarely trust the documentation, particularly detailed documentation because it’s usually out of
    sync with the code.
    Another point whose primary focus is documentation of the development process, not documentation deliverable as part of the system.
18. Each system has its own unique documentation needs, one size does not fit all. Right again.
19. Ask whether you NEED the documentation, not whether you want it.
    If the you here is the development team, then we need to extend this to include the stakeholders, who also might request documentation just because they think they need it, without demonstrating that need. At the end of the day, though…
20. The investment in system documentation is a business decision, not a technical one.
    The customer gets what the customer pays for.
21. Create documentation only when you need it at the appropriate point in the lifecycle.
    Another point whose primary focus is documentation of the development process, not documentation deliverable as part of the system.
22. Update documentation only when it hurts.
    Good point.

One approach might be to create an innovation zone separate from the actual economy of commercial trading, where traders can test new instruments under the scrutiny of regulators. There should be clearly defined rules for moving these new instruments from R&D to commercial use, including standards for evaluating their claims, authorization for specific uses, and mechanisms for monitoring their effects over time, especially towards the beginning of their adoption. This would allow for innovation while circumscribing some of the risks involved for the broader system.

Rather than play the role of regulator, Ben Bernanke testified yesterday before Congress that the approach of the Federal Reserve would be to shore up the reserves of the investment groups hardest hit by their exposure to these junk derivatives. When pressed on the question of how this would introduce new rules of the game, to change the way these investors did their business, Bernanke evaded a clear answer, saying that the stimulus measures would be accompanied by [unspecified] measures to ensure that the banks and holding companies would over time get back to more sustainable business plans. This is not very reassuring.

Posted from Diigo. The rest of my favorite links are here.