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 client’s 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 customer’s environment unknown (e.g. language)
  • What risk is involved in the deadlines and quality of deliveries from the client, subcontractors, suppliers, etc.
  • Etc.

Siemens AG Österreich, Program and Systems Engineering PSE
Contact: stdSEM Webmaster
Last modified: 08/27/98 15:41
Copyright © Siemens AG Österreich 1997. All rights reserved.