While finding ideas for new articles, I stumbled upon an article of a Japanese uncle writing about project management, found it quite practical, not cliché theory so I would like to translate for you. Any need to consult. Starting from here will be the translation, so I will use the first person of uncle Japan always. : kissingheart:
Normally I am a Backend developer but recently I have a chance to support a project as Project Manager (PM). I have not seen the specific actions that should be taken with a PM so this time I will try to write down my own specific actions. I hope it helps someone who doesn’t know what jobs PM should do?
I came from an SIer (System integrator -er) of NTT Data Group and then moved on to develop internal web of a private company, so I experienced working with Water fall, as well as Agile or Scrum during his years as SIer.
However, that does not mean that I have a degree in PM (PMP for example), so I still have a very personal style, but because it was applied very well in practice so I think it will not There are many differences.
Although the following actions are said to be Agile development models, the assumption is that they are developed with a large number of Stakeholders. On the contrary, with a small development model, there are too many things, so it needs to perform many necessary actions with steady state.
Actions are divided into two main categories, Process and Task. For Process, the main task is Visualization and Innovation, while for Tasks it is important to prioritize.
1. Create WBS
For large-scale development teams, it is important for stakeholders to know who will do what and when to finish. Therefore, creating WBS (Work Breakdown Structure) is very important. Once created, using WBS will help to grasp the current progress of the project, whether it is behind the deadline or not.
2. Check the project progress every day
Even though you’ve created WBS, if you don’t update it, it doesn’t make much sense. The schedule should be updated daily in sessions such as morning MTG, afternoon MTG, or daily scrum, etc. Especially, when the schedule is slow, to quickly find the cause, it is even more necessary.
3. Always adjust and update information
Updating does not mean just updating progress. There should be a place to easily store the latest status of information such as Specs or other external adjustments. The information needs to be organized and organized in layers (for example, in the form of trees below), instead of being arranged in a messy, junk on Wiki. Correction of information based on unknown perceptions or vague information should be avoided.
- Product Core
4. Implementation of the PDCA cycle
I do not think that by doing this 100% project will be successful. That’s because the level of maturity of the members is always changing and the stakeholders are also changing. However, this can help reduce the project’s failure rate.
When faced with a problem in a project, it’s good to look back and propose improvement measures, right? Technically, it is okay to use KPT or SSS. In terms of timing, for projects that are still weak, the good times are weekly, during reevaluation meetings or retrospective meetings. During those meetings will decide Next Action on current issues and make improvements.
For tasks it is important to decide the priority, clarify who will be responsible and how to bring that task to the Done state.
First, it’s important to decide the priority. By completing the items below, the determination of priority will be clarified.
5. Know the content of the entire task
The content of the task is not just to leave the Dev to the task, but the manager should also understand what the task is about. If there are any places do not understand must confirm immediately with Dev. Doing this will provide an understanding of the interdependencies between tasks.
6. Prioritize tasks with more Stakeholders
In particular, priority should be given to handling tasks that are related to the outside, such as those that are likely to cause congestion due to external dependencies, to quickly pass that task to other parties. This is because even if you try to handle the task urgently, it may be due to the resource situation on the other side that the task cannot be closed. Therefore, the need to prioritize early resolution of those tasks.
7. Understand the task’s dependencies
Understand which task dependencies are resolved, which tasks are allowed to begin. If you know this, you can consider whether you can solve the tasks in parallel or not.
8. Quickly handle congested tasks
This is similar to the task’s dependency relationship. If the bottlenecking task is not handled, the following tasks will be delayed, so tasks like that will greatly affect other tasks that need to be prioritized for higher processing.
9. Uncertain tasks need to be reviewed quickly
For uncertain tasks such as investigating a hogehoge or an outside cause that is unknown when it will be completed, it is necessary to promptly investigate and handle it. For example, when applying a new technique, it is necessary to quickly identify the architecture and request new applications to reduce uncertainty. With the increased feasibility, the insecurity of the schedule will be removed.
Tasks that have decided on priority need to update their status until the end.
10. Clarify who is performing the task
Clarifying who will perform the task makes it easier to capture the exact progress of the task. In case there are many people in charge of the task and must meet all the conditions, it is necessary to split the task.
11. Do not increase the tasks in progress, but make them done
Care should be taken when a large number of tasks are in progress. Because it’s hard to know how many percent of In progress tasks are being completed. In addition, it is possible to keep a relaxed spirit by completing task routines instead of increasing the number of tasks in progress.
12. Do not blame the members
In addition to process-related issues, the task has a very important job. Although the tasks are performed by members, the ultimate responsibility is the Project Manager (PM). The incompetent manager will simply rely on the members’ abilities and say “Fighting!”. But the task of PM is to try to keep the progress of the project stable by adjusting the scope, adjusting the schedule, allocating personnel for backup plans. For tasks that are behind schedule, it is necessary to discuss with the appropriate member to solve them together, eliminating anxiety.
Although there are details other than those listed above, I think the outcome is that PM is responsible for knowing the status of the project to eliminate ambiguities. project. In addition, it is important to make every effort to keep the project in good standing, rather than identifying the team members.
I think that in this way, the development team will keep QCD (Quality – Cost – Delivery) high and continuous, thereby bringing better values to the users.
Original article here