August 20, 2010 at 13:01Possible way to get around the Pareto rule
Hello everyone, 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 (in the general form it is formulated as “20% of efforts yield 80% of the result, and the remaining 80% of efforts give only 20% of the result”), in our version “80% of the resources are required for the last 20% of the project." Simply put, the project is really starting to be done 3 days before the opening. As a result: emergency, failure to meet deadlines, poor quality, running around, stress and other pleasures of PM'a.
A common mistake is to give developers TK and wait until they do everything, and then start checking. This works when the project is very small. So, you need to make several small ones from one large project. Through trial and error, we found a solution for ourselves, which we conventionally called "weekly iterations" (although this is not iteration 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 so that they can be completed in a week. Now the most important thing is that the iteration has to be done completely and verified.
Now, in order:
Of course, such a process is more difficult to organize and it seems that this creates an additional load on the manager, but in fact, the load is normalized and distributed more evenly on the project manager and the whole team. In a real job, a situation where a task package was handed over to the customer and the team is waiting for an answer would cause downtime. Therefore, “iterations” must go with superposition, i.e.
If by the 4th week there still remained unfinished tasks for the 1st and 2nd iteration, then you need to focus on them and not take the 4th iteration into work.
Bonuses that we get from this approach:
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 (in the general form it is formulated as “20% of efforts yield 80% of the result, and the remaining 80% of efforts give only 20% of the result”), in our version “80% of the resources are required for the last 20% of the project." Simply put, the project is really starting to be done 3 days before the opening. As a result: emergency, failure to meet deadlines, poor quality, running around, stress and other pleasures of PM'a.
A common mistake is to give developers TK and wait until they do everything, and then start checking. This works when the project is very small. So, you need to make several small ones from one large project. Through trial and error, we found a solution for ourselves, which we conventionally called "weekly iterations" (although this is not iteration 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 so that they can be completed in a week. Now the most important thing is that the iteration has to be done completely and verified.
Now, in order:
- All work is divided into separate tasks. When a project is broken down into tasks, you can organize the proper management of these tasks
- Tasks are combined in packages of about a week in size (depending on the number of developers, the size of the package may vary)
- The main feature: the tasks are handed over to the customer in parts (packages), every week - this allows you to understand many important things at the beginning of the project:
- The correctness of the assessment of the complexity of the tasks
- The adequacy and responsibility of the customer
- How high-quality result the team gives - It is important to complete the solution of problems, because Only the task accepted by the customer can be considered completed, i.e. not just transfer the package of tasks to the customer for acceptance, but will ensure that the customer accepts the work (and, accordingly, fix bugs)
Of course, such a process is more difficult to organize and it seems that this creates an additional load on the manager, but in fact, the load is normalized and distributed more evenly on the project manager and the whole team. In a real job, a situation where a task package was handed over to the customer and the team is waiting for an answer would cause downtime. Therefore, “iterations” must go with superposition, i.e.
- 1st week - we carry out 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 carry out the 2nd package of work. It is important that error correction at the 1st iteration proceeds with the highest priority.
- 3rd week - close the 1st package, correct errors on the 2nd package, make the 3rd package
If by the 4th week there still remained unfinished tasks for the 1st and 2nd iteration, then you need to focus on them and not take the 4th iteration into work.
Bonuses that we get from this approach:
- A clear understanding of the current state of the project and deviation from plans, understanding “what remains to be done to complete the work phase” (and receive payment)
- Understanding the "balance of power" - how many tasks are on the performer’s side, and how many are on the customer’s side
- Significantly reduced effect 20/80
- Risk reduction in relations with the customer (the delivery of work begins at the very beginning)
- Reducing the number of new requirements and disputes on their account: figured out the task, did, passed
- Cost reduction - it is much cheaper to correct errors in the code just written than after 3 months