Order out of chaos

I take the view that underlying this seeming chaos, there is definite order:

• people are engaged in explicit tasks in the project.
• tasks are related to a broader outcome in the project.
• tasks do have requirements and measurements of success.
• tasks do have dependencies that affect their pragmatic sequencing.
• tasks can be worked on concurrently (in the strict computing sense i.e. potentially in parallel and potentially multiplexed).
• tasks can normally be roughly estimated in terms of the time and resources needed.
• tasks can be prioritised.
• tasks define the granularity for obtaining feedback within the project.

I then see these tasks as mini experiments. In the same vein as test-first programming, the tasks can be specified, worked on, and the outcome can be observed, so as to validate the decisions and the implementation. The validation provides feedback that supports future decisions and tasks. Feedback needs to be obtained from multiple levels in system, and it is important to organise tasks to obtain earlier feedback from the production system.

Each task that completes generates concrete progress relative to the whole.

The trick is to ensure that that there is a low barrier to entry for maintaining this level of information about the project. This requires simple mechanisms and supporting tooling.

The next important step is to realise that these basic processes play out at all scales in the project. That is, over different time scales and involving varying numbers of team members. Yet the principles are the same in terms of deciding on a course of action, working towards a goal and evaluating the results.

Now, if we ensure that we use the same language and mechanisms for managing both the smaller scale and the larger scale tasks, then we immediately simplify the overall project management problem. This makes it easier for a range of team members to participate at project scales appropriate to them.

Obviously, ensuring that we consider the project at different scales is also fundamental to being able to step back from the fine-grained project details and gain an overarching view of the project at hand. This enables the team management (be that a team lead a department manager or the team collective itself) to ensure that the overall effort is on track.

Underlying structure

By considering each task in the project, irrespective of its scale, as an experiment - we immediately arrive at the following type of structure:

• requirements - the problem definition that needs to be met in order decide if this task is done. Here it is often useful to summarise the objective of the requirements in terms of a “halting condition” that gives a testable “definition of done.”
• design - the analysis and planning for how the work will be carried out in order to meet the requirements.
• implementation - the current work underway that is meeting the objective (e.g a WIP source code merge request). This is useful for ongoing review by multiple team members while the work is on going.
• observable - explicit artefacts that can be reviewed in order validate the result of the experiment i.e. to verify that the requirements have been met.
• approval - useful in some cases where a more formal sign-off needs to be recorded for future auditing purposes and communication to all stake holders.

The approach is to assume that any task could have any or all of these artefacts to support the communication and undertaking. However, the tacit implication is that some tasks may be too short lived or very well understood and may not benefit from all of this detail.

Additionally, we standardise on status flags for the tasks: staged, pending, active, completed, blocked and abandoned.

The end goal is that any task can be viewed as a locally run experiment that is successful if, when completed, it either explicitly solves the problem, or shows that the approach is not viable and that a new direction should be considered.

However, by itself this can easily lead to a “Cambrian explosion” of tasks, with little or no order. In order to keep the collection of tasks manageable we then employ two further constructs:

• dependencies - links to other “peer” tasks that indicate that the given task can not progress until the referenced task completes because the output of the referenced task is required as an input for this task.
• subtasks - links to other “child” tasks that indicate that the given task has been logically split into smaller units, and that this task can not be considered complete until all of its subtasks have also completed.

In adding the “network” constructs above, it now becomes possible to manage work in a scale-free manner. That is, logically there is little difference between a long-term project and a short-lived task. They both have to be well defined, have effort put into them, and need to be evaluated for completion at the end.

Letting things flow

Now that we have a clear view as to what elements in the project can be relied on as constant, we can start to leverage the variability in order to let the work flow.

The variability lies in aspects such as: the number of people assigned to a task, the estimated time needed to complete a task, the definitions of the requirements of tasks, the level of the system being affected.

The other obvious element of variability are the tasks themselves, and importantly the structure that they form, that is, the dependencies or subtasks defined.

It is this structure of the tasks that becomes the real power of project process because with it, we can be sure that at any scale we do not loose track of what it means to complete a task and which tasks are underway. While, at the same time we can reorganise the tasks and their structure to best represent a path that we feel will lead to the successful completion of the project.

Dependencies can highlight work that needs to take place sequentially. While, subtasks are good at teasing out work that can be carried out concurrently. Together these two aspects can be leveraged to encode efficiencies into the project plan.

Furthermore, subtasks can be used to work on projects in a more top-down manner (from the general to the specific levels of abstraction), by delineating boundaries for projects and assigning estimates and resources without needing to immediately unpack all of the details. When the time is right, the details can then be introduced as subtasks without affecting earlier planning, but with the ability to validate estimates and resources once this additional detail comes to light.

Ultimately, these approaches result in objective communication and improved coordination between all stake holders. Additionally, the individuals involved can rely on improved clarity in the work required and benefit from the sense of closure and completion of tasks, while being secure in the knowledge that this rigour actually allows for greater flexibility when circumstances demand it.

The nett result of applying this structure and rigour to how the projects are represented and managed, is improved project delivery and continuous visibility of project progress and overall flow.