Deployment Planning
What
A plan showing the deployment of the prototype to the customer.
How
The dish
Deployment Planning
Ingredients
- All artifacts produced in the project so far.
- Experiences and metrics from previously performed projects
Process
The Realisation Phase is an iterative process where the product is implemented and released part by part. The realisation is conducted through several iterations where the analysis and design are refined. The product is partly implemented and tested during each timebox resulting in a prototype with higher and higher implementation degree deployed to the customer.
As a part of the development plan, a deployment plan is made in cooperation with the customer. This plan describes which versions of the prototype the customer will get, at what time and with what functionality. Except for the first one or two timeboxes the length of each timebox is the same, and consequently the deployment can easily be planned. Please note: the result of the in-depth analysis performed in the first one or two timeboxes should also be deployed to the customer to ensure that the developer is still on the right track.
The customer could give a written accept of the deployment, but normally it is enough that the customer simply tells the developer that he is on the right track.
Why
During development of especially IT systems, it is particularly important that the customer gets some physical evidence of the project progress. A lot of IT projects have failed in the past, because a customer received a final product which in fact was not what he had wanted. In other words it did not fulfil his wishes. Therefore, it is necessary for the developer and the customer to make a plan which describes a deployment of the prototype. Additionally, it should also describe the performance the customer can expect of the prototype. This will give the customer the possibility of making adjustments to the overall specifications of the project very early in the project phase , which again possibly will result in a new plan, because some of the prerequisites have changed. But often the customer will be happy to pay a higher price for the right product, instead of paying the "right" price for the wrong product.
A positive side effect of frequent deployments is that the developer has deadlines coming up rather frequently in contrast to traditional development plans where deadlines often are sparsely distributed over the project period. The developer keeps the focus on the next delivery which is within a short time frame.
Another positive side effect is that the project management has concrete evidence of progress in the project by the application of frequent deployments. Hence, they are not left with spoken or written reports from the developers.
It is essential that we follow the time plan and deploy what has been implemented and verified, rather than delay the delivery. If some functionality is not ready for deployment as planned, the functionality should be removed from the deployment and planned for later deployment. The customer can still see some progress, and the development team will get the feeling of succes and can still gain important feedback from the customer.
