Homelessness task progression management overview
A task is a discrete action that must be completed as part of a wider homelessness case. Each task has three constituent elements that are defined as part of its configuration: an owner (automatically transferred from the definition), a service level agreement (dictating the duration over which it must be completed) and, optionally, a direct relationship to other prerequisite or dependent tasks through its inclusion within a workflow path. Whilst task ownership can mirror that of the associated homelessness case, there is the opportunity to assign responsibility to other subject matter experts, either directly or through their role membership. Ultimately, each task is linked to a homelessness activity, facilitating the logical grouping of actions that are required in order to achieve a specific aim, and classified as Prevention and Relief, Assessment or Review.
Depending on the complexity of any given homelessness task, it will likely be progressed in phases, with each phase being thought of as an event within the lifecycle of the task, thus compiling a historical picture of the progression status, ready for further review and analysis. In terms of the completion deadline allotted to the task, the expectations placed on the owner are governed by the overarching Service Level Agreement (SLA), as defined by the housing authority in line with their own internal procedures and adherence to legislation. Whilst the SLA operates right down to specific task level, it is applied in the wider context of other dependent tasks that coexist within the parent homelessness activity. The required SLA is assigned within the task definition, comprising a unit (days, weeks, months) and a period multiplier (an integer). Therefore, the target completion date for a live task is automatically calculated from the associated definition, based on the planned start date. Undoubtedly, there will be circumstances arising outside of the owner's control which they can influence through the adjustment of the planned target completion date. An owner also has the ability to place a task on hold in situations where no action can be taken for a set period of time, and where the SLA might otherwise be unavoidably exceeded. For instance, it would be legitimate to place on hold a task where verification details have been requested from an applicant who is known to be in hospital. As part of the process, a future release date would also need to be specified, ensuring that no open tasks remain static without a set progression point. Any number of discrete notes can also be appended to the homelessness task as an aide memoir to the owner, these appearing as separate entries within the overall graphical timeline.
From an end user perspective, all assigned homelessness tasks can readily be viewed and progressed via the 'cases and tasks' Home pane. This is in essence a 'to do' list, with real time information presented on the status of each task. Simply by double-clicking on an entry included within the list, an end user can launch and progress the task.
Separate help articles have been created for each key aspect of homelessness task progression management, including: