July 20, 2010 at 11:40Helpful Hints: Managing Projects in a Changing Environment
I propose to discuss one of the possible solutions to the problem of changing requirements used in our company.
Before moving on to the description of specific solutions and tools, a few words about the policy regarding the new requirements. Perhaps the most important thing that we understood is that the requirements are always changing and instead of “fighting the elements” we must learn to manage changing requirements. Of course, there is TK and a budget, but often negotiations to include new requirements are more expensive than the changes themselves. On the other hand, you can’t do whatever 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 pastime is organizing development processes and developing automation tools for this very development.
But for a couple of years now we haven’t been doing this almost, although there is 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, but I will talk about one of the main techniques in our work. We call it “basic tickets”.
It doesn’t matter what automation tools are used: tracker, exel or stickers. The primary principles and processes of the organization. So, the essence of the approach is very simple - before starting the development, a complete list of project tasks is compiled, a sort of To-Do list for the project (scientifically called Work Breakdown Structure, WBS). It is most convenient to do it in Excel, because there are autofilters and a hierarchy. It is important that WBS includes all the tasks that need to be done to complete the project (if previously unaccounted tasks appear, they must also be added to the list of jobs, you can use the “new” flag). We select a task scale from 4 to 16 hours of development. It's okay if there are several hundred tasks - they can be combined into subprojects and iterations.
And now the main trick is that a ticket is created for each task from WBS in our tracker with the full statement of this task (or in any system where you can conduct a discussion on the principle of 1 task = 1 tape). We can say that this is a case-based approach (use case, user story). We, tickets have an indicator - on which side the task is at the moment (again, this can be noted in Excel). As the development of the task (tickets) are handed over to the customer, and already at the beginning of development we receive feedback from the customer.
For the leader, this approach allows us to evaluate the pace and quality of development at the very beginning (for example, if a poor-quality result is transmitted to the customer, he will quickly express it and there will be an opportunity to correct the situation and get a new response).
But the main thing in the "Basic Tickets" 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 the "waterfall" does not work in them (wrote TK - made), as, for example, in construction. Those who say that the requirements are not changing, most likely simply did not conduct real projects. You could even say that IT project management is the management of requirements. Moreover, everything changes the requirements - both a large corporate employee, and an internal customer, and even a small office. Having basic tickets is always easy to see the initial setting.
Thus, we gain relevant knowledge about the state of the project and its requirements without separate document management or a wiki with current requirements. Typically, a separate history of requirements change is not relevant or requires inadequate management efforts to maintain it. The state of the project is also completely real, because the tasks are accepted by the customer (that is, instead of the abstract “we have almost everything ready,” we know how many tasks are accepted by the customer, how many are sent for revision, which have not yet been transferred, etc.)
Organizing our processes, we took as a basis different techniques (from RUP to XP), adding something of our own. Naturally, our approach does not pretend to be absolute truth (either novelty or originality), but it works for us, so it can also be useful to someone else. If something remains incomprehensible or there are counter offers, I will be glad to discuss.
UPD:
Complementing with fair remarks.
In this post, I wrote more about the technical approach and did not answer the question of what to do 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 end-to-end work is likely to go negative.
2) Before making any changes, you need to be sure that this change is really needed and will make the project better (this can and should be discussed with the customer)
3) Changes should be made only after debugging and delivery of functional acceptance according to the ToR
4) Naturally, the process should be iterative Until the iteration is complete, you cannot make changes to it. The change package is drawn up 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 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 the strategy, we need to strive to release the version as soon as possible (open the site to work), because before the opening of the requirements are one, and after a month of real work, they are completely different.
Before moving on to the description of specific solutions and tools, a few words about the policy regarding the new requirements. Perhaps the most important thing that we understood is that the requirements are always changing and instead of “fighting the elements” we must learn to manage changing requirements. Of course, there is TK and a budget, but often negotiations to include new requirements are more expensive than the changes themselves. On the other hand, you can’t do whatever 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 pastime is organizing development processes and developing automation tools for this very development.
But for a couple of years now we haven’t been doing this almost, although there is 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, but I will talk about one of the main techniques in our work. We call it “basic tickets”.
It doesn’t matter what automation tools are used: tracker, exel or stickers. The primary principles and processes of the organization. So, the essence of the approach is very simple - before starting the development, a complete list of project tasks is compiled, a sort of To-Do list for the project (scientifically called Work Breakdown Structure, WBS). It is most convenient to do it in Excel, because there are autofilters and a hierarchy. It is important that WBS includes all the tasks that need to be done to complete the project (if previously unaccounted tasks appear, they must also be added to the list of jobs, you can use the “new” flag). We select a task scale from 4 to 16 hours of development. It's okay if there are several hundred tasks - they can be combined into subprojects and iterations.
And now the main trick is that a ticket is created for each task from WBS in our tracker with the full statement of this task (or in any system where you can conduct a discussion on the principle of 1 task = 1 tape). We can say that this is a case-based approach (use case, user story). We, tickets have an indicator - on which side the task is at the moment (again, this can be noted in Excel). As the development of the task (tickets) are handed over to the customer, and already at the beginning of development we receive feedback from the customer.
For the leader, this approach allows us to evaluate the pace and quality of development at the very beginning (for example, if a poor-quality result is transmitted to the customer, he will quickly express it and there will be an opportunity to correct the situation and get a new response).
But the main thing in the "Basic Tickets" 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 the "waterfall" does not work in them (wrote TK - made), as, for example, in construction. Those who say that the requirements are not changing, most likely simply did not conduct real projects. You could even say that IT project management is the management of requirements. Moreover, everything changes the requirements - both a large corporate employee, and an internal customer, and even a small office. Having basic tickets is always easy to see the initial setting.
Thus, we gain relevant knowledge about the state of the project and its requirements without separate document management or a wiki with current requirements. Typically, a separate history of requirements change is not relevant or requires inadequate management efforts to maintain it. The state of the project is also completely real, because the tasks are accepted by the customer (that is, instead of the abstract “we have almost everything ready,” we know how many tasks are accepted by the customer, how many are sent for revision, which have not yet been transferred, etc.)
Organizing our processes, we took as a basis different techniques (from RUP to XP), adding something of our own. Naturally, our approach does not pretend to be absolute truth (either novelty or originality), but it works for us, so it can also be useful to someone else. If something remains incomprehensible or there are counter offers, I will be glad to discuss.
UPD:
Complementing with fair remarks.
In this post, I wrote more about the technical approach and did not answer the question of what to do 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 end-to-end work is likely to go negative.
2) Before making any changes, you need to be sure that this change is really needed and will make the project better (this can and should be discussed with the customer)
3) Changes should be made only after debugging and delivery of functional acceptance according to the ToR
4) Naturally, the process should be iterative Until the iteration is complete, you cannot make changes to it. The change package is drawn up 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 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 the strategy, we need to strive to release the version as soon as possible (open the site to work), because before the opening of the requirements are one, and after a month of real work, they are completely different.