<company>
Project Plan
<version>
<project>
Distribution list:
Name (alphab.) Department Location
<name> <department> <location>
<name> <department> <location>
Copyright © <company> <year> / For internal use onlyAuthor: / Inspector:
Dept.:
Name:
Tel.: / department
name
tel.no.> / Signature: / Dept.:
Name:
Tel.: / department
name
tel.no.> / Signature:
File: / X:\SEM\Entwicklung\Source\easysem_e.in.Arbeit\winword\projplne.doc / Status: / doc status
Date: / date / File: / Project file
File directory / Sect. <nn.nn
<directory>
Project Plan project
version Document Management
Document Management
History of changes
Version / Status / Date / Person resp. / Reason for ChangePersons authorized to make changes
<name> <department> <location>
<name> <department> <location>
Document was created using the following tools:
WINWORD 97
<Graphics tool>
Contents
1 Introduction
1.1 Purpose of the document
1.2 Validity of the document
1.3 Definitions of terms and abbreviations
1.4 Relationship with other documents
2 Key data of the project
2.1 Designations
2.2 Brief description
2.3 Project type, development method, life cycle approach
3 Project organization (persons responsible and contact persons)
3.1 Persons responsible in the project
3.2 Other persons responsible and contact persons
4 Component planning
4.1 Deliverables (product)
4.2 Additional components (not included in the scope of delivery)
5 Project volume
5.1 Activities
5.2 Effort
5.3 Charge rates and costs
6 Course of the project
6.1 Sequence of tasks
6.2 Personnel deployment
6.3 Deadlines/milestones
7 Risk management
8 Project monitoring and control
8.1 Project monitoring points
8.2 Reporting
8.3 Control measures
Page 2 / 1
Project Plan project
version Project monitoring and control
1 Introduction
1.1 Purpose of the document
The project plan is used to define the future course of the project on the basis of the preliminary project plan, software requirements specification, quality assurance plan and, where appropriate, a feasibility study. During the course of the project, this plan will normally need to be revised several times, since it will be used for project control purposes:
· The first version is used to define the course of the project.
· Revised versions indicate the current, actual status of the project at a given time and the planned course of the project.
· The last version at the end of the project shows the actual course of the project and, through a comparison with the previous plans, the planning quality.
It is advisable to use a tool to draw up the project plan or parts of this plan.
Proposal for possible formulation for this section:
The purpose of this project plan is to plan and document the structure and course of <release abc> of project <xyz>: Project organization, components and associated activities, efforts, costs and deadlines. Furthermore, this section is also used to describe the project control procedure and risk management.
1.2 Validity of the document
This section must specify the areas to which the project plan applies:
· Does the project plan apply to the entire project or only part of the project?
· Does the project plan also apply to subcontractors?
· Does the project plan apply to all project phases or only to specific phases? What degree of detail is involved?
The plan for components, project volume and task sequence (sections 4 to 6) will generally be revised frequently during the course of the project. Consequently, this section must also provide information on updating of the document (when is the project plan to be revised?).
1.3 Definitions of terms and abbreviations
If an appropriate glossary already exists for the entire project, a reference must be made to this. Otherwise, the terms and abbreviations used in this document must be explained. By way of example, two terms which are frequently misunderstood:
Product:
The result of a project delivered to the client (= sum of all deliverables, see section 4). Components which are not delivered are not considered part of the product.
Project:
Process for creating a product. More precisely: A single enterprise which is geared to a specific result (product goal) for which an execution plan exists and for which a defined time period and defined amount of resources have been planned.
1.4 Relationship with other documents
The project plan is related to very many project documents, since it describes the entire course of the project. The first version is based on the preliminary project plan and numerous other documents, some of which are still in the process of being completed: Software requirements specification, feasibility study(-ies), QA plan, CM plan, etc.
Revised plans are based on the previously valid project plan and on project documents which have been created or revised since. The reason for the revision (e.g. changes to software requirements specification) should be stated.
When the project is terminated, the contents of these plans are incorporated into the final report and project experience report.
2 Key data of the project
This section summarizes all key characteristics of the project which will be subject to little variation.
2.1 Designations
This section will be used to list the various project designations: Project title, project name, order number(s), short designation, etc.
2.2 Brief description
Brief description of the goal and content of the project (a few lines to quickly orient readers who are not closely involved with the project).
2.3 Project type, development method, life cycle approach
· Project type (e.g. new development, further development, porting, maintenance, etc.)
· Which development method?
· Which life cycle approach?
3 Project organization (persons responsible and contact persons)
This section defines the areas of responsibility in the project so as to ensure that all areas are covered, but without any overlapping of responsibilities. Responsibility - in contrast to execution - involves caring for and tending to the execution (in small projects, the person responsible will often also handle the execution). If necessary, areas of responsibility can also be defined outside the project, e.g. at the client’s or in the line hierarchy.
3.1 Persons responsible in the project
A project based on stdSEM must have at least two project managers (persons responsible for the project), since project management and product development on the one hand must not coincide with QA management on the other.
The areas of responsibility must be allocated to a person (not to an organizational unit!). In these areas of responsibility, specific responsibilities must be discernible (subdivision).
Possible areas of responsibility include:
· Project management
· Project assistance
· QA management
· Product development
· Technical support
· Configuration management
· Reuse (and reusability)
· Staff training planning
The specific areas of responsibility must be defined on a project-specific basis. The number of persons involved in the project must not be used as a basis. One and the same person can (with the above exception) handle several areas of responsibility.
These umbrella concepts must be subdivided in detail and a person and possibly a substitute must be nominated, e.g. in the following form:
Responsibility / Detailed Responsibilities / Name / Organizational Unit / TelephoneOrganizational project manager / Project planning (creation of project plan and project control), recruiting of personnel, ordering of HW and SW, monthly reports, contact persons for clients,
etc. / Mr. <abc> / xxx / -----
QA manager / QA plan
Quality reports
etc. / Ms. <cde> / xyy / -----
...
3.2 Other persons responsible and contact persons
This section must list the in-house responsibilities outside the project:
Responsible business unit, responsible business administrators, responsible QM, consultants and other specialists; decision-making bodies (CCB), etc.
This section must also specify persons responsible and contact persons outside the company (e.g. project and product managers at the client’s, technical contact persons, persons responsible for change requests and error reports, persons responsible for acceptance, etc.).
Sections 4 to 6 which follow must set out the entire course of the project. Individual sections can also consist of subplans or the results of a project planning tool (e.g. components, activities, efforts, resources and deadlines as the outcome of a project plan with MS project). It is important to use a suitable degree of detail in order to manage and control the project. It is also important to ensure that changes can be integrated easily into the project plan (e.g. changes to effort, deadlines etc.).
These sections are generally the ones most affected by project control interventions, since it is frequently necessary to alter the plans (see section 8). In the event of such interventions, it is therefore important that the content remains consistent:
Section “Deliverables” (4.1), then “Additional components” (4.2) and finally “Activities” (5.1) are dependent on each other in this sequence and should therefore also be worked through in this sequence. The (sub-)sections which follow contain so many cross-references that they form a type of network.
From section “Activities” (5.1) onwards, a project planning tool should be used wherever possible. Most of these tools require that the activities be listed first.
4 Component planning
Components include everything which needs to be created or must be already present during the project. The components are categorized according to two criteria (at the time the project plan is drawn up, components should be regarded as logical units, not physical ones):
· Firstly, the deliverables which come together to form the product.
· Then the other components which are required to create the deliverables: These are components which must be available or must be created, but which are not delivered.
This sequence is important, since the deliverables (together with the selected development method) determine the additional components. The sum of all components provides the basis for determining the activities (work packages). These can then give rise to efforts and costs. The complete listing of the components also provides the usual basis for determining the configuration items in the Configuration Management.
4.1 Deliverables (product)
This section contains all the product components, i.e. the parts which, according to the software requirements specification, are delivered to the client. The deliverables derive from the existing requirements (see software requirements specification).
Examples of possible deliverables include:
· Executable software
· User documentation
· Installation instructions
· Make files
· Training documents
· Design documents
· Program sources
· Test reports
The additional components set out below (e.g. elements which are procured and used, but not supplied) are dependent on the deliverables. Deliverables which are forgotten from this section result in additional components being forgotten and, as a consequence, in activities being omitted - all with serious consequences.
The components are usually shown in the form of a tree structure.
4.2 Additional components (not included in the scope of delivery)
This section contains all additional components, i.e. parts which are not supplied to the client, but which must be available or must be created during the course of the project. The deliverables set out in section 4.1 serve as input for defining the additional components. Section 5.1 uses the sum of all components to derive all the activities.
Typical entries in this section include:
· All documents required for this project by the development method
· Tools
· Monthly reports
· Utilities which are self-created
· Test data
· Simulators provided by the client
· etc.
All required resources, in particular HW and SW, count as additional components (since they too do not lead to required activities!).
The components are usually shown in the form of a tree structure.
5 Project volume
This section must set out the project volume, i.e. the activities and the effort and costs resulting from these. The activities are determined from the components set out in sections 4.1 and 4.2. They are to be defined in such a way that they form clearly-arranged units. The activities are then assigned efforts and these efforts are assigned costs. This section can also form an automatically generated part of a project plan (e.g. MS-Project).
5.1 Activities
Most activities can be derived from the components. There are two major types of activity. Production, changes, matching on the one hand, and procurement, outsourcing, using, deployment on the other. The greater the extent to which the activities can be derived 1:1 from the components, the clearer and easier to understand will be the plan. There are, however, a number of activities which cannot be derived directly from the components, e.g. “Operate CM system”. Activities of this kind can either be “opened” to related activities (e.g. during encoding, integration, etc.) or can be shown separately.
The degree of detail for the activities must be selected so that the related effort can be determined with ease and to ensure that a planned/actual comparison is also possible for project control. If the two are not possible simultaneously, a grouping together into superordinate terms can prove useful.
The type and quality of the structuring (breakdown) of the various activities determines the reliability of the planning process and the effectiveness of the project control process. The complete structuring of each project up to and including definition of all necessary activities (work packages) is therefore essential for expedient project planning and control. This structuring is also known as the project structure or work breakdown structure.
5.2 Effort
This section must set out the estimated, measured or calculated effort (the effort is not a sum of money but rather a quantity schedule!). In addition to the effort itself, the method used to determine the effort must also be specified in order to demonstrate how the effort was determined in the first place. Experience has shown that it is difficult to estimate effort. Both algorithmic (function point) and non-algorithmic estimation methods (bottom-up, percentage method, expert surveys, analogy estimation) can be used for estimating effort. What is important, however, is that all effort be recorded in detail, e.g. effort for personnel deployment, outlay for operating resources and for other requirements (e.g. training, travel, materials, outsourced goods, etc.).
Common types of effort in SW projects include:
· Personnel effort (e.g. personnel hours, possibly subdivided into internal and external personnel, subcontractors, etc.)
· Operating resource outlay (e.g. computing time, units, SW required, maintenance contracts, etc.)