PROJECT PLANNING (CONTD.):Elements of a Project Plan, Potential Problems

<< PROJECT PLANNING (CONTD.):Outside Clients, Quality Control Planning

PROJECT PLANNING (CONTD.):Sorting Out Project, Project Mission, Categories of Planning >>

Project Management MGMT627

LESSON 17

PROJECT PLANNING (CONTD.)

Broad Contents

Elements of a Project Plan

System Integration

17.1

Elements of a Project Plan:

As we know that the process of developing project plan varies from organization to

organization. However, any project plan must contain the following elements:

Overview:

This is short summary of objectives and scope of project. It is directed to top management

and contains statement of goals of project; brief explanation of their relationship to firm's

objectives, description of managerial structure that will be used for project, and list of major

milestones in project schedule.

Introduction:

This contains more detailed statement of general goals noted in overview section. Statement

should include profit and competitive aims as well as technical goals.

General Approach:

This section describes both managerial and technical approaches to work. Technical

discussion describes relationship of project to available technologies. For example, it might

note this project is extension of work done by company for earlier project. Subsection on

managerial approach takes note of any deviation from routine procedure for instance, use

of subcontractors for some parts of work.

Contractual Aspects:

This critical section of plan includes complete list and description of all reporting

requirements, customer-supplied resources, liaison arrangements, advisory committees,

project review and cancellation procedures, proprietary requirements, any specific

management agreements (for example, use of subcontractors) as well as technical

deliverables and their specifications, delivery schedules, and specific procedures for

changing any of above. Completeness is necessity in this section. If in doubt about whether

item should be included or not, wise planner will include it.

Schedules:

This section outlines various schedules and lists all milestones events. Estimated time for

each task should be obtained from those who will do work. Project master schedule is

constructed from those inputs. Responsible person or department head should sign off on

final, agreed-on schedule.

Resources:

There are two primary aspects to this section. First is budget. Both capital and expense

requirements are detailed by task, which makes this project budget. One-time costs are

separated from recurring project costs. Second, cost monitoring and control procedures

should be described. In additional to usual routine elements, monitoring and control

procedures must be designed to cover special resource requirements for project, such as

128

Project Management MGMT627

special machines, test equipment, laboratory usage or construction, logistics, field facilities,

and special materials.

Personnel:

This section lists expected personnel requirements of project. Special skills, types of

training needed, possible recruiting problems, legal or policy restrictions on work force

composition, and any other special requirement, such as security clearances, should be

noted here. (This reference to "security" includes need to protect trade secrets and research

targets from competitors as well as need to protect national security). It is helpful to time-

phase personnel needs to project needed and in what numbers. These projections are

important element of budget, so personnel, schedule, and resources sections can be

crosschecked with one another to ensure consistency.

Evaluation Methods:

Every project should be evaluated against standards and by methods established at project's

inception. This section contains brief description of procedure to follow in monitoring,

collecting, storing, and evaluating history of project.

Potential Problems:

Sometimes it is difficult to convince planners to make serious attempt to anticipate potential

difficulties. One or more such possible disasters such as subcontractor default, technical

failure, strikes, bad weather, sudden required breakthroughs, critical sequences of tasks,

tight deadlines, resource limitations, complex coordination requirements, insufficient

authority in some areas, and new complex or unfamiliar tasks are certain to occur. Only

uncertainties are which ones will occur and when. In fact, timing of these disasters is not

random.

There are times, conditions and events in life of every project when progress depends on

subcontractors, or weather, or coordination or resource availability, and plans to deal with

unfavorable contingencies should be developed early in project's life cycle. Some project

managers disdain this section of plan on grounds that crises cannot be predicted. Further,

they claim to be very effective firefighters. It is quite possible that when one finds such

project manager, one has discovered arsonist. No amount of current planning can solve

current crises, but preplanning may avert some.

These are elements that constitute project plan and are basis for more detailed planning of

budgets, schedules, work plan, and general management of project. Once this basic plan is fully

developed and approved, it is disseminated to all interested parties.

Below is detailed discussion on some important parts/aspects of a Project Plan.

Introduction/Overview:

The project management plan introduction/overview includes an introduction both to the

specific project and to the project management plan document itself. Some background

information may be included to set the stage or provide perspective on the information that

follows, such as how the project was initiated, who the customer or sponsor is, how the project

is funded, or other factors that are important to those who read the plan. Introductions are

always short, allowing the reader to move into the plan quickly. Additional external or historical

information can be referenced or included in the Appendix.

External factors, such as general or specific economic trends, constraints, or opportunities;

political or governmental conditions; population demographics; or internal organizational

factors, should be discussed.

129

Project Management MGMT627

Mission and Objectives:

The purpose or mission of the project is stated in one or two paragraphs, followed by a set

of concrete objectives. The mission statement is all encompassing, establishing why the

project exists. Mission statements can be general or specific. They also reference the

customer if the project is being performed under contract or for a third party.

Project objectives are outlined as specific goals to be accomplished and to which status they

can be applied. For instance, objectives for a small construction project might include a

good location; a modern energy-efficient economic design; a fully furnished facility; a

complete set of project documents; compliance with all laws, codes, and requirements; a

standard profit margin; and a completion date.

Planning becomes straightforward when objectives are defined for key areas. Objectives

can be established for every aspect of the project, including scope of work, organization,

management, systems, environment, safety, and overall completion of the project (i.e., final

cost and schedule dates). Established objectives in the following areas facilitate detailed

planning, systems development, and work performance:

Technical objectives

Schedule objectives

Cost objectives

Organizational/personnel-related objectives

Quality objectives

Environmental safety and health objectives

Contracting/procurement objectives

Management system objectives

Well-defined objectives enhance the reliability of subsequent planning. Once objectives are stated in

concise terms, they allow for the development of the project scope of work and the work breakdown

structure.

Work Scope:

The work scope section of the project management plan demonstrates how well the project

is understood.

It includes narrative descriptions of all elements of the project's scope of work. It clearly

identifies the products or services to be provided to the customer. The statement of work

contains enough information to allow development of the Work Breakdown Structures

(WBS), schedules, and cost estimates, as well as assignment of responsibilities.

This section can address the project phases and include special plans associated with those

phases, such as the Research and Development plan, engineering/design plans, construction

plan, manufacturing plan, facility start-up plan, or transition plan. It may also describe the

systems management activities, including systems engineering and integration, to ensure

project life cycle perspective. In other words, it shows that the activities necessary to ensure

that the design and final products meet customer requirements are all planned and managed

properly and can be integrated and operated as intended, and that start up, transition,

operation, and completion activities are also planned and managed properly.

To simplify preparation, the work scope can be prepared in outline form, which can then be

used to develop the Work Breakdown Structures (WBS). Often the Work Breakdown

Structure (WBS) and work scope are prepared in parallel, with the resultant narrative

description of the work called a Work Breakdown Structure (WBS) dictionary.

130

Project Management MGMT627

Planning Basis:

The planning basis section provides for the documentation of key approaches, assumptions,

requirements, and other factors considered during preparation of the project management

plan. The following topics are addressed in this section:

Project Deliverables/End Products:

A list of all products, documents, and services to be delivered to the customer

over the life of the project is required.

Requirements:

Requirements are specifications or instructions that must be followed during

project performance.

They may include technical requirements, facilities requirements, data

requirements, management requirements, or special instructions. Technical

requirements may include codes, standards, laws, engineering or design

specifications, models, or examples for mandatory or recommended compliance

on the project. When there are mandatory requirements, such as laws, these

must be identified and listed, or project performers run the risk of

noncompliance and legal prosecution.

Facilities requirements include an initial assessment of types, amount, and

quality of facilities needed for the project, along with related utilities, furniture,

and equipment.

This provides initial bases for estimating quantities and costs associated with

those resources. Overlooking facilities issues during project planning leads to

schedule slippages, cost overruns, unhappy project participants, and untold

headaches for the project managers. For small projects, facility requirements

may not be a big issue; for larger projects, they can be critical.

Functional and operational requirements spell out what the system, facility, or

product being produced is intended to do. They provide the basis for the

engineering, design, and planning of the system, facility, or product. Where

Functional and operational requirements exist, listing or identifying them

greatly simplifies and facilitates the design process. Mandatory data

requirements, management directives, or special instructions are also identified

and documented during the planning process. Special instructions may include

directions from the customer or upper management or may be spelled out in

contract documents.

Constraints:

Constraints may include known technical limitations, financial ceilings, or

schedule "drop dead" dates. Technical constraints may be related to state-of-

the-art capabilities, interface requirements with other systems, or user-related

issues (e.g., software that must run on certain types of personal computers).

Financial and schedule constraints can be introduced by the customer and lead-

time associated with procured hardware or funding/ budgetary limits.

131

Project Management MGMT627

Approaches/Strategies:

The approach or strategies to be utilized can have a major impact on subsequent

planning.

For instance, if all project work is to be performed within the parent (host)

organization with minimum subcontract support that approach impacts planning

of resources and organizational issues. If work is to be "fast-tracked" by

overlapping design and construction activities, or by performing more work in

parallel, then that approach can be described. Communication of strategies to

project participants can be done effectively by devoting several paragraphs to

that topic in this section of the project management plan.

Key Assumptions:

Every project is planned under some degree of uncertainty. Therefore,

assumptions are required to estimate work scope, schedule durations, resource

requirements, and cost estimates. Assumptions are also required when defining

the management strategies, systems, and procedures to be utilized.

Major assumptions are to be documented because they can have a significant

impact on planning and estimating. This is true on all projects, regardless of

size. Large projects, which involve numerous participants and major

complexities, generally depend on more key assumptions during project

planning than smaller projects. The major reason for documenting key

assumptions is to provide the project manager with a basis for revising plans

when the assumptions are changed (that is, when a customer changes his or her

mind).

Specifically Excluded Scope:

This subject may be needed to limit the scope of work. It highlights specific

and relatively obvious issues, such as documentation, training, or follow-on

support, which customers often assume but which cost money and have not

been included in the project plan. Clarification of these scoping questions saves

headaches later, in some cases even avoiding litigation.

17.2

Systems Integration:

Systems integration (sometimes called systems engineering) plays crucial role in performance

aspect of project. We are using this phrase to include any technical specialist in science or art of

project who is capable of performing role of integrating technical discipline to achieve

customer's objectives, and/or integrating project into customer's system.

As such, system integration is concerned with three major objectives:

Performance:

It is what system does. It includes system design, reliability, quality, maintainability,

and reparability. Obviously, these are not separate, independent elements of system, but

are highly interrelated qualifies. Any of these system performance characteristics is

subject to over-design as well as under-design but must fall within design parameters

established by client. If client approves, we may give client more than specifications

132

Project Management MGMT627

require simply because we have already designed to some capability and giving client

over designed system is faster and less expensive than delivering precisely to

specification. At time, esthetic qualities of system may be specified, typically through

requirement that appearance of system must be acceptable to client.

Effectiveness:

Objective is to design individual components of system to achieve desired performance

of optimal manner. This is accomplished through following guidelines:

Require no component performance specifications unless necessary to meet one or

more system equipments.

Every component requirement should be traceable to one or more systems

requirements.

Design components to optimize system performance, not performance of

subsystem.

It is not unusual for clients to violate any or all of these seemingly logical dicta.

Tolerances specified to far closer limits than any possible system requirement,

superfluous "bells and whistles," and "off shelf" components that do not work well with

rest of system are so common they seem to be taken for granted by both client and

vendor. Causes of these strange occurrences are probably associated with some

combination of inherent distrust between buyer and seller, desire to over-specify in

order "to be sure" and feeling that "this part will do just as well". These attitudes can be

softened and replaced with others that are more helpful to process of systems

integration.

Cost:

Systems integration considers cost to be design parameter, and costs can be

accumulated in several areas. Added design cost may lead to decreased component

costs, leaving performance and effectiveness otherwise unchanged. Added design cost

may yield decreased production costs and production cost may be traded off against

unit cost for materials. Value engineering (or value analysis) examines all these cost

tradeoffs and is important aspect of systems integration. It can be used in any project

where relevant cost tradeoffs can be estimated. It is simply consistent and thorough use

of cost/effectiveness analysis. For application of value engineering techniques applied

to disease control projects.

Systems integration plays major role in success or failure of any project. If risky

approach is taken by systems integration, it may delay project. If approach is too

conservative, we forego opportunities for enhanced project capabilities or advantageous

project economies. Good design will take all these tradeoffs avoid locking project into

rigid solution with little flexibility or adaptability in case problems occur later on or

changes in environmental demand changes in project performance or effectiveness.

133

Table of Contents: