Browse Prior Art Database

Task Description Technique as Input to Task Analysis

IP.com Disclosure Number: IPCOM000122988D
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 166K

Publishing Venue

IBM

Related People

Sluiman, H: AUTHOR [+2]

Abstract

A method for collecting task descriptions and workflow organizations is disclosed.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 32% of the total text.

Task Description Technique as Input to Task Analysis

      A method for collecting task descriptions and workflow
organizations is disclosed.

      In the domain of task analysis, tasks are typically described
with sentences that are then decomposed in terms of their noun / verb
pairings.  In the domain of work flow, data flow is typically used to
describe the input and output of a task.  In order to provide a
solution to a user population you need to actually deal with two
different requirement definition paradigms, and two different
information collection techniques.

      An established practice that is able to deliver both task
analysis and work flow data are customer site visits where
consultants interview and observe the day-to-day workings of the
personnel responsible for a given process (or set of processes).
However, this is a costly and, sometimes, intrusive practice; the
costs of which are  exasperated as the processes of interest involve
larger numbers of people and extend over greater periods of time.

      A second problem one needs to solve in order to provide a
solution to a user population is the problem of context.  Task and
work flow occur within a context.  Narrow down that context too
precisely and the applicability of one's solution to the broader user
population becomes questionable.  Ignore that context and the data
one has gathered will contain a much reduced set of insights.

      Customer site visits provide all the context one needs and
more.  But the costs of such an approach simply become prohibitive as
multiple customers are included in the sample to be studied in order
to generalize one's findings to a broader user population.

      Finally, hard-wiring tasks and data flow to context fails to
recognize that the user's fundamental tasks do not change
substantively over time.  In contrast, the tools that they might use
to do these tasks and, consequently, the data that flows between the
tasks change constantly, as does task sequencing.  What one needs is
a process that recognizes this; preserving the life of the core task
data, but allowing the mappings and frameworks from which the core
task data are hung to be routinely reassembled.

      Our solution to the problems identified above breaks down into
a four phase process.  Each phase can be refined and done in a more
tool based or graphical way, but the concepts remain the same.  We
basically follow these steps.

    Phase 1 (Generate)
  1.  Recruit a heterogeneous set of users that work in the
       task domain of interest.
  2.  Brainstorm to create an un-associated list of tasks.
  3.  For each task textually define and agree the goals of
       the task.
  4.  For each task define the tools used, or needed to execute
       the task.
  5.  For each task define the information the task produces.
       Typically, this is a list of "objects" or artifacts produced
       o...