CA305

Project & Process Management

Sample Contents: "SW Development Plan" template

1. Introduction
2. Project organisation
3. Managerial process
4. Software engineering process
5. Work packages (WPs), schedule and budget
Appendix A: Work package [and main activity] descriptions

0. Template-specific conventions & notes REMOVE for

actual projects
1. Angle brackets < > contain material that must be replaced by project-specific
data. For emphasis, this material is sometimes in bold italics.
2. Bolded square brackets [ ] delimit text that may or may not be applicable,
depending on project. A pair of separators || is used to identify alternative wordings,
depending on project needs.
3. Guidelines are italicised and, in part, may be paraphrased for specific projects.
4. Title page (and headers & footers) must be replaced by the appropriate project
specifics.

319288337.doc

Page 1 of 9

CA305

Project & Process Management

1. Introduction
1.1 Project overview
Self explanatory; keep fairly brief.
1.2 Project deliverables and milestones
List the deliverables in a table ordered by work package, each deliverable being
associated with a work package.
List the major project milestones each milestone should usually coincide with
starting or ending a work package.
1.3 Evolution of SDP
State at which points it is planned to issue the SDP during the course of the project
and outline what will be new to each issue. For example, for a standard waterfall
sequence, one could have
Issu
e
1

When issued

Outline

Pre SR phase

Outline plan for whole project identified tasks are probably

based mainly on requirements at this stage.
Provide (at least rough) estimates of cost and schedule.
Specify in detail the SR phase activities.
2
In SR phase
Refine plan for whole project - tasks may be based on SW
components (e.g. classes) at this stage.
Provide more precise estimates of cost and schedule.
Specify in detail the DD phase activities.
3
In AD phase
Should include a work breakdown structure (WBS) directly
related to SW components.
Estimate cost and schedule accurately.
Include a planning network showing interrelationships between
coding, testing and integration.
4
In DD phase
Refine & update the WBS as work progresses.
Detail project activities until final acceptance.
Refine the job schedule.
where SR = SW requirements, AD = Architectural or high level design, and DD =
detailed design and production.
1.4 Reference materials
<Specify any applicable and reference documents>
1.5 Definitions & acronyms
Self-explanatory.

319288337.doc

Page 2 of 9

CA305
Project & Process Management
2. Project organisation
2.1 Process model
The organisations Quality Management System (QMS) provides overview and
detailed guidelines of the processes involved in any software project, and should be
consulted in defining the process model of the current project.
In addition, the high-level, general process model presented in Figure 2.1-1 (from
Project management for information systems, Yeates & Cadle, 1996), although
containing much more than software development, may be useful as a further
guideline, especially as a check that no essential activity has been overlooked.
Specifically, this section should
Identify the SW processes to be used in the project
Define the SW life-cycle model
Define transition criteria between SW development processes
Identify planned builds
State objective of each build
State activities for each build
where, typically, transition criteria between SW development processes could be
The SW verification process reviews have been performed
The input is an identified configuration item
A traceability analysis has been completed for the input
Note: Ensure all contractual clauses relating to planning are addressed adequately.
2.2 Organisational structure
Specify, preferably with a diagram, the organisational structure of the project. For
example,
- Is there a key responsible with sufficient resources and authority?
- Any elements independent of project management, particularly quality assurance?
2.3 Organisational boundaries & Interfaces
Specify how the project fits into the overall company structure.
State how project interfaces with customer (acquirer) and any other external agency.
2.4 Project responsibilities
Present (diagram?) all key team members.
What are lines of communication between members?
Which work packages/ tasks is each team member responsible for?

319288337.doc

Page 3 of 9

CA305

Project & Process Management

Project plan (SDP)

Quality plan (SQAP)
Project organisation
Project administration

Site surveys and

preparation
Staff training/
familiarisation
Warranty
support and
maintenance

Data acquisition
and take-on
Finalise any
subcontracts
Initial
client
contact

Receipt
of ITT
& bid
process

Documentation
production

Contract
negotiation

Project
start-up

Monitor bid
process

Bid debrief
and review

Development

Delivery
to site

Site
installation

Requirements specification
Technical specification
Detailed & module design
Prototyping

Site
accept
-ance

(Sub)
system
commission

Integration with other systems

Actual data and operation
Controlled conditions

H/W & S/W modules

Module/system integration
System testing
Factory acceptance

Figure 2.1-1: A general process model (major deliverables/results shown in call-outs)

319288337.doc

Page 4 of 9

Customer takeover

In-service
live running

Enhancement and
future
development

CA305

Project & Process Management

3. Managerial process
3.1 Management objectives & priorities - self explanatory
3.2 Assumptions, dependencies & constraints - self explanatory
3.3 Risk management
To help identify risks, use following (not necessarily complete) checklist:
No.
Potential area of risk
1
Proven business case? Funding approved? Right type of contract
2
Areas of contract ill-defined or not agreed?
3
Customer: sufficient access? effective decision making procedures?
4
User committed? Quality & stability of user requirements
5
Acceptance criteria specified in contract?
6
Level of definition & stability of external interfaces
7
Adequacy & availability of resources including team members.
8
Availability & quality of tools.
9
Team member training & experience //// Definition of responsibilities
10
Short time scales. Rapid build-up of staff required. Over-optimistic planning.
11
Technical novelty of the project. Technical complexity of the system.
12
Demanding performance, reliability, availability, maintainability requirements
13
New development environment. Mis-match between development and target
14
Bought-in items
Table 3.3-1: Checklist for potential risk identification
Provide an assessment of risk for example, use as a basis for comparison, a risk map
such as Figure 3.3-1. Each identified risk is assigned to a cell of the map:
High
Medium
Low
Likelihood of occurrence->
Large
Potential
Moderate
scale of
Small
impact
Figure 3.3-1: Risk map template
Provide a plan for reducing any identified risks.
3.4 Monitoring and controlling mechanisms
State how progress towards reaching project objectives will be measured ...
State how difference, for both resource and schedule, between planned and actual
"expenditure" will be analysed (for example by earned value analysis).
State frequency & content of project status reports (to give visibility on progress).
State how project reviews will be prepared for and organised...
3.5 Staffing plan - more detail than section 2.4

319288337.doc

Page 5 of 9

CA305
Project & Process Management
4. Software engineering process
4.1 Standards, methods, tools and techniques
As relevant to specific project needs:

Identify standards, including

SW requirement standards
SW design standards (e.g. UML as tailored to company's needs)
SW code standards
Standards for test cases, procedures and results (probably in Software
Verification & Test Plan (SVTP))
Define the selected methods and tools
SW requirements methods & tools (e.g. tool for UML)
SW design methods & tools (e.g. tool for UML)
Programming language(s), coding tools, compilers, linkers, loaders ...
HW platforms for tools
Summarise how use of project standards, methods and tools will be monitored and
enforced (maybe refer to SVTP, for example, for planned reviews and inspections).
4.2 Project support functions
Refer to separate Software Configuration Management Plan (SCMP) for software
configuration management.
Refer to separate Software Verification & Test Plan (SVTP) for organisation and
planning of software verification, including but not limited to testing.
Refer to separate Software Quality Assurance Plan (SQAP) for software quality
assurance activities.
[4.3 Management of reusable software products]
Two aspects are distinguishable.
Incorporate reusable SW products
Identify (Scope of search? List already known?)
Evaluate (Criteria?)
Incorporate (How?)
Develop reusable SW products (cf Components in earlier lectures)
Identify opportunities
Evaluate opportunities
Report opportunities
[4.4 Handling of critical requirements]
If relevant, state any special measures for requirements designated as critical, such as
requirements for assurance of safety, security or privacy.

319288337.doc

Page 6 of 9

CA305
Project & Process Management
5. Work packages (WPs), schedule and budget
5.1 Work breakdown structure (WBS), work packages and tasks
5.1.0 Work breakdown structure (WBS)
The level of detail should be commensurate with the project size.
The following work breakdown structure (Figure 5.1.0-1) has been established for the
<Supply Name> PROJECT.
WPs

Main Activities

Tasks

1. <Name>
1.1 <Name>
etc

1.1.1 <Name>
etc

2. <Name>
2.1 <Name>
etc

2.1.1 <Name>
etc

n. <Name>
n.1 <Name>
etc

n.1.1 <Name>
etc

Figure 5.1.0-1: Project Work Breakdown Structure

The following sections provide overviews of each work package. Detailed work
package [and main activity] descriptions are provided in Appendix A.
5.1.1 WP1 <Supply WP NAME> overview (self explanatory)
5.1.2 WP2 <Supply WP NAME> overview (self explanatory)

5.1.n WPn <Supply WP NAME> overview (self explanatory)

5.2 WP and task interdependencies
Each work package description (WPD) or task work sheet (TWS) identifies the
activitys inputs and outputs, and any constraints on its execution.
Show how work elements are interrelated (preferably in diagram(s) e.g. PERT/CPM).
5.3 Estimated resource requirements
Include a table (similar to Table 5.3-1) which identifies the estimated labour effort,
and estimated cost of any other resources, needed to perform tasks to the level

319288337.doc

Page 7 of 9

CA305

Project & Process Management

identified in the WBS of section 5.1.0. The estimates should be accumulated for each
main activity, work package and the overall project.
WPs

Main Activities

Tasks

Labour
(person days)

Other costs
(monetary)

1. <Name>
1.1 <Name>
etc

1.1.1 <Name>
etc

2. <Name>
2.1 <Name>
etc

2.1.1 <Name>
etc

n. <Name>
n.1 <Name>
etc

n.1.1 <Name>
etc

ESTIMATED PROJECT TOTALS

Table 5.3-1: Summary of required resources
Note on estimation:
Basic approach:
Break work into small tasks, then estimate time and cost for each task. Finally
estimate whole project by accumulating or synthesing the individual task estimates.
It is wise to base estimates on valid past experience.
In addition, other approaches may be sometimes useful such as
- prototyping
- cost models (e.g. COCOMO, function points).
As indicated in section 1.3 of this template, refined estimates can be documented in
later versions of the SDP corresponding to more detailed versions of the WBS.
5.4 Budget and resource allocation
Show how resources are allocated over the project lifetime, broken down as necessary
into work packages or lower level activities. Can be presented in tabular form and/or
using one or more figures (such as histograms).
5.5 Schedule
Define the project schedule (preferably using a bar-chart or Gantt chart), identifying
the dates of the major milestones, deliverables, external inputs to the project (and any
other external dependencies), the duration of each workpackage broken down, to
sufficient resolution, to activities and tasks.

319288337.doc

Page 8 of 9

CA305

Project & Process Management

Appendix A: Work package [and main activity] descriptions

Complete, as necessary, work package descriptions (WPDs) (or similar) for work
packages and major activities. As a minimum include a WPD for each work package.
A sample blank WPD form is as follows:

WORK PACKAGE DESCRIPTION (WPD) FORM

PROJECT:
WORK PACKAGE
Title:
Manager:
Planned Start date:
INPUTS:

Reference:
Version & date:
End date:
Effort:

CONSTITUENT TASKS:

CONSTRAINTS (e.g. task sequencing, environment, etc):

OUTPUTS:

319288337.doc

Page 9 of 9