Possible way around the Pareto rule
Hello,
I propose to discuss one of the possible solutions to the 20/80 problem that is actually used in our company.
Many project managers know the Pareto law (generally stated as “20% of effort gives 80% of the result, and the remaining 80% of effort only 20% of the result”), in our variant “80% of resources are required for the last 20% of the project”. Simply put, the project really start to do 3 days before the opening. As a result: a break, deadline, poor quality, running, stress and other pleasures of PM.
A common mistake is to give the developers the TZ and wait for them to do everything, and then start checking. This works when the project is very small. So, it’s necessary to make several small projects out of one big project. Through trial and error for ourselves, we found a solution, conditionally called “weekly iterations” (although these are not iterations in the full sense, when each iteration is a mini-project that includes all phases, from analysis to implementation) - the tasks are combined into an iteration, so they can be completed in a week. Now the most important thing is that the iteration should be done completely and verified.
Now in order:
Of course, such a process is more difficult to organize and it seems that it creates an additional burden on the manager, but in fact, the load is normalized and distributed more evenly on the project manager and the entire team. In actual operation, a situation where a task package was transferred to a customer and the team waits for a response would cause a downtime. Therefore, the “iterations” should go with imposition, i.e.
If by the 4th week there are still unfinished tasks for the 1st and 2nd iterations, then it is necessary to concentrate efforts on them and not to take the 4th iteration into work.
')
The bonuses that we get from this approach:
I propose to discuss one of the possible solutions to the 20/80 problem that is actually used in our company.
Many project managers know the Pareto law (generally stated as “20% of effort gives 80% of the result, and the remaining 80% of effort only 20% of the result”), in our variant “80% of resources are required for the last 20% of the project”. Simply put, the project really start to do 3 days before the opening. As a result: a break, deadline, poor quality, running, stress and other pleasures of PM.
A common mistake is to give the developers the TZ and wait for them to do everything, and then start checking. This works when the project is very small. So, it’s necessary to make several small projects out of one big project. Through trial and error for ourselves, we found a solution, conditionally called “weekly iterations” (although these are not iterations in the full sense, when each iteration is a mini-project that includes all phases, from analysis to implementation) - the tasks are combined into an iteration, so they can be completed in a week. Now the most important thing is that the iteration should be done completely and verified.
Now in order:
- All work is divided into separate tasks. When the project is divided into tasks, you can organize the proper management of these tasks.
- Tasks are combined into packages of about a week (depending on the number of developers the size of the package may vary)
- Main feature: the tasks are handed over to the customer in parts (packages), every week - this allows us to understand many important things at the beginning of the project:
- The correctness of the assessment of the complexity of tasks
- Adequacy and responsibility of the customer
- How good is the team’s result? - It is important to bring the solution to the end, because only the task accepted by the customer can be considered completed, i.e. not just transfer the task package to the customer for acceptance, but ensure that the customer accepts the job (and, accordingly, fix the bugs)
Of course, such a process is more difficult to organize and it seems that it creates an additional burden on the manager, but in fact, the load is normalized and distributed more evenly on the project manager and the entire team. In actual operation, a situation where a task package was transferred to a customer and the team waits for a response would cause a downtime. Therefore, the “iterations” should go with imposition, i.e.
- 1st week - we perform the 1st package of work and prepare (internal testing) for transfer to the Customer
- 2nd week - we transfer the 1st package to the customer and we carry out the 2nd package of work. It is important that the error correction for the 1st iteration goes with the highest priority.
- 3rd week - close the 1st package, correct errors on the 2nd package, do the 3rd package
If by the 4th week there are still unfinished tasks for the 1st and 2nd iterations, then it is necessary to concentrate efforts on them and not to take the 4th iteration into work.
')
The bonuses that we get from this approach:
- A clear understanding of the current state of the project and deviation from the plans, an understanding of “what remains to be done for the delivery of the work phase” (and receiving payment)
- Understanding the "balance of power" - how many tasks on the side of the contractor, and how many on the side of the customer
- Significant reduction in the effect of 20/80
- Reducing risks in relations with the customer (delivery of works begins at the very beginning)
- Reducing the number of new requirements and disputes on their account: figured out the task, did, passed
- Cost reduction - correcting errors in newly written code is much cheaper than after 3 months
Source: https://habr.com/ru/post/102237/
All Articles