Architecture basics: The structure of a task
Blog: Tom Graves / Tetradian
What’s the structure of a task? What do we need in a task to make sure that we do the right things right?
It’s worth thinking about this in architectural terms – in terms of that tagline for enterprise effectiveness, that “Things work better when they work together, on purpose”. What would that show us about how we currently describe day-to-day tasks for change across any part of the enterprise? And might there be a better way to describe and make sense of those tasks, and how they relate with each other?
To do this, let’s start with a good old Gantt chart, like this one shown on Wikipedia:
It’s made up of a bunch of tasks, which, as far as the chart is concerned, are each just an empty box where something is meant to happen. The boxes are connected to each other, in terms of dependencies and time and so on, but there’s nothing in the chart itself that tells us what actually needs to happen in each case.
So let’s expand on that a bit.
Let’s pick a task at random from that chart above. The task-boxes shown there don’t really have any proper labels, so let’s call it ‘the Task‘:
But what we would put inside that box that we’ve labelled ‘the Task’?
Probably the first thing that we’d do would be to map out a step-by-step sequence for how we’d do things in the task, defining the process for the action via a set of work-instructions and the like:
Note, though, that each of those steps in the work-instructions would itself be a kind of ‘mini-task’ in its own right. Which might in turn have its own work-instructions, which in turn would be a set of ‘micro-tasks’, each potentially with their own work-instructions. Which – well, you get the idea…
Which brings us to a couple of important understandings about the structure of tasks:
- tasks are fractal, potentially nested inside each other ‘upwards’ and ‘downwards’ to any depth and breadth that we choose
- the boundary of any task is where we choose it to be
As in the Gantt-chart, we’d probably start off by defining those task-boundaries in terms of dependencies or blocks of time, or who’s doing the work, or where it happens.
In each case, though, we choose the boundaries. There may be constraints or limits on where we’d place those boundaries, but in general we still choose where the boundaries would go.
Which means there may be other useful ways in which to draw those boundaries.
The first of these would be to expand a bit on that description of the action, by noting that the work-instructions are just the setup for the more predictable part of the action. To be more complete, we need to note what we should do about any unpredictable parts of the action – variances, exceptions and so on – and also what records we need to keep about the action itself:
That gives us a way to link the instructions for the task to the outcomes for the task – to link what’s supposed to happen with what actually happens, or to bridge from intended-future through the ‘Now!’ of action and onward to the unchangeable-past. Which is probably important, as we’ll see later.
To do the task well, though – no just ‘do things’, but do things right – we’re going to need some kind of plan and preparation. We might well see this as separate from the part that we’d label as ‘the action’ – maybe even treat it solely as a separate task. Yet in practice that ‘the plan’ is still so tightly linked to ‘the action’ that it does also make sense to include it as part of the same overall ‘the Task’:
There are two distinct parts to this ‘Plan’ section of the task: building the plan for action, and setting up for the action itself.
In building the plan, we identify how we’re going to do the action. This may well involve a whole swathe of child-tasks, working our way down from an abstract ‘Just Do It’ to concrete, practical step-by-step sequences, steadily reducing any inclarity and uncertainty – as indicated by Damien Newman’s ‘the Squiggle‘ in the background of the left-hand part of the ‘Plan’ section. Part of the outcomes of that work would be in defining the four types of checklist for the action: work-instructions, preventive-checks, emergency-checks, and guidelines for unprecedented events.
In setup for action, as shown on the right-hand side of the ‘Plan’ section, we add to those checklists with any preparation needed for the action itself – resources, materials, guidance, the start- and stop-signals for the action, success-criteria and so on. We’ll also need to set up to monitor and measure any items to be used as action-records for the overall action.
No doubt many people would stop there, in describing what’s needed in the task. But it’s actually not enough to just do things right – we also need to ensure that we do the right things too. For this, before we try to do the task, or even the plan for the task, we’ll need a solid understanding of the scope for the task – the boundaries, the people or stakeholders, the overall requirements and more:
It’s perhaps simplest just to show that part of the task as a checkbox here, because most of the time we’d have done the detailed work on that already, and all we need to do here is to check that we do understand what the scope is, and how to ensure that we avoid scope-creep and the like. But if we haven’t done that work already, there’s another whole swathe of sub-tasks that we’d need to do here – and do it all before we start on the plan or the action.
The same applies to the other key part of ‘do the right things’: we need to be sure that we do understand the big-picture context and overall purpose for the action – the vision and values to guide us whenever we face unprecedented events, the laws, standards and guidelines that apply throughout the context, and the overall criteria that define success and not-success:
Again, often all we’ll need here is to check that we do understand that broader context and purpose before we set the boundaries for scope, set out the plan, and take the requisite action. But if we’re not clear on all of that before we start, then yes, there’s yet another whole swathe of sub-tasks that we’ll need to do before we go any further – and that are definitely part of the overall ‘the Task’.
Establishing this link back to scope and context establishes a trail of provenance, helping to ensure that even the smallest sub-task right down in the depths of the detail is ‘on purpose’, and helps towards that aim that everything works better, together, towards that overall aim.
And finally, ‘the Task’ includes not just what needs to happen before and during the nominal ‘main action’ of the task, but what needs to happen after that action as well. We need to learn from the action, for the future, via a review of our performance and outcomes of that action:
This wrap-up for the task is absolutely essential, because it’s the key means via which we can get things to work better, together, on-purpose. As shown on the left-side panel of this ‘Review’ section, we first need to collate all of the records and outcomes from the current task and all of its sub-tasks, drawing from what had been gathered on the right-side panel of the preceding ‘Action’ section.
Once that’s been done, there are three parts to this review
— Benefits-realised: Check the outcomes from the action against the success-criteria defined in the ‘Context’ section, and as amended or extended in the ‘Scope’ and ‘Plan’ sections. In short, did we achieve what we set out to do? If not, there will probably need to be changes made – either amendments to other ongoing or intended tasks, or new tasks entirely.
— Lessons-learned: Identify any changes needed in skills, competencies and the like, typically via the five questions of an After Action Review: ‘What was supposed to happen?’, ‘What actually happened?’, ‘What were the sources of the difference?’, ‘What can I do better next time?’ (individual-responsibility) and ‘What can we do better next time?’ (collective-responsibility, e.g. as a team). This again is likely to give rise to further new or amended tasks.
— Tasks arising: Assess all of the suggestions from the previous two steps, for new tasks or changes to tasks, clarify their requirements, and set them up as tasks in the organisation’s systems for change-management and project-management.
That last step also establishes a further trail of derivation for each of these tasks-arising, showing where they came from, why they were called-for, and how they ultimately link back to the overall purpose.
In short, to keep ‘on-purpose’ in the midst of real-world change, we need every task to do the right things right, and help us learn and adapt from every action. To do this well, it’s not enough to list the main action for each task, as in a Gantt-chart and the like. Instead, we need to describe our tasks in a way that links everything together in a consistent way:
- support a trail of provenance that identifies the big-picture purpose of a task
- support a trail of derivation that identifies where and why the request for that task arose
- establish that each task will support doing the right things, in terms of context, scope, values, success-criteria and more
- establish that each task will support doing things right, with a clear plan, preparation and action
- ensure that each task provides appropriate means to support continual learning and improvement from the actions in that task and its sub-tasks, and from the actions in all of the related tasks for its plan, scope and context
There are all manner of ways in which we make that work in practice, within a given system for change-management and project-management: for example, we could continue, Gantt-style, to describe context, scope, plan and review as separate tasks, but include them all ‘by reference’, as crosslinks between each of the respective tasks. Or, as above, we could include them all ‘by value’, embedded within the respective ‘the Task’. In essence, that’s a choice for design rather than architecture. In an architectural sense, though, we need that structure of a task – context, scope, plan, action, review – because only with that structure do we have any way to ensure that everything is done on-purpose, doing the right things right, and learning how to get better at what we do, every step of the way.
Leave a Comment
You must be logged in to post a comment.
