| Related: |  |
 |
|
OBJECTIVES |
Create the detailed plans for the project that define the activities, resources, budget, schedule and systems engineering processes to be used for the project. |
|---|---|
|
Description |
Project Planning is an effort that occurs at the beginning of a project to identify the tasks, resources, schedule and risks of the project. The result of this planning is the Project Management Plan (PMP) which identifies the detailed work plans for all tasks. It identifies key events and the technical and program milestones, and establishes a schedule for the project. For projects with systems engineering, a Systems Engineering Management Plan will also be a key output, either as a section of the PMP, or if the project’s complexity warrants, a stand-alone document. Based on project complexity, additional [e.g., Configuration Management, Risk Management and Procurement] plans may be needed. |
|
Context |
|
|
INPUT Sources of Information |
· Goals and Objectives · Project Charter · Programming outputs for project |
|
PROCESS Key Activities |
· Define project objectives, tasks, resources, schedule, and risks · Define needed systems engineering processes · Prepare project management plan · Prepare supporting management plans |
|
OUTPUT Step Results |
· Project Management Plan · Systems Engineering Management Plan · Additional Management Plans |
Project planning is one of the five process groups of the Project Management cross-cutting activity (3.4.1). This is the initial step in the project development process, occurring prior to the commencement of development activities. In order to achieve the benefits of the use of systems engineering, the tasks, processes, resources, and schedule of the project need to be defined and documented in a project management plan (PMP). The scope of this step is highly dependent on the complexity of the project and on the processes that have been developed by the agencies involved.
The identification of risks and the definition of a plan to manage those risks is one of the key outputs of the project planning process step. While risks largely fall into three general categories, technical, cost, and schedule, each project has a unique set of risks that must be identified and a management approach determined. For further discussion of risk see the cross-cutting topic Risk Management (section 3.4.4)
Define project objectives, tasks, resources, schedule, and risks
The first task in planning the project is to identify and define all of the work efforts [tasks] which are needed to accomplish the project’s goals. These tasks include all the technical work, but may also include project management itself and other administrative tasks. A clear definition of the project objectives is also a key part of the planning effort.
The resources needed for each task must also be identified. In addition, the staffing responsibilities should be defined, often through an Organization chart, in order to identify clear paths of both responsibility and communications. Other resources, such as a testing laboratory, may not be needed immediately. However, the need for them should be identified as soon as possible.
An understanding of the project’s tasks, plus the resources and budget needed for each task, are combined into a project schedule. This schedule is generally constrained by external requirements, such as, a need for the system to be operational by a certain date or a dependence on the installation of another interfacing system. Key in developing the project schedule is to identify the dependencies among tasks. The most common dependency is that the completion of one task is required before the start of a subsequent task.
Another key output of this activity is identification of the risks that are anticipated for the project. Each project will have unique technical, schedule, and budgetary risks that should be identified and a plan for managing the risks should be developed. See the Risk Management cross-cutting topic (Section 3.4.4) for a further discussion of risk identification and risk management.
Define needed systems engineering processes
The project and engineering management will identify the systems engineering processes and resources necessary to support each identified technical task. If significant portions of the systems engineering tasks are contracted to commercial firms, those firms may have to be involved in detailing these processes.
Prepare project management plan
The various parts of the project plan need to be gathered together into a written Project Management Plan. The degree to which the Project Management Plan needs to be documented will vary by project size and complexity.
Prepare supporting management plans
The other plan that needs to be developed is the Systems Engineering Management Plan, which describes the systems engineering processes that will be a part of the project. The scope of this is highly dependent on the complexity of the project and on the processes that have been developed by the agencies involved. For many projects the SEMP information will be incorporated into the PMP, but for more complex projects the SEMP may be a standalone document.
If necessary, additional separate supporting plans are developed to supplement the PMP, such as a software development plan, risk management plan, configuration management plan and other technical plans.
The degree to which various management plans are documented is the prime variable in this process step. They must be documented enough so that the responsible staff knows what to do [the larger the staff, the more important this is]. For small and low risk projects, a 5-10 page document [the Project Management Plan] is all that may be needed to contain all the necessary project planning information. Existing organizational procedures should be referenced in the plan. Depending on the nature of the project, the systems engineering processes needed should be described as part of the PMP. If the project includes custom software development, a more complete SEMP, possibly even a stand-alone document, is probably necessary. In addition, the system’s owner must have available a Configuration Management [CM] Plan designed for software products. The system’s owner must ensure the organization’s standard CM Plan is sufficient. If it isn’t, tailor it to the project or have one prepared.
As a minimum, a PMP should consider tasks, resources, schedule, systems engineering processes and identification and management of risks. For projects with higher complexity or risk a larger, more complete PMP will be needed.
The definition of systems engineering process for the project is definitely not one-size fits all. Since systems engineering is intended to address the technical challenges in building a system, it must be tailored to the technical challenges of the specific system.
The biggest variable affecting the scale of the systems engineering analysis is the need to develop custom software applications. If custom software development is needed, requirements definition and design become much more complex and a separate SEMP is usually the best approach.
Projects that only involve the purchase and installation of hardware or hardware with embedded software applications do not require the same depth of requirements analysis and design. Of course, these projects may require serious trade studies on such issues as product selection, site selection, or communications alternatives. The definition of the systems engineering effort (in the SEMP) for such projects may be quite short and can be combined into the PMP for efficiency.
Another factor is the degree to which the system owner is comfortable with the technologies involved. If the system owner is unsure or there is a perceived risk, then added attention to the preparation of a SEMP is advised.
The final factor is the degree to which the System Engineer and Development Teams have their own well-developed processes, such as requirements management, configuration management, or software development.
Where the agency does not have any of these processes in place, it is recommended that they identify and select experienced development firms with established processes. In such cases, the SEMP should reference these processes [tailored appropriately] and only deal in detail with the unique processes needed for the project.
Of all the processes described in this Document, project planning is the one which is most likely to be defined and controlled by established agency procedures. Almost all agencies have internal rules, regulations, and guidelines for project management activities. Furthermore, in the area of procurement, project management intersects with contract law, making it subject to legal requirements. It is the task of project management to be aware of, use, and be compliant with this guidance.
With regards to the systems engineering aspects of the planning, the FHWA Regulation does not specifically mention Systems Engineering Plan development practices to be followed.
The IEEE Standard for Application and Management of the Systems Engineering Process [IEEE-1220] focuses on the engineering activities necessary to guide project development. Annex B of IEEE-1220 provides a template and structure for preparing a systems engineering management plan along with an informative discussion of each section and subsection.
The key artifacts determined by the Project Planning process step are the definition the Project Management Plan and supporting plans, identified in Table 3, with their backward and forward traceability to other process artifacts or external documents.
Table 3: Project Planning Traceability
|
Traceable Artifacts |
Backward Traceability To: |
Forward Traceability To: |
|---|---|---|
|
Project Management Plan
Systems Engineering Management Plan |
Project programming |
All the other Project-related Process Steps |
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Has an effective project manager been selected?
R Have all project tasks been identified?
R Have all project tasks been defined enough so they are understood by the performing organization?
R Are all needed systems engineering process steps, along with their process, inputs, and outputs identified?
R Does the performing organization agree the task budget is sufficient?
R Has a project schedule been developed, reviewed, and agreed to by all parties?
R Does the performing organization agree the project schedule is sufficient?
R Are all necessary technical reviews identified and planned?
R Is the required content of each deliverable document clear to the performing organization?
R Are the project risk areas adequately identified and a management of the risks addressed?
R Have the necessary documents to support procurement of a contracted effort been prepared [the Request for Qualifications and/or Proposal]?
R Are the Project Management Plan, Systems Engineering Management Plan and any supporting plans documented?
| Related: | |
|
