Agile application in a fixed phase contract
You are the head of a customized project. You brought the contract, it is not known by whom and as a prisoner, gave the customer's contacts and then you left to yourself. Having studied the functional scope of the project, you understand that in this case it would be correct to apply Agile. But the contract has already spelled out clear phases in accordance with the cascade model of development (waterfall) with deadlines, results and a fixed price for each stage. What to do in this situation?
Make sure that it is for your project that the Agile methodology and high iterative development cycles provide significant benefits. If, for example, you build a hydroelectric power plant, then starting from a small paddle wheel and gradually turning it over will not be the best idea. The same applies to the large-scale implementation of the ERP system, when a separate project team is working on each module, they all need to be integrated and earn at the same time — there is no need to work out a high-quality blueprint and a unified phased plan. But if your task is local enough, you have a compact project team, close interaction with the customer, that is, all the prerequisites for using Agile.
So, in accordance with the methodology of Agile, you have determined the minimum functionality that is of greatest importance to the customer and, in the shortest possible time, launched it into productive operation. Then you start every two weeks to post updates, add features and correct comments. The first ambush awaits you when the deadline for the completion of the design phase of the contract is suitable (Figure 3).
')
Fig. 3 Closing the Design Phase
Under the contract, by this time you must pass the TK for the entire functionality, and you really did not examine it, because you were busy launching the first release. What to do? In fact, nothing terrible about it, you just hand over the TK in which all the functionality is described very high-level (you can directly copy the wording from the contract), and according to the functions that you have already examined or even implemented, you give a detailed specification. Almost always the customer will react to this loyally. He received the most important functionality for him very quickly, the comments are corrected promptly, he has no reason not to trust you, he cannot wait to move on, and he will easily sign some kind of formal TK.
By the way, this is a very good moment to review the functional scope of the project. The customer may already have suggestions for the already implemented functionality. And you have an excellent chance to exchange these small, clear and necessary for the customer dopfunctions for muddy and dangerous pieces of the requirements of the contract. Just agree on such a replacement with the customer and fix it in the TK without changing the value of the contract and signing additional agreements.
This ambush awaits you further when the deadline for the implementation phase is due.
Fig.4 Closing the implementation phase
At this point, half of the functionality is already working in production, the second half did not really begin to be examined, and you bring an act to the customer, asking you to close the implementation phase. Then he usually clicks something in his head: “How can I close the whole development for them, if I have only received half of it ?!”. For this turn, you need to prepare in advance and meet him fully armed:
After signing the act on the implementation phase, then you can relax. No further pitfalls due to the inconsistency of your methodology and contract are foreseen. Just see what kind of reporting materials you must pass through the implementation phase. Usually there are some data migration protocols, user training protocols, instructions, etc. If before you did everything correctly, then you have these documents already signed in terms of embedded functionality. And most importantly, their signing is put on stream. The customer, routinely signing the next training protocol, will not even replace that it was the last protocol necessary for closing the implementation stage.
Fig.5 Closing the implementation phase
The same with the initial support phase of industrial operation. From the first month of work on the project, you taught the customer that he exposes defects in the bugtracking system for any reason, and you quickly work them out. The customer already understands how the bug differs from the new requirement, how defects are prioritized, and why all defects cannot be assigned a critical priority. When the closing date of the initial support stage is right, you simply unload all the defects caused by the customer during the project, draw up a beautiful report with any statistics and schedules, and send it to the customer along with the act. It is desirable that at this stage you do not have any critical defects. The only thing that remains is to explain to the customer that your project has come to an end, and in order to continue to correct the defects, you must enter into a separate contract for the maintenance of the system.
If you followed these recommendations, then you realized all the advantages of the Agile methodology, that is, you received a useful product that best meets the needs of the customer. At the same time, they met the deadlines and budget originally specified in the contract.
1. Project preparation
Make sure that it is for your project that the Agile methodology and high iterative development cycles provide significant benefits. If, for example, you build a hydroelectric power plant, then starting from a small paddle wheel and gradually turning it over will not be the best idea. The same applies to the large-scale implementation of the ERP system, when a separate project team is working on each module, they all need to be integrated and earn at the same time — there is no need to work out a high-quality blueprint and a unified phased plan. But if your task is local enough, you have a compact project team, close interaction with the customer, that is, all the prerequisites for using Agile.
2. Conceptual Design Stage
So, in accordance with the methodology of Agile, you have determined the minimum functionality that is of greatest importance to the customer and, in the shortest possible time, launched it into productive operation. Then you start every two weeks to post updates, add features and correct comments. The first ambush awaits you when the deadline for the completion of the design phase of the contract is suitable (Figure 3).
')
Fig. 3 Closing the Design Phase
Under the contract, by this time you must pass the TK for the entire functionality, and you really did not examine it, because you were busy launching the first release. What to do? In fact, nothing terrible about it, you just hand over the TK in which all the functionality is described very high-level (you can directly copy the wording from the contract), and according to the functions that you have already examined or even implemented, you give a detailed specification. Almost always the customer will react to this loyally. He received the most important functionality for him very quickly, the comments are corrected promptly, he has no reason not to trust you, he cannot wait to move on, and he will easily sign some kind of formal TK.
By the way, this is a very good moment to review the functional scope of the project. The customer may already have suggestions for the already implemented functionality. And you have an excellent chance to exchange these small, clear and necessary for the customer dopfunctions for muddy and dangerous pieces of the requirements of the contract. Just agree on such a replacement with the customer and fix it in the TK without changing the value of the contract and signing additional agreements.
3. Stage of implementation
This ambush awaits you further when the deadline for the implementation phase is due.
Fig.4 Closing the implementation phase
At this point, half of the functionality is already working in production, the second half did not really begin to be examined, and you bring an act to the customer, asking you to close the implementation phase. Then he usually clicks something in his head: “How can I close the whole development for them, if I have only received half of it ?!”. For this turn, you need to prepare in advance and meet him fully armed:
- You need to explain to the customer in advance why you adhere to the Agile methodology. Tell about the uninterrupted supply of valuable software, risk reduction and all that jazz.
- You can draw a diagram similar to fig. 4 and clearly show that half the work is done, so you want to get half the money.
- It is very good if you have critical defects in functionality that are in productive operation. You say: “How is it that you want us to eliminate defects to you, that is, to carry out the work in step 4, and you still have not paid us for step 2?”. If the implemented system is really useful to the customer, this is a good leverage.
- To make it psychologically easier for the customer to sign an act for you, you can try to implement stubs in the system for the remaining functionality: idle menu items, interfaces without implementation, etc. At the same time, it should be explained that all this will be implemented at the implementation stage, according to the iterative scheme already familiar to him.
- It can be stated that the customer himself is to blame in the current situation, because he could not immediately formulate all the requirements. And you went to meet him and allowed to formulate the requirements gradually throughout the project.
- Constantly remind you that this is only the second phase and the project is still far away.
- Well, use all other standard tools from the arsenal of the project manager: requests, manipulations, exhaustion, threats, blackmail. At this stage, all means are good.
4. The implementation phase
After signing the act on the implementation phase, then you can relax. No further pitfalls due to the inconsistency of your methodology and contract are foreseen. Just see what kind of reporting materials you must pass through the implementation phase. Usually there are some data migration protocols, user training protocols, instructions, etc. If before you did everything correctly, then you have these documents already signed in terms of embedded functionality. And most importantly, their signing is put on stream. The customer, routinely signing the next training protocol, will not even replace that it was the last protocol necessary for closing the implementation stage.
Fig.5 Closing the implementation phase
5. initial maintenance of industrial operation
The same with the initial support phase of industrial operation. From the first month of work on the project, you taught the customer that he exposes defects in the bugtracking system for any reason, and you quickly work them out. The customer already understands how the bug differs from the new requirement, how defects are prioritized, and why all defects cannot be assigned a critical priority. When the closing date of the initial support stage is right, you simply unload all the defects caused by the customer during the project, draw up a beautiful report with any statistics and schedules, and send it to the customer along with the act. It is desirable that at this stage you do not have any critical defects. The only thing that remains is to explain to the customer that your project has come to an end, and in order to continue to correct the defects, you must enter into a separate contract for the maintenance of the system.
If you followed these recommendations, then you realized all the advantages of the Agile methodology, that is, you received a useful product that best meets the needs of the customer. At the same time, they met the deadlines and budget originally specified in the contract.
Source: https://habr.com/ru/post/196916/
All Articles