Useful tips: project management in the face of changing requirements
I propose to discuss one of the possible solutions to the problem of changing requirements, used in our company.
Before turning to the description of specific solutions and tools, a few words about the policy on new requirements. Perhaps the most important thing that we understand is that requirements always change and instead of “fighting the elements”, one must learn to manage changing requirements. Of course, there is a budget and a budget, but often negotiations on the inclusion of new requirements are more expensive than the changes themselves. On the other hand, you cannot do what the customer wants - then the project will never be launched at all. Therefore, the requirements must be managed.
Since our company consists of managers and programmers, our favorite activity is the organization of development processes and the development of automation tools for this development itself.
But now, as a couple of years, we almost do not do this, although there is both time and money. It's simple - after a long search, we found a solution that works stably for us. As part of this post, I will not talk about everything - it will turn out too much, and tell you about one of the main techniques in our work. We call it "basic tickets."
It does not matter what automation tools are used: tracker, Excel or stickers. Primary principles and processes of organization. So, the essence of the approach is very simple - before the start of development a complete list of project tasks is drawn up, a sort of To-Do list for a project (in a scientific way it is called Work Breakdown Structure, WBS). It is most convenient to do it in Excel, because there are autofilters and hierarchy. It is important that the WBS include all the tasks that need to be done to complete the project (if previously unrecorded tasks appear, they should also be added to the list of jobs, with the “new” flag. We choose the scale of tasks from 4 to 16 hours of development. Nestrashno, if there are several hundred tasks - they can be combined into subprojects and iterations.
And now the main trick - for each task from WBS, a ticket is created in our tracker with the full formulation of this task (or in any system where you can conduct a discussion on the principle 1 task = 1 tape). It can be said that this is a use case, user story approach. We, tickets have an indicator - on which side the task is at the moment (again, this can be noted in Excel). As tasks develop (tickets) are handed over to the customer and at the beginning of development we receive feedback from the Customer.
')
For the head, this approach allows you to assess the pace and quality of development at the very beginning (for example, if the customer transmits a poor-quality result, he quickly expresses this and will be able to correct the situation and get a new response).
But the main thing in "Basic Ticket" is, of course, tracking the changing requirements. In general, changing requirements are one of the most serious problems of IT projects, and that is why the principle of a “waterfall” does not work in them (wrote TK - did), such as in construction. Those who say that the requirements do not change, most likely simply did not conduct these projects. You could even say that IT project management is the requirements management. And the requirements change everything - both a large corporate employee, and an internal customer, and even a small office. Having basic tickets is always easy to see the original production.
Thus, we get current knowledge about the state of the project and its requirements without separate maintenance of documents or a wiki with current requirements. Usually, a separate maintenance of the history of changes in requirements is not relevant or requires inadequate management efforts to maintain it. The state of the project is also completely realistic, because the customer accepts the tasks (instead of the abstract “almost everything is ready with us”, we know how many tasks are accepted by the customer, how many are sent for revision, which have not yet been transferred, etc.)
By organizing our processes, we took different techniques as a basis (from RUP to XP), adding something of our own. Naturally, our approach does not pretend to absolute truth (and novelty or originality), but it works for us, so it may also be useful to someone else. If something remains unclear or there are counter proposals, I will be glad to discuss.
UPD:
I supplement the fair comments.
In this post I wrote more about the technical approach and did not answer the question of how to be, when the requirements change.
1) Initially, you need to lay a small margin (in the budget, terms) for changing requirements. The project adopted in the work "butt" is likely to go into the minus.
2) Before making any changes, you need to be sure that this change is really necessary and will make the project better (this can and should be discussed with the customer)
3) Changes should be made only after debugging and acceptance of functionality for TK
4) Naturally, the process should be iterative, until the iteration is completed, it cannot be amended. The package of changes is made in a separate iteration.
5) In order for the process to be controlled and the customer to make only really important changes, we give a pool of hours (for example, 100) of a free appointment that the customer can spend. Naturally, discussing with the customer the introduction of certain changes, he needs to explain how long it will take and how many hours he has left.
In complex projects, it is very important to first get a stable version, and only then make changes to it.
If we talk about strategy, then we should strive to release the version as soon as possible (open the site to work), because before opening the requirements are one, and after a month of real work, they are completely different.
Before turning to the description of specific solutions and tools, a few words about the policy on new requirements. Perhaps the most important thing that we understand is that requirements always change and instead of “fighting the elements”, one must learn to manage changing requirements. Of course, there is a budget and a budget, but often negotiations on the inclusion of new requirements are more expensive than the changes themselves. On the other hand, you cannot do what the customer wants - then the project will never be launched at all. Therefore, the requirements must be managed.
Since our company consists of managers and programmers, our favorite activity is the organization of development processes and the development of automation tools for this development itself.
But now, as a couple of years, we almost do not do this, although there is both time and money. It's simple - after a long search, we found a solution that works stably for us. As part of this post, I will not talk about everything - it will turn out too much, and tell you about one of the main techniques in our work. We call it "basic tickets."
It does not matter what automation tools are used: tracker, Excel or stickers. Primary principles and processes of organization. So, the essence of the approach is very simple - before the start of development a complete list of project tasks is drawn up, a sort of To-Do list for a project (in a scientific way it is called Work Breakdown Structure, WBS). It is most convenient to do it in Excel, because there are autofilters and hierarchy. It is important that the WBS include all the tasks that need to be done to complete the project (if previously unrecorded tasks appear, they should also be added to the list of jobs, with the “new” flag. We choose the scale of tasks from 4 to 16 hours of development. Nestrashno, if there are several hundred tasks - they can be combined into subprojects and iterations.
And now the main trick - for each task from WBS, a ticket is created in our tracker with the full formulation of this task (or in any system where you can conduct a discussion on the principle 1 task = 1 tape). It can be said that this is a use case, user story approach. We, tickets have an indicator - on which side the task is at the moment (again, this can be noted in Excel). As tasks develop (tickets) are handed over to the customer and at the beginning of development we receive feedback from the Customer.
')
For the head, this approach allows you to assess the pace and quality of development at the very beginning (for example, if the customer transmits a poor-quality result, he quickly expresses this and will be able to correct the situation and get a new response).
But the main thing in "Basic Ticket" is, of course, tracking the changing requirements. In general, changing requirements are one of the most serious problems of IT projects, and that is why the principle of a “waterfall” does not work in them (wrote TK - did), such as in construction. Those who say that the requirements do not change, most likely simply did not conduct these projects. You could even say that IT project management is the requirements management. And the requirements change everything - both a large corporate employee, and an internal customer, and even a small office. Having basic tickets is always easy to see the original production.
Thus, we get current knowledge about the state of the project and its requirements without separate maintenance of documents or a wiki with current requirements. Usually, a separate maintenance of the history of changes in requirements is not relevant or requires inadequate management efforts to maintain it. The state of the project is also completely realistic, because the customer accepts the tasks (instead of the abstract “almost everything is ready with us”, we know how many tasks are accepted by the customer, how many are sent for revision, which have not yet been transferred, etc.)
By organizing our processes, we took different techniques as a basis (from RUP to XP), adding something of our own. Naturally, our approach does not pretend to absolute truth (and novelty or originality), but it works for us, so it may also be useful to someone else. If something remains unclear or there are counter proposals, I will be glad to discuss.
UPD:
I supplement the fair comments.
In this post I wrote more about the technical approach and did not answer the question of how to be, when the requirements change.
1) Initially, you need to lay a small margin (in the budget, terms) for changing requirements. The project adopted in the work "butt" is likely to go into the minus.
2) Before making any changes, you need to be sure that this change is really necessary and will make the project better (this can and should be discussed with the customer)
3) Changes should be made only after debugging and acceptance of functionality for TK
4) Naturally, the process should be iterative, until the iteration is completed, it cannot be amended. The package of changes is made in a separate iteration.
5) In order for the process to be controlled and the customer to make only really important changes, we give a pool of hours (for example, 100) of a free appointment that the customer can spend. Naturally, discussing with the customer the introduction of certain changes, he needs to explain how long it will take and how many hours he has left.
In complex projects, it is very important to first get a stable version, and only then make changes to it.
If we talk about strategy, then we should strive to release the version as soon as possible (open the site to work), because before opening the requirements are one, and after a month of real work, they are completely different.
Source: https://habr.com/ru/post/99495/
All Articles