tasktracker API 0.1 pre-release

The TaskTracker is an example COS application that enabled task tracking within Distributed Ad-hoc Work Groups, also known as DAWGs.

See:
Description

Packages

org.davesag.tasktracker	The tasktracker package consists of the core TaskTrackerEntry and ListEntry classes.
org.davesag.tasktracker.client	The client package consists of a simple client application that allows a user to enter and manipulate TaskTrackerEntries via a Swing GUI.
org.davesag.tasktracker.test	The test package contains various unit and performance tests for the tasktracker.

The TaskTracker is an example COS application that enabled task tracking within Distributed Ad-hoc Work Groups, also known as DAWGs.

The future of work is distributed. Old management styles are inappropriate for many types of projects. People are demanding to be treated with respect and not just as cogs in a machine and, although these demands were treated with fear and loathing by old school managers, modern management is all about empowering individuals and encouraging them to perform at their peak. As anyone whose planned a project using microsoft project knows, software for planning and resource allocation has not kept pace with these changes in corporate culture.

Outside the corporate world, work also continues. From NGOs to households, open source software teams to theatre groups, classrooms and pot law reform activists; groups of people need access to better planning and resource management systems. In such situations there are often almost no central management structures, yet work needs to get done.

Traditional project planning tools and ERP systems are too top down, too centralised and are based on out of date approaches to project management.

If you are sitting at the dinner table and want the butter, just out of your reach at the other end of the table, you can either order someone to pass you the butter, or just say "could someone please pass me the butter." Unless your's is a truly dysfunctional dinner party the latter request will get you the butter with no chance of someone saying "get it yourself you lazy prick". People like to be asked, not told.

DAWG applications mix top down guidance with bottom up interaction and individual responsibility.

The old way:

a manager is told what her team needs to achieve. his team is briefed and they set to work, following a project plan - marking off time as they go. usually by the end of the scheduled project plan the plan has been binned. project plans built by a central authority with tasks delegated are simply not the way to work.

The DAWG way:

A better model is to allow any member of the work group add the tasks they think need doing. this may happen initially by consensus, as the first batch of 'big picture' tasks are put together based on a project brief. members of the work group are now free to attack these tasks in the following ways.

• break a task into subtasks.
  When a worker breaks a task into a set of subtasks the super task becomes a task overview object as in any regular project planner.
• specify task dependencies
  When a worked specifies task dependencies they can do so in a number of ways
  • specify that task a can not be started until task b is complete
  • specify that two tasks must be done simultaneously
  • specify that whenever task a is done, task b must also then be done
  • specify that a task is iterative and thus always needs doing.
  • specify a lag period eg task a should start the day after task b ends.
• work on a task
  When a worked elects to work on a task, either by pulling a task out of a common pool, or by having a task allocated to them by another worker, they specify when they think they can get the task completed by. as a worker logs time on a task they should keep track of the work they do. ideally the worker will just hit a start button on a timer against that task to record the time spent. they should record a short log message whenever they stop their timer.
• or assign the task to someone else
  at any time a worker can assign their tasks to other workers. each task should keep a history of the workers that have touched it, and when.
• add new tasks
  Anyone can add new tasks at any time. Tasks found to be repeats of other tasks must be able to be merged with their doubles. this can be done by ad-hoc human supervision.
• follow up on tasks you reported
  To follow up on a task or tasks you have reported you will have access to various reports. depending on your status within the project , and the status of the tasks themselves, some parts of a project's gannt chart may be incomplete or blank, but the chart should clearly show what is being done, by whom, when they think they'll be done and so forth. as the tasks are worked through all members of the team can see how the project is going via simple overview reports. this helps motivate everyone.

Workers in the same work group may never need to know each other. you can only assign work to your buddies, and for the most part people's buddy lists overlap. tasks can be restricted to known groups of workers for sensitive projects, but that does not mean that groups can not feed each other the results of such work. thus you can develop projects that feature real 'chinese walls' and that provide layers of overviews based on your authority to see a project.

This is a good DAWG application. Workers can be anywhere, and are connected only by their buddy lists. they are encouraged to exercise individual responsibility in accepting jobs. the application facilitates interpersonal familiarity because jobs can be assigned to buddies, not just dropped into a pool. you give the job to someone you trust to do the job.

there are various contexts for deploying such a system.

• An open access system would allow general tasks to be proposed and bid for by workers competing to complete is faster, or better. in this case buddies need to be ratable using some form of reputation capital.
• A closed ERP replacement where buddy lists are preset by 'the company' and are allocated in a structured manner that compliments the existing work practice. in this case buddies are co-workers and some form of reputation capital may be refocussed to a form of peer review system. the underlying mechanisms are the same.

DAWGs extend p2p concepts popularised by instant messengers. the buddy list is central to any DAWG.

As well as task allocation and tracking for a DAWG to work you need simple chat ala an instant messenger and simple shared desktop ala VNC. as bandwidth improved and IP6 rolls out voice and video over IP will also become more useful supplements to collaborative distributed working.

Since:

TaskTracker 0.1 pre-release 30 Mar 2002