3. Project management and goal setting
Last updated
Last updated
The principles of project coordination and goal setting for remote work are not too different from the office ones. The bottom line is to build intelligible and transparent processes while choosing convenient tracking and reporting tools. It is also important to create a culture and values so colleagues understand how to behave in unforeseen situations and are not afraid to make decisions.
The roadmap gives an understanding of the overall view of the projects, the timing and milestones of development, and the priority of tasks. Therefore, all team members must have access to the map and know what is planned and for what date. At the same time, do not make the roadmap too detailed; do not describe small tasks and connections. Otherwise, the scheme will be too complicated and unsuitable for work. A useful roadmap provides an overview of only the main objectives and results of the project.
Clearly prescribe procedures, roles, and deadlines. At remote work there is no place for micro-management and coordination of each step of the employees. Therefore, it is very important that everyone in the team understands the order of actions and roles. Avoid blurry, undeclared rules that are passed as rumors. They bring chaos and disrupt structure.
If there are a lot of tasks set at the same time, you should determine priorities first. Then the team will not be confused about the order of the task execution. Again, this is the situation where the roadmap really helps: when some new unforeseen tasks appear it is easier for the team to understand what to do and in which order.
If it is impossible to carry out the current task, there should be a list of other tasks to which one should switch. This way you can avoid downtime while current problems are being sorted out. For example, if a developer is blocked he should change the status of the task and describe the situation in the comments without waiting for the next call. Right after that, he should proceed to the next scheduled task.
It is important for managers to understand how the situation is changing on projects every day. One must be able to see what has already been done and what tasks are still in the process. For this one should use task statuses, update lists, and reports. All these can be automated with the help of any convenient time tracker. And, of course, one should additionally plan daily status calls.
Setting goals in remote work is subject to generally accepted rules. The only particularity is that a detailed description is needed as if you were discussing it in a live conversation.
One of the most common planning concepts is SMART. According to the approach, it is important to set a goal from which it is clear what exactly needs to be achieved, when it needs to be done, and how to understand that you have succeeded.
From our experience, the concept does not work well for large and complex goals. In addition, full adherence to the approach does not eventually guarantee that the goal has been formulated correctly.
Another famous approach is OKR (Objectives and Key Results), where:
Objective is a memorable well-worded description of what you want to achieve.
Key results mean the set of metrics, the value of which changes as it moves toward the Objective.
The system is clearly described by John Doerr's Formula: I will achieve (Objective), as measured by (set of Key Results).
This approach is used at Google, Spotify, Twitter, LinkedIn, and Airbnb.
Achieving the objective largely depends on how correctly the tasks are set.
WELL-SET GOAL | POORLY SET GOAL |
It is described clearly and in detail and therefore does not require additional explanation. To a large extent, it reveals WHAT should be done, not HOW. Indicates a clear deadline, if there is any. | Even during the goal setting it is obvious that a call for discussion will be needed. It does not show what and when should be achieved as a result. |
Explains WHY implementation is necessary. | Does not show the benefits of implementation. |
It contains clear execution criteria and a transfer procedure (for example, for testing). | It’s not clear what to do next further down the chain. |
Includes all the necessary materials for implementation in full (for example, a special text or design). | Requires the search for additional information or materials, a separate explanation at the intermediate stage. |
If it requires changes to the existing functionality, it first describes the current version of the work and then the necessary corrections. | It contains a list of changes to the current functionality without a description of the problems of the current version. |
Registering something in Jira and partially creating cards in Trello is an unsuccessful way of organizing. Everyone will only get confused and forget what and where exactly everything is and what and where to write. Any member of the team must open just one tool to find out about the status of tasks and sprints and see the responsible person and assessments.
If you do not determine who is responsible for the appointment and coordination of tasks, you end up with complete confusion. Everyone will independently come up with tasks and do what they want. Sometimes even clients or partners can suddenly set tasks directly, thereby introducing uncertainty into the life of the project. Therefore, we offer an option with a special inbox list of team members. The project manager works further with this list while analyzing, planning, and assigning tasks.
It’s not good when tasks of different types are mixed in one pool, since they always differ in importance and scale. It is proper to use a specific separation system. For example, we have a structure like this:
Epics. Large, often strategic tasks that require a long implementation time and consist of separate parts. For example, a general redesign includes working on separate pages, which can be done one after another. At the same time the whole redesign will be complete only when every page is ready.
Tasks. Minimal independent units of work that benefit the project and users.
Sub-tasks. Technical parts of the implementation of tasks. Our manager does not follow those — sub-tasks are created by the performers themselves as elements of their work planning.
Use special marks such as: bug, design task, technical work, and others. Pay attention to the information in the name of each task. It is always proper that the name contains the verb.
