Bad Advice for Project Managers: How to Set Tasks That Can’t Be Completed in the First Iteration
I’ve been working in the IT industry for more than eight years, and for the last five years as a project manager (PM). As per my observations, management problems are all very similar, and repeat themselves from one project to another. Typical mistakes have nothing to do with the geography, the scale of the project and its complexity, the competence of the team, and the roles within the team. I’ve made many of them myself. So I started to wonder to what extent my own conclusions are shared by other non-PM roles, like business analysts, developers, and testers.
I conducted a survey among team members in development offices in Ukraine and Russia in Feb 2021. The survey asked people to identify the most frequent and annoying issues when interacting with project managers.
The results of the survey — or better to say, the solidarity of the respondents on key points, and their correlation with my personal observations — surprised me.
Part one. A statistical one
More than 50% of respondents noted that poorly set tasks are the most common pain of development teams. The second and third places are shared by:
- Insufficient immersion of the PM in the essence of the project, and a lack of understanding on the PM’s part of the application area. At the same time, many respondents admitted they would be happy to conduct onboarding to help a fellow manager, but… The PMs don’t often ask them to do this. As one of the respondents aptly noted, a lack of understanding of the project and a lack of technical literacy often leads to planning errors.
- Ignoring the issues and inconvenient risks identified by the team, and avoiding the problem. This topic, perhaps, deserves a separate article and, in my experience, this behavior is associated not only with risk management skills, but also with the leadership qualities of a PM.
As for setting tasks, the anti-rating of the most annoying and (sadly!) most frequent pitfalls of project managers, is led by empty or insufficient task descriptions. More than 70% of respondents noted this issue.
Many team members are tolerant of grammatical errors, typos, and incorrect use of terms, but not of the lack of a clear description of the essence of the task. Furthermore, more than half of respondents said that getting a huge list of subsequent and related tasks hardly makes their work any easier.
Part two. A reflexive one
Here I share only my own experiences and do not pretend to have absolute knowledge.
A task should always be clear to the person who performs it and accepts it. Its wording should include the necessary context and links to the necessary sources, describe the subtleties of implementation and maintain the focus of the team. After reading the task, the person should understand what is required of them, why the project needs this task, and be able to imagine how they will achieve the result, at least in the first approximation. If there is no such understanding, we probably have problems.
The second question is to what extent the project manager is responsible for this. Depending on the framework that the project uses, different scenarios and levels of self-organization in teams are possible. Thus, a different impact of the PM’s role is possible.
A great option is to involve a business analyst (BA) in this process. These people are typically responsible for a detailed description of the requirements, and the design of fringe cases. At the same time, the PM, not the BA, together with the team, sets the tasks and plans.
In true Agile teams, the role of the PM in the usual sense is leveled. Agile demonstrates to us the value of a self-organizing team that can set achievable and clear tasks on its own. Why does such a team need a manager who sets and controls tasks? At the same time, I don’t see any contradictions.
It’s not so important who technically described the task and set it, if the project manager controlled and organized the final result: the PM made sure that the team understands who should do what, and why. Thus, in my opinion, any additional tweaking of tasks is the responsibility of the PM.
Let me also speak separately about project managers who assign tasks from the top with minimal coordination with the team. What’s wrong with this approach?
- One person’s knowledge is always limited. You can be a cool PM, but your colleagues may have more experience in certain areas. Relying only on your knowledge, you can miss something or lead the team down the wrong path.
- Assigning tasks from the top without discussion eliminates a second opinion in the team, and the opportunity to show initiative by other participants, and can undermine healthy relations in the team.
- Limiting the team’s growth. We grow not only when we take on complex tasks, but also when we are responsible for them. Without giving the opportunity to show this responsibility, the PM limits the growth of the team.
The PM always acts as the project leader and is ultimately responsible for delivering the project. I really love the term ownership — it succinctly reflects my vision of responsibility. I am deeply convinced that a) the project manager’s personal responsibility and involvement; and b) correct task setting, are both important factors for the success of any project.
The feedback from my former and current colleagues has confirmed and continues to confirm that everyone likes to be on the same page. No exceptions for a PM.
Part three. An ironic one
When I was a child, I enjoyed a cartoon about Imp Number 13. It’s a funny cartoon about an inverted world. What if the imp grew up, realized his mission, and began to teach at one of the PM schools? Perhaps this is what he could advise his students in terms of setting tasks in this backwards world.
- Write long task descriptions.
The longer the better! It’s not your job to keep the team focused on what’s important. It’s better to write everything that you can, and then say: “Oh, I told you so!” — or “Here at the bottom (see where it is crossed out, and then in a smaller font?) it’s written…”
2. Actually, it’s better not to write descriptions at all.
Who even reads these tasks? Let’s just ignore task descriptions altogether and save time for you and your team. The best tip ever — paste a one-sentence description of the task as a title and leave the description empty. The team will guess, they have to share the context. That’s what Agile is for.
3. Set tasks out loud.
More meetings! And fewer notes. It’s better to discuss all questions in voice — it’s much faster to articulate than to write something down. It’s no big harm that the whole team spends an extra hour of their lives on another call. You are saving time on writing descriptions in JIRA. The team is smart, and they’ll figure out themselves what to do and what not to do.
4. The more sources of truth, the better.
More sources, more! The standard of your project should be as follows: a task board (you can have several), Confluence, some separate document in the cloud storage, and, preferably, a diagram that no one will ever update. Make all changes silently and randomly. A real developer should be a detective: let them show their abilities — they may suffer, but they’ll find all the necessary requirements eventually, and independently resolve all conflicts.
5. Never analyze a task.
If the client or the product owner has set the task themselves, don’t analyze it by any means! You aren’t a business analyst. Your goal is to manage, and your responsibility is to ask: “When will it be ready?!”
6. Ignore acceptance criteria and fringe cases
After all, this is the job of a tester. Or an architect. Or a business analyst. You don’t have them in your project? Then a developer will have to figure it out. Although it would be better for the client to think about everything in advance.
7. Don’t link the task to the epic or related items
Everyone understands what it’s all about. And if someone doesn’t understand — they need to work on their context. Everything is in JIRA!
All of the above points, of course, are not a guide to action, but irony and self-irony about our mistakes. What do you think?
The text expresses the personal opinion of the author, who is open to both cookies and rotten tomatoes.
Russian version of the article was featured in DataArt blog.
