CHAPTER 7: MOVING AN EXISTING WATERFALL PROJECT TO PRINCE2 AGILE

If you have an existing project that has been delivered using waterfall methods and you want to transition the project (or subsequent stages of the project) to PRINCE2 Agile, there are two different approaches to use, depending on whether or not the existing project has been delivered within a PRINCE2 framework.

If your existing waterfall project uses PRINCE2

If the existing project already has a PRINCE2 framework, it is recommended that you use the steps detailed in Chapter 5: Moving from PRINCE2 to PRINCE2 Agile with the following variations:

Step 0: Take a pulse point

For an existing waterfall project, this is an opportunity to review what work has been produced by the team, including previous outputs, outstanding requirements, documentation, and lessons learned.

As these project artifacts will most likely align with PRINCE2 requirements, they could theoretically be used as the baseline for developing equivalent PRINCE2 Agile project documentation; however, it may be more valuable to consider them good sources of historical information, and to create new project documents that are fully compliant with the structure and principles of PRINCE2 Agile moving forward, as described in the following steps.

Step 1: Identify the right project team

In this situation, the Project Board members will have most likely already been identified. The key is to identify the project delivery team that can support the selected Agile delivery method. This may be the existing project team (especially if they have intimate knowledge of existing deliverables) with the appropriate Agile training.

Step 2: Establish a shared vision

This would be approached in the same way as moving any team to a PRINCE2 Agile model as described in Chapter 5: Moving from PRINCE2 to PRINCE2 Agile.

Step 3: Define the outcomes and outputs

This would be approached in the same way as moving any team to a PRINCE2 Agile model, with the exception that there may be existing requirements documents that need to be transitioned to be PRINCE2 Agile artifacts (e.g. turning detailed specification documents into user stories and prioritizing them in a product backlog).

Step 4: Define the release plan

This would be approached in the same way as moving any team to a PRINCE2 Agile model, with the caveat that referring to previously produced waterfall project plans could actually prove to be a disservice to the PRINCE2 Agile project planning. It is better for the project team to extract any known milestone dates from the waterfall project plan as input into ongoing PRINCE2 Agile planning – and then break away completely from the previous plan in favor of the responsive Agile planning model.

Step 5: Define the tolerances

This would be approached in the same way as moving any team to a PRINCE2 Agile model.

Step 6: Choose your tools

This would be approached in the same way as moving any team to a PRINCE2 Agile model.

Step 7: Get approval for the baseline PID

This would be approached in the same way as moving any team to a PRINCE2 Agile model, with the caveat that referring to the previously produced waterfall PID could also be a disservice to the PRINCE2 Agile project planning. Similar to Step 4, it is better for the project team to extract any critical information from previously produced PID(s) and other project planning documents, and then archive them as historical documents.

Step 8: Start the project work

This would be approached in the same way as moving any team to a PRINCE2 Agile model.

Step 9: Monitor the project work

This would be approached in the same way as moving any team to a PRINCE2 Agile model.

Step 10: Close the project

This would be approached in the same way as moving any team to a PRINCE2 Agile model, with the exception that the project documentation may need to include both the historical waterfall artifacts and the PRINCE2 Agile artifacts.

If your existing waterfall project uses a different governance structure (or no formal governance structure)

If your existing waterfall project does not already have a PRINCE2 framework, it is recommended that you use the steps detailed in Chapter 8: Implementing PRINCE2 Agile with No Existing Framework, with any existing waterfall project documentation being used only as information sources and then archived.