Over the next few pages we’ll break down each of our deliverables into smaller sub-deliverables and define the tasks and activities that are required to complete them. Not all tasks and activities will be relevant for all projects (different projects may have additional tasks required, or may need to duplicate tasks for multiple rollouts, or may simplify the activities).
The first step is to confirm our Plan for a Plan and create our Preparation Plan:
- Preparation Plan
- Test Strategy
- Scenarios, Checklists, and Charters
- Execution Schedule
- Human Resources
- Test Execution
- Close Project or Phase
Planning and Preparation Plan
Our first deliverable is this plan itself. Our Project Manager wants to be reassured that we’re on top of things and wants to know who will be creating the plan and by when, so our first task is to outline what tasks are required to complete our detailed Planning and Preparation Plan, to allocate tasks and activities, and to set durations, so that we can start with the plan review process.
It is a bit Inception-like that we are adding in tasks to this plan to show our deliverable of this plan, but it means that we can immediately turn our minds to the first four questions we need to resolve – who is putting the plan together, how long have they got to do it, what form will it take, and what will the review process be. This plan is a deliverable, after all, so the activities, resources, and durations to create it need to be established.
The deliverable from this activity is the Preparation Plan, the list of deliverables, milestones, and activities that need to happen to make our test project a success. It’s important to have a detailed plan for several reasons:
- We use the initial project milestones to work backwards with activities to estimate durations. If there are risks or issues in being able to start or complete an activity on time then we can immediately highlight this to the project manager so that we can work on mitigation.
- Our plan includes dependencies and activities that come from other project teams (Data, Basis, Dev, etc). In reviews of our plan our assumptions on timelines and drop dates can be confirmed or challenged by those teams, leading to a tighter overall combined project plan.
- Activities need to be completed by someone, and not necessarily someone in the test team. For example, we will need assistance from business representatives to identify test scenarios. If we do not identify the activity and the resource requirement early enough the people that we need may be reallocated to other activities, putting our timelines at risk. The plan helps to identify and communicate that requirement.
- It’s very easy to forget to complete an activity or a deliverable if you don’t have a solid plan, leading to delays and further risks and issues.
The plan itself should be reviewed by all relevant stakeholders to ensure that milestones are achievable. If necessary, different views of the plan can be created or even transposed onto another format (for example, an Excel or Powerpoint document with only the headline activities and durations) for different stakeholders and reports.
Once our plan has been prepared, reviewed, and signed off, the work doesn’t stop there, monitoring and controlling the plan throughout the test phase to track the current status and to tweak the activities to add or remove them as the project progresses.
|Previous Page - Create Initial WBS||Next Page - Define Activities - Test Strategy|