Create Initial WBS

For our sample Planning and Preparation Plan we’re running a UAT test phase for a medium-to-large SAP implementation project. As this is a generic plan the type of implementation doesn’t matter that much, and the details within the plan can be scaled as required to a larger or smaller project. Where a test manager is responsible for more than one test phase or for multiple rollouts then this plan can be used as an initial template and scaled where required to each phase/rollout.

The PMI PMBOK tells us that our project is broken down into phases, and from there to deliverables (or functional or partial objectives, or intermediate results). Although a deliverable is something that is intended to be delivered to a customer, and therefore our major deliverable in this case is the successful completion of test execution for the phase, we can redefine our WBS so that the deliverables make more sense and relate to the outputs from each activity. The following graphic illustrates the decomposition from Project (for example, our UAT project) into Phases (for example, Planning, Preparation, and Execution) into Deliverables (for example, the Test Strategy, the Scope, the Test Schedule, etc). From there, we can further decompose into work packages and activities:

WBS diagram

 

Our initial list of deliverables (and the reasons why we are including them) are:

.
  • Preparation Plan

Having a detailed plan is vital to ensure that all interested parties have confidence that the planning is structured and detailed enough so that vital tasks are not missed, that the effort fits within the timeframe available (and that where there are discrepancies there is an opportunity to discover them and raise risks/issues), that dependencies with other teams dovetail together with their plans, and that people with allocated tasks are aware that they are required to do something and have a milestone date to complete their activities.

  • Test Strategy

The Test Strategy details how we will be executing this phase of testing – where our testers will be sourced from, where they will be located during test execution, who will be supporting them and how, what training they require and how they will be receiving it, what authorisation strategy they will be using, the defect management process, change request process, entry and exit criteria, etc. This will be a living document, changing and updating as our team goes through the various activities in the detailed plan. The key audience is our leadership team (both project and business) so that we gain support and agreement for the way that we will be conducting our test phase and the test activities we will be completing.

  • Scenarios, Checklists, and Charters

In our medium-to-large implementation we will be running end to end business scenarios complemented by workstream-specific checklists and exploratory testing, so we need to add in a deliverable of the test scripts, checklists, and charters that we will be using in our test execution.

  • Data

Together with the test scenarios we will need confirmation of the test data required. For testing, this lets us know the number of iterations of a scenario we may need to run (for example, we may have a standard manufacturing scenario that we want to run for multiple materials or across multiple factories). For the configuration team this helps to confirm the design – customers, vendors, and materials selected by the business to include in testing tend to be the ones most critical to them. For the data team this lets them know the priority to focus on for cleansing and loading into the test system. Together with the scenarios, checklists, and charters, this forms our scope for testing.

  • Execution Schedule

The schedule for testing encompasses the scenario scope, testers, location, timeframe, and test sequence. Delivering the test schedule early in the process enables the testers and support teams to review it in depth to confirm that they accept and have familiarised themselves with those details, to reduce any surprises during test execution.

  • Human Resources

We can’t run any testing without identifying and onboarding our testers, 3rd parties, and support. They also may require training on our SAP and test management systems. Any system knowledge transfer or training will usually be delivered by the process experts and/or training team, and in our plan we’ll keep an inbound dependency to track that this is in progress and complete. We will be responsible for any training of test management systems and onboarding the testers to ensure they are aware of what is coming and how we will be managing the test phase.

  • Communication

Our communication strategy is multi-pronged – from shared network drives for “pull” communication, to delivering the detailed execution plan, to preparation status reporting, to test execution progress reporting, there are multiple communication channels and methods of delivery.

  • Procurement

In order to successfully prepare for test execution we should be aware of what we need to procure or set up. Test lab booking, hardware, travel and accommodation for testers all need to be planned and actioned.

  • Readiness

At either end of the Preparation we start with the Preparation Plan, and we end with the Readiness checklist. With so many disparate parts needing to come together, we will have a simple checklist to keep track of our current status and the critical path to our entry criteria. Although we own the checklist, the updates to it are gathered from the various responsible teams.

  • Test Execution

This is what we’re here for, after all – the successful delivery of the test execution phase. We’re including a Dry Run as well – at it’s simplest we will have a handful of key process representatives walk through the test execution schedule, with the intention of confirming that all required data and development/configuration is available. A full dry run could include testers travelling to the test location for a hands-on system and process walkthrough, running mock scenarios and testing the support, defect, and change processes, system access, and local printer/scanner setups.

  • Close Project or Phase

Once everything is wrapped up we can close out our test phase, handing over to either the following test phase or to the Deployment and Cutover team. There are several activities that we need to complete here, including closing our procurements and formally closing the test phase.

 

Our initial WBS levels with these headline deliverables looks something like this:

Initial WBS
 
 

Previous Page - Detailed Test PlanningNext Page - Define Activities - Preparation Plan