Creating a Task Tracker for Teamwork on a Project

Part 2: “Have We Submitted all the Tasks?!”

You can find Part 1 here.

Working with the task tracker turned out to be so convenient that all the tasks of the project team gradually moved there, including those formed to carry out the work of the project plan.

But this immediately led to failures in teamwork.

Firstly, the tracker and the procedures for working with it were designed for a relatively small number of tasks that the team had to discuss daily at a half-hour working meeting. The increase in the number of tasks first led to a boost in time of the meeting and then to the fact that the tasks began to be considered selectively — some of them were on the verge of uncertainty.

Secondly, the work from the project plan was not displayed in the tracker, and the wording of the tasks created to detail them did not always allow them to be attributed to a specific work. The team spent time clarifying the nature of the task and its impact on other registry tasks.

A solution was required to consider related tasks in the aggregate, reducing the time for “inclusion” of the team in the context of a specific task. At the same time, the short duration of the tasks and the presence among them of a large number of “orders” unrelated to the project plan made it inconvenient to use the classic tools for managing the relationship of work in the project, for example, the hierarchy of project work and establishing the sequence of work on the schedule (Gantt chart).

Target

Thus, the goal of modifying the task tracker at this step was to provide the ability to consider tasks in context.

Solution Technology: Grouping of Tasks

Having tried various options, we chose to group tasks according to the project results because no matter how operational the task is, it always arises in creating a specific outcome. But it turned out that the project results were unsuitable for our purposes because, in the short term, we worked on one maximum of three results, and the groups of tasks turned out to be too large and heterogeneous.

Then we introduced the concept of a key result and limited its size to the period of receipt — two weeks. Thus, we have a transitional level between the project plan and operational tasks.

A key result is an internal intermediate result necessary to obtain the result of a stage or project as a whole.

In the task tracker, the names of key results were added to one column with tasks, and a classification of objects by type (task and key result) was added as well.

This approach was not very convenient since it was impossible to set up the sequence of displaying dependencies we needed with Coda.io tools. Therefore, we filtered the key results into a separate column, created an association with a key result for each task, and grouped them into a convenient form for use.

Limitation

Suppose you plan to use multiple task filters in your tracker, for example, by the key result, task status, and due date simultaneously. In that case, we recommend you initially form key results and other independent data types as a separate column. Experience has shown that formulas are significantly more labour intensive when using our Key Results Creation scenario.

Each task in the tracker then corresponded to a key result and was considered in conjunction with other related tasks. We got the opportunity to determine the sufficiency of the tasks set to achieve the key result and quickly identify duplicate tasks and tasks with overlapping content. In addition, now it was visible which perimeter of tasks can be affected by the delay of one of them.

First, it was necessary to allocate time to determine key results for the period. Including this issue in the agenda of daily meetings led to delay, so a weekly half-hour meeting to plan key results was introduced. Within the framework of the meeting, the readiness of key results was assessed, and new key results were formulated.

The question immediately arose of who should add tasks to a result, evaluate their sufficiency, and form additional ones. Tasks created as a result of meetings and meetings were introduced by those responsible for meetings and minutes. Only another data parameter has been added — the key result. Responsible executives followed the tasks; team meetings were not intended for this analysis.

Therefore, separate key results Responsibles have been appointed. They also began to monitor the attainment of a key result, the presence of risks of variances, inform the team, and coordinate the work of responsible executors. Daily meetings moved to discuss the status of key results, and specific tasks were considered only if problems and risks arose. Separate views were formed on the tasks register table for those responsible for key results.

The next problem was that “promising” tasks in the “backlog” status, including those created based on minutes of meetings with the customer, could not correspond to any of the key results available in the two weeks. Previously, at daily meetings, the team primarily considered these tasks. When the discussion switched to the key results format, there was a risk that backlog tasks that were not related to a specific result would be lost. Therefore, one of those responsible for key results was appointed responsible for the unallocated backlog of tasks — he looked through it daily. He formed proposals for the formulation of new key results. Suggestions for new key results were considered at the weekly planning meeting, and in case of urgent tasks in the backlog, a new key result could be created as part of the daily working meeting.

Life Hacks That Improved our Tracker:

• We have set up automatic highlighting of blocked tasks. Further, in the daily working meetings, it was straightforward to prioritize the discussion.
• It was fixing requirements and comments that arise when discussing at team meetings in a separate column + checklists with automatic deletion of items after completion.
• Visualizing the connection of tasks was good by displaying tasks in groups according to key results.

Conclusion

Once again, I will note the advantages of our decision to use a no-code tool. It took us about 2–3 days to finalize the task tracker. We tried several different ways to enter and display data, discussing the result with the team until we set up a convenient view.

That is, we changed the functionality of the task tracker several times, all the while continuing to solve the project’s main tasks, fixing them and their execution in it, and at the same time, no information was lost.

As a result of the refinement of our task tracker, we received the following significant developments:

• Created conditions for monitoring the need and sufficiency of tasks in the registry and their relationship.
• Synchronized the task register with the project plan by:

Intermediate dependency of planning key result.

Weekly key results planning meeting.

The role of the person responsible for the key result.

• Improved the quality and reduced the time of daily team meetings.