 |
|
Checklist for Preliminary
Project Plan (pE1)
|

 |
 |
1 Introduction 1.1 Purpose of the document
The purpose of this project plan is to convey a
general overview of the course of the planned project
<xyz>.
1.2 Validity of the document
This section must specify the solution and solution path
(as reference only!) which the preliminary project
planning relates to.
Predetermined internal and external constraints (in
addition to the clients requirements) for the
planning (both technical and organizational) can also be
stated in this section. Does this planning only apply for
a project start within a specific period of time (e.g.
availability of personnel, HW, prices of procured goods,
etc.)?
1.3 Definitions of terms and
abbreviations
This section is used to define the terms used in the
document (e.g. important abbreviations and organizational
terms used by the client).
Alphabetical order is recommended for listing the terms
and abbreviations.
1.4 Relationship with other
documents
How is this document related to other documents both
within and outside the project (documents from earlier
projects, other requirements documents, planning
documents, feasibility studies, etc.)?
To which proposed solution (document) does the
preliminary project plan relate? Do any minor deviations
exist to the solution path which this describes?
|
 |
 |
2 Project goal This
section must state what the project is to generate by way
of a result or what is to be delivered by way of the
project result (short profile of the product). For
details, reference should be made to the specification of
the proposed solution and to the solution it describes.
|
|
 |
3 Project
organization 3.1
Client
This section must specify the envisaged client (possibly
also contact persons).
3.2 Project manager
This section must name the designated project manager
(with overall responsibility).
3.3 QA manager
This section must name the person who has assumed
responsibility for quality assurance in the project
(during the Initiation phase).
3.4 Project organization
This section must describe how, in principle, the project
is to be organized. It is particularly important,
especially with complex forms of cooperation (e.g.
business associates, departments, external firms, etc.,
involved in the project), that the project organization
and, consequently, the associated responsibilities are
defined as early and unambiguously as possible.
|
 |
 |
4 Framework
for effort This section must specify the
approximate effort for the solution envisaged in the
specification for the proposed solution. The total effort
must be sufficiently detailed with reference to the
proposed solution.
|
 |
 |
5 Personnel
requirements framework 5.1 Qualification
This section must specify the
qualifications which the personnel must have (e.g. in the
form of a knowledge matrix).
5.2 Histogram of manpower
This section must describe how the manpower
is to be distributed over the entire project.
|
 |
 |
6 Framework
for deadlines 6.1
Start of project
This section must state when the project
could start.
6.2 Duration of project
This section must state the expected
duration of the project.
6.3 Completion / delivery dates
This section must specify the completion
and delivery dates which are possible from the
perspective of the initial preliminary analysis.
|
 |
 |
7 Constraints
7.1 Project type
This section must specify the project type
based on PROCON (development project, maintenance
project, consultancy project, etc.).
7.2 Processing
This section must specify how the project
is to be processed and in accordance with which
agreements:
- On the basis of effort or fixed price
- Continuous project execution or on the basis of
hours "on demand" at fixed hourly rates
- Is a phased development process desired?
- Will the project be conducted with business
associates?
- Will PSE International be involved?
|
 |
 |
8 Risks
All risks which are already known must be specified in
this section. This section must state the problematical
requirements (see listing below) which give rise to these
risks.
The risks will essentially be internal, though
external risks must also be taken into account.
It is also necessary to state the effects which these
risks can have on the course of the project, how likely
they are to occur and what measures can be taken to limit
their occurrence.
8.1 Technical risks
- Can the task be resolved through a technical
solution (e.g. can performance values be
satisfied)?
- Have the interfaces been adequately defined?
- Do the necessary development environments (HW and
SW) already exist?
- Etc.
8.2 Quality risks
- Have the acceptance criteria been adequately
defined?
- Can the product be adequately tested? Are there
any technical, organizational or deadline risks
involved in conducting the test?
- Can the required norms, standards, etc. be
complied with?
- Etc.
8.3 Project execution risks
- Are sufficient numbers of personnel available at
the correct time?
- Is there sufficient experience (technical,
organizational or domain-related) to execute this
project within the agreed framework?
- Are coordination problems to be expected (e.g.
when carrying out development work at several
sites, with subcontractors, etc.)?
- Etc.
8.4 External risks
- Currency fluctuations, customs duties, taxes
- Market situation (competition) difficult to
appraise
- Aspects of the customers environment
unknown (e.g. language)
- What risk is involved in the deadlines and
quality of deliveries from the client,
subcontractors, suppliers, etc.
- Etc.
|