GTD = Just Enough Structure

Last week I was able to attend a webinar given by Dan Pink, author of Drive: The Surprising Truth About What Motivates Us .  He's started a new webinar series called "Office Hours", in which he and a special guest just take questions the whole hour, much like a professor's office hours in college. (You can listen to past episodes, such as Seth Godin, on the Office Hours page.)

The special guest last week was none other than David Allen, the Getting Things Done guy. It was a funny and informative hour.

One of the best discussions of the hour was about what tool to use to implement GTD. Dan was impressed by how the system itself is "tool agnostic" -- it doesn't matter what tool you use as long as you are comfortable using it.The key thing, he said, is to get stuff out of your head and decide what it means.  David said that until you get it all out of your head (capture) and then be very discrete about each item and what to do about it (processing), the rest of the system doesn't matter.

"I'm running across a lot of high tech people who are going back to paper, because paper is a good way to keep track of stuff running through your head," David said. The computer can be a dangerous animal, he added, because out of sight, out of mind. A computer screen or PDA screen cannot display all the relationships you have to keep in mind all at once.

Someone suggested using a database system, and while David was supportive of anything that works for you, he cautioned that if it's too much work to keep the system up, you won't use it. This was the key takeaway from the session for me, because I tend to over-engineer things. 

"GTD needs to be just structured enough, but not so much that you have to think too much, or you won't use it when things get fast-moving."

On Resiliency

This is the first post in what I hope will become a series on Change Management. Wikipedia defines Change Management as "a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state." In this series, I hope to examine and reflect upon those factors that help us survive change well, without becoming too disfunctional in the process.

I first became interested in Change Management when I was working for SQLSoft+, a Microsoft Certified Gold Partner for Learning Solutions.  (They've since been acquired by QuickStart ). Microsoft was rolling out something called Microsoft Readiness Framework, a tool for assessing an organization's readiness to implement Microsoft solutions. Although MRF never really took off like its sister, Microsoft Solutions Framework (which in turn has become an Agile-based, scrum methodology), I found the MRF training valuable. The training was conducted by Linda Hoopes, who now heads Resilience Alliance in Atlanta, GA, and was based on the work of Daryl Conner, author of Managing at the Speed of Change, and the founder of Conner Partners, Inc.
When I was writing for TechRepublic, I wrote a Change Management Primer based on an interview with Mr. Conner.

I really like Linda's list of seven Resilience Characteristics: traits that people with a high degree of personal resilience seem to have.

1. Positive: The World - Resilient individuals effectively identify opportunities in turbulent environments.
2. Positive: Yourself  - Resilient individuals have the personal confidence to believe they can succeed in the face of uncertainty.
3. Focused - Resilient individuals have a clear vision of what they want to achieve and use this as a guide when they become disoriented.
4. Flexible: Thoughts - Resilient individuals generate a wide range of ideas and approaches for responding to change.
5. Flexible: Social - Resilient individuals draw readily on others’ resources for assistance and support during change.
6. Organized - Resilient individuals effectively develop and apply systems, processes, and structures when dealing with change.
7. Proactive - Resilient individuals initiate action in the face of uncertainty, taking calculated risks rather than seeking the comfort of the status quo.

In the training we learned that when the amount of change a person is faced with exceeds their their capacity to change, they become dysfunctional in various ways: actively resisting the change, passively resisting the change (sabotaging), freezing up (procrastinating), or seeking a return to the old status quo. This slows adoption of the change and also creates stress within the individual.

Sometimes, an organization doesn't understand the cumulative effects of change. Different parts of the organization propose a number of initiatives, each one reasonable in itself. But the targets of the initiatives -- those being asked to change -- experience the combination as beyond their ability to absorb.

Change Management is a process of consciously addressing the impact of change upon people, both individually, and as a group (teams and organization-wide). It is a vital, but often ignored, companion to Project Management.

Google Apps Migration

I'm midway through a migration of my GTD system to Google Apps. It's been a bit of a challenge. Here's what's been accomplished so far, Phase 1 was to migrate my electronic services:

• Migrate domains bwatkins.com and bnlventures.com to new registrars. My old registrar was the same as my hosting company, and it turned out I wasn't able to create custom DNS records with them if I also didn't host my email and website with them. This was more stressful than it needed to be, because I had taken the time to talk with their support staff and was assured I could still control my domain on the free parking account. They were wrong.  Or maybe they just didn't have the same definition of "control" that I had.
• Migrate email to Google Apps Mail.  Their free level of service now includes custom domain names, so I could keep "@bwatkins.com" for my email addresses. On the old service, I had actual mailboxes for various uses; on Google Apps Mail I just created aliases for all of these but my main email address. I only created all those boxes as an anti-spam measure; Google's spam filtering seems to be good enough that I don't need to do that any more.  I'm slowly working through the list and changing my address at various sites to use my primary again.
• Migrate blog from Typepad to Blogger. This, too, was a challenge, until I discovered a tool that let me convert my Typepad export file to Blogger format. I was able to import most of the content including comments.  I imported without publishing, then went through the posts to decide which ones I wanted to leave behind.

I'm currently in Phase 2, which is to convert my paper planner into Google Apps. Here's what I've done on that:

• Migrate my calendar to Google Apps Calendar.  I now have four calendars to maintain:  my paper planner, my work Outlook calendar, a scheduling system my employer uses (which doesn't sync with Outlook so I have to do that manually), and now Google Apps Calendar. I spent the better part of a day synchronizing all four. I also jotted down some process notes on what to do when changes happen. Four calendars is insane: but it will get better.  I'll eventually replace the paper planner with occasional printouts from Google Apps Calendar, and I've been told that the scheduling system will eventually be able to auto-update Outlook.  So I'll only have two.  I wish it could be one, but given my employer's policies, it's not gonna happen.
• Migrate my GTD review lists -- Projects, Someday/Maybe, and Waiting -- to Google Apps Docs. I typically only review these once a week, so it wasn't a big impact on my daily workstyle to move them. Bonus: I can now review and update them while on the road; before they were in Excel documents on my desktop at home.

The hardest part of Phase 2 is still ahead: migrating my Action Lists. Although some say that Google Apps Calendar's task list is not powerful enough for GTD, I like the minimalist approach of simple lists. I've created separate lists for each GTD context ("Calls", "Errands", etc.). My next step is to dump all the items in my paper Action Lists into this structure.  I don't know if I will feel constrained by having to be online to look at my action lists. I may have to do an occasional printout of them. I'm not sure how this will work, and it may be that I'll have to re-engineer this later.  But I want to try the simple way first.

Phase 3, and where this is all heading, is that I plan to upgrade my plain phone to a smartphone in a while. At that point, I'll have all this information sync'ed on a regular basis and be able to carry it with me. The work I'm doing now may seem odd from a paper planner viewpoint, but it is laying a foundation of moving all my planning information from PC to the cloud, so once I get the smartphone it will all be in place and ready to switch over.

Database Sharding

I discovered a new term today, via a useful post on Julian Dontcheff's Database Blog (which I also discovered today). His post, Do not go beyond this point: on the "obvious advantages" of Database Shards, succinctly describes what database sharding is, and even better, points to three resources for deeper study.  He writes:

Caution! Database Sharding is like the anti-consolidation of databases. It is splitting the database into many small databases. You spend years and years on trying to unify and gather together databases and all of a sudden you are told that there is an application managed scaling technique using hundreds of independent databases. Tricky, right?

Sometimes, when planning database solutions in terms of scalability and massiveness, going beyond a certain point might be risky. This is the case when database shards may be of huge help (big website used globally). The word shard may sometimes refer to a piece of glass, a sea glass that can be found almost everywhere, for example at the beaches near San Francisco.

I share his amazement that after years of listening to vendor sermons on the benefits of server consolidation, now there's talk about going the opposite direction. Whatever happened to "green" in the data center?

He also makes the excellent point that proponents of standing up many servers with small databases typically ignore database licensing fees, which are typically charged per server (sometimes per core).

Anyway, good read.

Always Learning - Rebooted

I've just spent a painful few weeks with my blog down as I changed hosting companies. But Always Learning is back, with only minor changes.

I dropped the Business Travel Tips category, and also removed some of the older announcements that are no longer relevant.

Another announcement is that my business, B. Watkins Database Training and Consulting, is no more. The domain name bwatkins.com has reverted to my personal use. Email addresses should all still work, and the blog will continue to be at this address.

I have plans for new articles on areas of personal interest, such as resiliency, change management, training, Getting Things Done (GTD), and of course, Oracle.  Please stay tuned!

My Outbox

I've had an IN box for as long as I can remember. But it's only comparatively recently (a year or so) that I've had a formal OUT box. Here's what I've discovered about using it.

It's not actually a box or tray, like my physical IN box. Rather, it's more of a "landing zone" on top of the printer stand - a designated bit of clear space which, in my mind, carries the label "OUT".

When something needs to go out of my office, I put it there. Bowl from this morning's cereal? OUT box. Completed expense reports that need to be mailed? OUT box.  Mail that needs my wife's attention instead of mine? OUT box.

In the same way that a pad of paper lets me capture thoughts without acting on them immediately, the Out Box lets me stage items that need to be moved somewhere, without interrupting my flow of work. I can let go mentally of the thought that this item needs to be put away. When I do want to take a break and stretch, all these "somewhere else" items are in one place so it's easy to scoop them up and walk them to where they need to be.

What I DON'T put in the OUT box are things "to be filed".  I've learned that that doesn't work. It grows without bound, and then OUT is useless because it's cluttered.  I file most things immediately, though I'm ashamed to say there's still a bit of a TO FILE pile that needs attention.  (It's on my "IN OFFICE" action list to clean that up.)

So, the two habits I'm working on right now have to do with comings and goings: (1) when I enter my office, I need to toss any notes I've taken into my In Box for processing; and (2) when I leave my office, I need to check the Out Box to see what can be delivered elsewhere.

Simple things, but they help.

Most expensive training vehicle?

I was listening to the replay of a webinar by datango AG and Neochange about trends in end user adoption of IT applications. One comment really grabbed me:

"With the average cost of a help desk call hovering between 35 and 45 dollars, that's your most expensive training vehicle."

It reminded me of the Fram oil filter slogan quoted often by David Allen:  "You can pay me now, or you can pay me later."  If companies don't invest in training up front, they'll pay more on the back end in help desk calls. But one way or another, there will be a training cost. It's not optional.

Overall, the survey question, "% of Application Budget Spent on End-User Programs" revealed that most of the money spent on end users was skewed to new users (End-user training for new hires) and "laggards" (Help desk support).  Power user support for other users and a self-help knowledge base were second, and Perodic Refresher training for all users was last.

But companies that had a higher than average investment in end user training also had the highest adoption rates - go figure!

The survey can be downloaded from the Neochange link above.