How-to... Recommendations for TaskPack

1 TaskPack = 1 Doer

The Workanizers methodology recommends that you insist on individual responsibility. That's why one TaskPack is always made to be executed by only one Doer. He is responsible for the execution and the result.

1 TaskPack lasts max. 1 day

Avoid creating TaskPacks that last longer than one working day.

If you assume that the execution will most often not happen during one working day, then divide such a TaskPack into two or three smaller ones.

There are no timeouts inside TaskPack

Try not to create a TaskPack with expected timeouts. A common example is when e.g. Doer in TaskPack sends an email to the client and waits for a response from which the continuation of work depends. In this case, one TaskPack should end with sending emails and the next TaskPack should be created and start with receiving emails from the client.

Passive delivery of results

Avoid personally delivering and receiving results between Doers. In particular, avoid verbally conveying essential information or explaining modifications (why something is different from what is described in the result norm). You waste valuable time, interrupt the work of multiple Doers for no reason, and inevitably lose (forget) verbal information in the work chain.

Use passive delivery of results instead. Specify the location where the result is delivered, physically or digitally. The next Doer can find it there at the appropriate time and continue the workflow. It is a passive delivery of results.

TaskPack is short and easy to remember

The TaskPack should be short, which means that it does not have a large number of tasks. Best three to five or six. The goal is to make the TaskPack as easy to remember as possible to fit into Doer's working memory and to remain in it during the entire execution.

TaskPack is written for the beginner

TaskPack should always be created with the assumption that it is read by a beginner who can independently execute it step by step with it. We call it self-training. We should do so even though we know it will be executed by experienced Doers as well.

The details of TaskPack and the independence of Doer

The TaskPack can have the level of detail as needed. The level of detail of the TaskPack should be adjusted to its importance.

A less detailed TaskPack is suitable when it is made up of tasks whose execution is not particularly important in terms of the norm of results. Then it's usually about simple, well-known operations that don't need to burden Doer.

Not all elements in a TaskPack are always necessary. It depends on the complexity of the TaskPack and whether you have had problems with those tasks in the past. If you had problems, go into the details and where the problems appeared. If there are no more such problems, you can relieve TaskPack of the details.

If the goal of the TaskPack is to provide Doer with clear instructions, then it may be the wrong approach to overload the TaskPack with all possible information "just in case". Such a TaskPack becomes unclear, difficult, and slow to read and thus misses its goal.

Following the recommendation that TaskPack should be written for beginners, excessive detail should be avoided when it comes to simple and well-known operations.

More detailed TaskPacks are used when the result is critical in terms of obtaining the exact norm of the result or the execution is important for the safety of the Doer or third parties.

Depending on the level of detail of the TaskPack, you will give more or less autonomy to the Doer in choosing how to complete the tasks. With detailed steps, rules, and descriptions you will guide Doer in detail through the execution. And vice versa. Sometimes you can leave out the details if you think Doer will have a clear enough understanding of how to proceed on his own.

The level of detail of the TaskPack can be changed over time as needed.

Input control

Use input control only if in practice you have problems with the execution of that or the previous TaskPack. Or if the TaskPack is very important or sensitive in terms of security. Or the TaskPack is new and the Doers need to discipline themselves and get used to it.

Output control

Similar to the previous one.

Use the control of the result before its delivery only if in practice you have problems with the execution of that TaskPack. Either the TaskPack is very important or sensitive in terms of security. Or TaskPack is new and Executors need to discipline themselves and get used to it.