Deployment Planning

From EUDP
Jump to: navigation, search

What

A plan showing the deployment of the prototype to the customer.

DeploymentPlanning.png

How

The dish

Deployment Planning

Ingredients

  • All artefacts 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 a 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 receive, 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 and the conclusions based on the 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 s/he is on the right track.

Why

During development of especially IT systems, it is particularly important that the customer is given some physical evidence of the project progress. Many 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 live up to expectations. 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 to make adjustments to the overall specifications of the project very early in the project phase, which again will likely 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 frequent deadlines in contrast to traditional development plans where deadlines are often 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 you follow the 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 success, and can still gain important feedback from the customer.

Example

DeploymentPlan.png

An example of an uncomplete deployment plan.

Finally, the Development Planning Realisation ends the planning processes.