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
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 timephase
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.
130
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.
131
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:
1. 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.
2. 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.
3. Constraints:
Constraints may include known technical limitations, financial
ceilings, or
schedule “drop dead” dates. Technical constraints may be related
to state-ofthe-
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 leadtime
associated with procured hardware or funding/ budgetary limits.
132
4. 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.
5. 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).
6. 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:
1. 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
133
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.
2. 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.
3. 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. |