Hierarchical Task Analysis

Hierarchical Task Analysis (HTA) is a structured method for understanding and analyzing users’ tasks and goals within a system, product, or service. A technique of task decomposition, it visibly breaks down complex tasks into smaller, more manageable parts.

Key Concepts

Goal-Oriented: HTA starts with identifying the main goal or objective of the task. This goal is then broken down into sub-goals and further into smaller tasks, creating a hierarchical structure resembling a tree.
Hierarchical Structure: The analysis is organized hierarchically, with each level representing a task broken down into more detailed steps. The top level contains the main goal, and subsequent levels contain sub-tasks necessary to achieve that goal.
Iterative Process: HTA is often an iterative process involving multiple rounds of refinement to ensure that all tasks and sub-tasks are accurately captured and organized.

Steps to Conduct HTA

Preparation and Research: Gather information about the system, including user needs, tasks, pain points, and other relevant data. This step involves understanding the target audience and observing how the task or system is used in real-world scenarios.
Define the Use Case: Identify the scope of the analysis and the specific use case to be mapped. This includes understanding what needs to be mapped, why it is being mapped, and which user segment will engage with the experience.
Construct the Initial Flow Chart: Create an initial draft of the flow chart that includes all the steps needed to complete the task. Highlight interactions between different parts of the system.
Develop the Diagram: Break the main task into smaller chunks and organize them into a task sequence. Each chunk should have a unique identifier for easy reference.
Review the Diagram: Validate the diagram’s accuracy and completeness through walkthroughs with stakeholders and users. Gather feedback to refine the analysis.
Report Findings and Recommendations: Identify opportunities for improvement and make recommendations based on the analysis. This step involves further user research and ideation, culminating in a report to share with team members and stakeholders.

Applications of HTA

UX Design: HTA helps UX designers understand user interactions and identify pain points, leading to improved user experiences.
Human Factors Engineering: Originally used to evaluate and improve human performance, HTA is effective in designing systems that align with human capabilities and limitations.
Training and Onboarding: HTA can create training materials and onboarding processes by breaking down complex tasks into manageable steps.
Process Improvement: By analyzing and visualizing tasks, HTA helps identify inefficiencies and areas for improvement in existing systems.

Benefits of HTA

Comprehensive Understanding: A detailed view of all steps involved in completing a task.
Identifies Opportunities for Improvement: Helps pinpoint critical steps, redundant tasks, and user struggles.
Facilitates Communication: Offers a clear and structured way to share findings with stakeholders.
Supports Complex Task Analysis: Handles detailed and complex tasks effectively, making it suitable for various applications.

Limitations of HTA

Not Suitable for All Tasks: HTA is less effective for tasks that are open, volatile, uncertain, complex, and ambiguous (e.g., emergency response, strategic planning).
Requires Iterative Refinement: The process can be time-consuming and may require multiple iterations to achieve accuracy.

Hierarchical Task Analysis for Computer System Validation (CSV)

As an example, we will create an HTA for a Computer System Validation (CSV) process through release. Not meant to be exhaustive but meant to illustrate the point.

1. Planning and Preparation

1.1 Develop a Validation Plan

Create a comprehensive validation plan outlining objectives, scope, and responsibilities.
Include timelines, resource allocation, and project management strategies.

1.2 Conduct Risk Assessment

Perform a risk assessment to identify potential risks and their impact on validation.
Document mitigation strategies for identified risks.

1.3 Define User Requirements

Gather and document User Requirements Specifications (URS).
Ensure that the URS aligns with regulatory requirements and business needs.

2. System Design and Configuration

2.1 Develop System Configuration Specifications (SCS)

Document the hardware and software configuration needed to support the system.
Ensure that the configuration meets the defined URS.

2.2 Installation Qualification (IQ)

Verify that the system is installed correctly according to the SCS.
Document the installation process and obtain objective evidence.

3. Testing and Verification

3.1 Operational Qualification (OQ)

Test the system to ensure it operates according to the URS.
Document test results and obtain objective evidence of system performance.

3.2 Performance Qualification (PQ)

Conduct performance tests to verify that the system performs consistently under real-world conditions (includes disaster recovery)
Document test results and obtain objective evidence.

4. User Readiness

4.1 Write Procedure

Create process and procedure to execute within the system
Create Training

4.2 Perform User Acceptance Testing

Confirmation business process meets requirements
Document test results and iteratively improve on process and training

5. Documentation and Reporting

5.1 Create Traceability Matrix

Develop a traceability matrix linking requirements to test case.
Ensure all requirements have been tested and verified.

5.2 Validation Summary Report

Compile a validation summary report detailing the validation process, test results, and any deviations.
Obtain approval from stakeholders.

Task Decomposition

http://smbc-comics.com/comic/break-it-down

Task Analysis

Task decomposition is a systematic approach to breaking down a complex task into smaller, more manageable components. A more detailed version of task analysis helps organize work, improve understanding, and facilitate effective execution.

Step 1: Understand the Task

The first step in task decomposition is to fully understand the task at hand. This involves defining the main objective, identifying the final deliverables, and recognizing all the requirements and constraints associated with the task.

Step 2: Break Down the Task

Once the task is clearly understood, the next step is to break it down into smaller, more manageable parts. This can be done by identifying the major components or phases of the task and then further dividing these into subtasks.

Techniques for Breaking Down Tasks:

Hierarchical Task Analysis (HTA): This involves creating a hierarchy of tasks, starting with the main task at the top and breaking it down into subtasks and further into individual actions.
Functional Decomposition: Focus on dividing the task based on different functions or processes involved.
Object-Oriented Decomposition: Used primarily in software development, where tasks are divided based on the objects or data involved.

Step 3: Sequence the Tasks

Determine the logical order in which the subtasks should be completed. This involves identifying dependencies between tasks, where some tasks must precede others.

Step 4: Assign Resources and Estimate Time

Assign the appropriate resources to each subtask, including personnel, tools, and materials. Additionally, estimate the time required to complete each subtask. This helps in scheduling and resource allocation.

Step 5: Prioritize Tasks

Not all tasks are equally important. Prioritize tasks based on their impact on the overall project, their urgency, and their dependencies.

Step 6: Monitor and Adjust

Once the decomposition and planning are in place, the execution phase begins. It’s important to monitor the progress of tasks, check adherence to timelines, and make adjustments as necessary. This might involve re-prioritizing tasks or re-allocating resources to address any bottlenecks or delays.

Step 7: Documentation and Feedback

Document the entire process and gather feedback. This documentation will serve as a valuable reference for future projects, and feedback can help in refining the decomposition process.

Task decomposition is a dynamic process that may require iterative adjustments. Used well, it is a powerful tool in the quality toolbox.

The RACI (and RASCI) Chart

What is a RACI chart?

A RACI chart is a simple matrix used to assign roles and responsibilities for each task, milestone, or decision. By clearly mapping out which roles are involved in each task and at which level, you can eliminate confusion and answer the age-old question, “Who’s doing what?”

RACI is a useful complement to a process map, since it can get into more detailed and specific activities than a high-level process map. Think of a process map at one level of abstraction and RACI as the next level of detail

What does RACI stand for?

RACI stands for Responsible, Accountable, Consulted, Informed. Each letter in the acronym represents a level of task responsibility.

When to use RACI

RACI’s are best used in procedures as part of the responsibilities section or to start each section in a long procedure.

RACI’s are great tools that can help:

Design or re-design processes more efficiently by highlighting decisions
Clarify overlapping, redundant, “bottle-necked,” or inconsistent responsibilities
Structure and distribute responsibility and authority
Establish clear lines of communication
Reduce duplication of efforts; pinpoint what can “come off the plate”

RACI definitions

A RACI is a matrix of tasks or deliverables and the roles associated with them.

Each box in the matrix identifies that role’s function in the task

Responsible – primary role performing the work
Accountable – role primarily responsible for the work getting done (and done correctly)
Consulted – roles providing input into the task or deliverable. Consulted means prior to the decision/activity.
Informed – roles to be informed of the outcome of the task or deliverable so that they may fulfill execute their role in the process or other process.

I’m a big fan of adding Supporting, and doing a RASCI. Supporting is very helpful in identifying individuals who provide support services, and often capture indirect accountabilities.

Key point – only one Responsible and one Accountable role for any task or deliverable. In some processes, Responsible and Accountable may be the same role

How to create a RACI

Follow these 3 steps, using the RACI chart example below as your guide:

Enter all responsibilities in the procedure across the top row.
List all procedural steps/tasks, milestones, and decisions down the left column.
For each step, assign a responsibility value to each role or person on the team.

Ensure the following:

Every task has one Responsible person (and only one!).
There’s one (and only one!) Accountable party assigned to each task to allow for clear decision-making.
If you have a lot of C and I roles on your matrix, make sure you have an easy and lightweight way to keep them informed in the procedure.

Some points to consider:

Have a representative from each of the major functions that participate in the process
Reach consensus on all Accountabilities and Responsibilities
Consider the emotional aspects of documenting “A”s and “R”s, including job justification
Eliminate excessive “C”s and “I”s
Consider the organization’s culture

Review the RACI chart vertically to:

Avoid under- or over-committing positions or team members
Eliminate unnecessary gates and bottlenecks
Designate appropriate skill sets

Review the RACI chart horizontally to:

Clarify any ambiguous division of labor
Ensure adequate continuity across decisions and process steps
Ensure accountability and authority to get the job done

Although the RACI is a simple tool, the process of creating it and having it agreed is a political process.

Developing RACI charts surfaces many organizational issues because it confronts the three elements of roles and responsibilities:

Role Conception: what people think their jobs are and how they have been trained to perform them
Role Expectation: what others in the organization think another person’s job is and how it should be carried out
Role Behavior: what people actually do in carrying out their job

Example

	Deviation Creator	Area Responsible	QA	Investigation Team	Site Head
Take real-time action to minimize and contain the effect of an event	R	A	I	–	–
Assemble cross functional team for Triage	R	A	I	–	–
Determine if the event is a deviation	R	C	A	C	–
Define batch association strategy	C	R	A	I	–
Define Containment	C	R	A	C	–
Create Deviation in eQMS in 24 hr	R	A	I	–	–
Gather Data	C	A/R	C	C	–

Flow Chart

The flow chart is a simple, but important, graphic organizer. Placing the states or steps of an event or process into the correct sequence allows you to reach conclusions and make predictions.

However, its simplicity means we don’t always work to be consistent and can benefit from a little effort to ensure users are aligned.

I am a huge fan of including flow charts in all process and procedure documents.

Steps for Building a flow chart

Capture

Capture the events or steps of the process. Resist the urge to arrange them sequentially and concentrate on capturing the events/steps only.

Cull

If there are more than eight steps in a flow chart we start creating cognitive overload. If a process or procedure has more than eight steps you need to:

Ensure the steps are at the right level, sometimes we have substeps represented and we can cull that. Ensure they are all on the same level of process/procedure/task.
Decide we need to break the procedure into multiple documents. This is a great way to decide what work instructions are necessary.
Look for opportunity for process improvement.

Sequence the events and draw the flow chart

The focus now shifts to temporal relations. The correct sequential arrangements of steps or events helps to reach conclusions about past events and prepare for future events.

Example

I’m writing the procedure for my mornings, I capture the following:

Eat breakfast
Take shower
Take dog out
Get dressed
Decide on tea
Heat water
Drink tea
Read for 30 minutes
Deal with morning email
Snuggle with dog

Taking a look at the list I realize that not everything is on the same level of process/procedure/task and end up with a shorter list.

Breakfast
Take shower
Take dog out
Get dressed
Read for 30 minutes
Deal with morning email
Snuggle with dog

Notice how I combined all the tea stuff into a breakfast category. When brainstorming my list I put a lot of weight on tea, because it is important to me (yes I have been using tea as a training example since 2005, I just love tea).

I can then put them in sequence:

When I was making things sequential I realized that two of my activities (read and dog snuggle) were concurrent, so I combined them as one step.

Process, Procedure and Task

A task is the steps for doing a particular piece of work.

Procedure are activities made up of a series of tasks.

A process is an upper level description of a series of activities required to accomplish an objective. Processes are made up of procedures or tasks. They have inputs and outputs.

Process	Procedure	Task
Flow of sequences of activities that transform input elements into results	Specific and required way to carry out a process	Describe the correct steps to perform a specific task
What we do By Whom Where it takes place When it happens	How the work must be performed	How to accomplish a specific task within a process with very detailed directions
Orchestration the work	Mandatory method	Mandatory guidance
Can link to 0, 1 or more procedures	It may consist of 0, 1 or more task instructions	Focus on the instructions of 1 task
Transversal by business units	Cross functional or only 1 business unit	Only 1 business unit
Participate more than one role	Participate more than one role	Participate only one role
Encapsulates activities	Explains how to do but doesn’t get to all the details of how it is done	All of the detail of all the steps to follow in an activity
Provides the workflow model at the highest level using BPMN	Document with both narrative and images, usually in the form of use cases and workflow diagrams	Document with the maximum detail that explains step by step the instructions that must be carried out in an activity

Process, Procedure and Task Differences

This is the middle of a traditional document hierarchy and forms the Functional set of documents.