I routinely use two tools for knowledge
management: Lotus Notes and Mind Manager. I have long
wished
for a single integrated solution to search desktop documents, Notes databases,
and MindManager maps. Well, it looks like at least one of these wishes
will be granted soon.
The makers of the
X1
Desktop search tool are preparing to add support for Lotus Notes databases.
For the past week, I have been evaluating a beta release (I'm using ver.
5.1 Beta Rel 2, Build 1616zq) of the next generation of the X1 desktop
search tool. I'm really excited about the ability to use a single
search tool to search Lotus Notes databases in addition to the documents
on my local disk drive. Right now, the search functionality is limited
to mail databases, but I'm told that there are plans to add support for
any Notes database. When that happens, it will represent a significant
productivity boost for users of Lotus Notes.
One of the strong features of X1 is their support for a variety of document
types; they have extended this functionality to searching text information
stored within Notes as well. So far, my testing has gone reasonably
well; well enough to continue working with the product. Currently, there
is no indication in the returned search results display which database
the result came from, however, the basic mail folders are shown.
I would really like to see support for multiple databases -- at least
email, discussion, and doclib. I've worked out a way that this could be
done. Hopefully, they have, too.
All in all, it's been a good experience so far and I plan to continue working
with the product as it matures.
And my other wishes? I've spoken with one of the representatives
from X1 who assured me that he would post a link to my
wishes
on the X1 forum.
We'll see what happens.
If you are unfamiliar with X1, I recommend that you check out Marc Orchant's
reviews
of the product. Posted with permission from the folks at X1.
Should we really use the delegated task
feature to delegate actions to others?
While many people are usually excited to learn that their action management
system will allow them to delegate actions to someone else, I find that
many who have actually worked with such a system do not often share the
same enthusiasm.
I usually recommend that my clients avoid using the task delegation feature
of their action management system-- at least until I can confirm that everyone
is on the same page in terms of how they will use it.
In
order for delegated tasks to work, a high level of trust and an "action
delegation protocol" must exist between all parties.
The
person doing the delegating needs to trust that when he delegates something
to another, it will be seen and actually treated as an action by the assignee.
Likewise, the person who receives the delegated action must have a way
to become aware of, internalize, and "accept" the action as their
own. Successful delegation requires trust and commitment. If either is
not present (as is often the case) then delegated tasks won't work.
This is not a new problem, it's as old as paper, at least. Technology has
just made it easier to quickly dispatch a barrage of computer-delegated
actions to unsuspecting (and possibly unwilling) people.
Delegated tasks create a situation in which the technology
of productivity is likely to clash with the methodology of productivity.
The
technology allows for tasks to be created and assigned to other
individuals; however, without a sound methodology and clear
agreement on how these will be processed, (the action delegation protocol),
it can quickly become a recipe for lost or missed actions, frustration,
and incompletion.
I recommend that my clients use David
Allen's GTD methodology. In of my years of consulting on technology, I've
not found a better system for thinking about your work than GTD. In his
book, Getting Things Done, David emphasizes the importance of accountability
in all aspects of delegating and accepting actions; he also makes it clear
that the system used to track actions - be it paper or digital - must be
absolutely leak-proof. These are two areas where delegated actions, if
not used properly, can fall apart as a tool for organizational action management.
Microsoft Outlook, Lotus Notes, and even my
eProductivity
software all allow for tasks to be delegated to others simply by selecting
the assignee from a directory. The beauty of this - at least from the perspective
of the one doing the delegating - is that it is easy to create a project
and then delegate actions to others.
One of my first
action
management systems, which
I designed for the US Navy, did just this. The manager could initiate a
project and then define and delegate specific actions to others in succession.
Next actions could be queued so that as one action was completed the next
would be delegated out in sequence. The system was a success, but I suspect
that a large measure of this success was because the actions were effectively
"orders" on the part of the manager and it was clearly understood
that they were to be followed as assigned. The trust and protocol that
I mentioned earlier were part of the environment. In a closed-system, with
a clear chain of command, action management can, and indeed in some cases
must work this way. That was almost 20 years ago. Today, a person is as
likely to collaborate with someone in their own office as they are with
someone around the world. The relationship is less likely to be superior/subordinate,
as with my Navy client, and more likely to be peer to peer. In this situation
trust and protocol are essential.
The benefits of a delegated-tasks system can be significant. For the one
doing the delegating, as tasks are entered into the system, they can delegate
an action to someone else simply by indicating their name in the "assigned
to" field. They can also can provide optional information such as
a due date, status and alert notification request.
Outlook task delegation fields:
Lotus Notes task delegation fields:
For the assignee, they do not have to enter anything into their action
tracking system - it's all done for them. Depending upon how their system
is configured, they may have the ability to accept or reject assigned tasks
first or the new tasks may simply appear on their to do list. Both Microsoft
Outlook and Lotus Notes will display a list of delegated tasks, the responsible
party, due date, and status. For these reasons it is often quite
tempting to use delegated tasks in the hopes of having a system of "total
control and accountability."
Key things to consider when using delegated tasks:
1. Discuss delegated actions with your collaboration partners:
Will you use computer-delegated tasks at all? Will you allow others to
add actions directly to your action support lists (risky) or will you use
the propose/accept model (better) for delegated actions? What kind of feedback
will be exchanged about the actions? What should be done when changes are
required on either side?
2. Make sure that you understand how delegated tasks work:
Who "owns" the task? Will your system automatically place an
action item on the assignee's to do list? How will they become aware of
the new action? Do they have to accept it to make it their own? What is
the process for delegating a task to someone and what happens when you
(or they) cancel or change a task? Can a delegated task be delegated to
someone else? How will you track these delegated items?
3. Make sure that everyone else understands this as well:
Simply having good technology in place will not necessarily make a team
more productive. Sometimes it even leads to just the opposite. It is important,
therefore, to have procedures and protocols in place for putting technology
to work. My clients have found that training and
coaching
can make a big difference in the productive benefits they receive from
their technology investment.
4. Have everyone practice delegating/accepting/declining actions:
Practice, practice, practice. As I've said before, in order for delegated
actions to work at all, there must be a high level of trust - not only
among the people but in their support systems as well.
Are delegated tasks simply a bad idea?
I don't think so, but I do think they can be very dangerous if not used
properly. When used correctly, by a group of people, who have agreed upon
a specific task delegation protocol, delegated tasks can be a powerful
productivity tool. Unfortunately, more often than not, this agreement is
not in place, and for this group of people, computer delegated-tasks can
quickly lead to a lack of trust in systems and turn into a digital nightmare.
As I show clients how to use technology in support of the GTD methodology
I find that few are really ready or need to use delegated actions. I usually
coach these people to avoid using computer delegated actions and to use
traditional means, such as e-mail, phone or even paper as a way of
exchanging information about tasks without entering actions directly into
someone else' system. This way, each party can internalize the next action
and their commitment to it, placing it on their own list as appropriate.
Is your organization using computer-delegated tasks? If so, how has it
worked (or not worked) out?
I would like to hear about your experience.
Please post a comment (or send me an email) and let me know what you think!
This blog post is a transcript from last week's
podcast
on delegated tasks management.
Note: For purposes of this discussion, when I refer to delegated
tasks, I am specifically referring to the ability to create a task (an
action) in a digital system such as Outlook or Lotus Notes, and to assign
it to another individual, so that it will automatically end up on their
action list.
(c) Eric Mack 2005
