|
Project Planning
The overall
objective of project management is to complete more quality projects on
time and within budget. Meeting this goal is easier with well-developed
business and leadership skills based upon a common language and a common
sense methodology. In addition, this language and set of processes must
effectively assist in the areas of planning, scheduling, estimating, staffing,
reporting, tracking, influencing and communicating.
In the process
of defining a project management approach to assist in effective project
management it is important to identify the critical success factors that
ensure practical project management techniques are being developed. As
a result, an affective approach would provide:
- A Repeatable
Process
- Templates
- Guidelines
for
- Estimating
- Approach/Process
Guidelines
- Leadership
Training
And an effective
approach would enable:
- Project
Monitoring/Tracking
- Project
Plan History
Based upon
feedback from K&J Information Systems Managers the following tools have
been determined to assist in meeting the above objectives.
Project
Summary Document Template
IS Division
Project Spreadsheet
Insert
proj9804.xls here.
Preliminary
Project Plan Template
To
be developed.
Detailed
Project Plan Template
To
be developed.
Project
Management Tools
Organizing
the Project
To get started, the manager must gain a clear understanding of the scope
of the project and must establish the basis for control. The major initial
concerns relate to clarifying the requirements, the deliverables, and
the organizational framework. By addressing the 5-Step Model below, the
manager will acquire an understanding of the key elements that will affect
project planning.
The
5-Step Model
The 5-Step Model was designed to categorize project management tasks and
provides project management focus: analysis, organization, staffing, implementation,
and follow-up. These focal points target all the relevant questions such
as the what, why, how, who, when and where of projects. Each step is listed
below. In addition, specific guides have been developed to assist project
managers and these are listed next to the category.
Analyze/Identify
the Requirements (What/Why) – Project or Support Project Summary
Form
Customer
- Who are
we doing this project for?
- Who will
be the key contact people from the customer, developer, and support
groups?
- Do the
different groups understand their areas of project responsibility?
Business
Reasons
- Why is
this project important?
- What is
the objective?
Requirements
- What functions
must the system perform?
- How will
the system be operated?
- Are the
boundaries of the system visible?
- In what
form does the job definition exist?
- Is the
current job definition understandable?
- Does the
project depend on external events or activities?
Deliverables
- What documents,
programs, and files are specified as deliverable products?
- In what
form are the deliverables, e.g., draft copies or on electronic media?
- Who will
receive the deliverables and accept the final product?
- What criteria
will be used to judge the acceptability of the final product?
End date
& costs
- When must
they be delivered?
- What budget
constraints exist?
Organize
(How) – Project Plan/Network Diagram/Task Planning Guide/Scheduling
Guide
- Work Breakdown
Structure (Statement of Work – SOW)
- Plan (Resources/Equipment,
Availabilities/Skill Matrix, Lead Times
- Network
(List Activities, Precedence Diagram)
- Schedule
(Labor hours, Duration, Critical Task, Slack, Early/Late Start/Finish,
Constraints)
- Milestone
Chart
Resource
(Who) – Resource/Staffing Guide/Project Plan/Skills Matrix/Equipment
and Materials/Responsibility Matrix
- People
(Labor Costs)
- External
Contractors (Labor Costs)
- Equipment
& Materials (Material Costs)
- Other
Implement
and Follow-Up (When/Where) – Project Plan/Key Performance Indicators/Performance
Management/Communication Guide/Risk Analysis
- Start-up
- Performance
& Quality Measures (Control, Timeline, Planning Tools, Company Reports
- What
measures will be used to assess project health?
- Obstacle
Management
- What
reviews will be necessary to mark the transitions between phases?
- Are
there technical or managerial risks to successful completion of
the project?
- Communications
& Reporting
- Is
there a timetable for periodic reporting of project status?
- What
is the procedure for incorporating requirements changes that affect
the scope of the work?
Lessons
Learned (Why) – Documentation/Post Audit Review
- Historical
Data
- Database
- Project
Diary
- Continuous
Improvement
Producing
the Project Plan
The project plan provides a disciplined approach to organizing and managing
the software project. A successful plan serves as
- A project
summary.
- A structured
checklist of important questions.
- Consistent
documentation for project organization.
- A baseline
reference with which to compare actual project performance and experiences.
- A detailed
clarification of the management approach to be used.
- By completing
the plan early in the life cycle, the manager becomes familiar with
the essential steps of organizing the development effort.
- Estimating
resources.
- Establishing
schedules.
- Assembling
a staff.
- Setting
milestones.
The plan
should concentrate on information that is unique or tailored to the project
at hand. If standard policies, guidelines, or procedures will be applied
to an aspect of the project, the plan should reference the documents in
which these are defined rather than restating them in detail. Writing
the plan can begin as soon as any information about the project definition
and scope becomes available. The project should be initiated with the
completion of the project summary document found in Appendix A. This completed
document will provide essential project information such as the project
sponsor, project manager, project objectives, deliverables, benefits and
costs. Then a preliminary project plan should be completed by the end
of the requirements analysis phase. This plan should define the proposed
project phases and general timelines. A comprehensive definition of the
resources required to complete each phase of the project needs to be defined
by the end of the detailed design phase. Copies of the plan should be
provided to all levels of project management and the project's technical
staff.
The suggested
format and contents for the software development/management plan is listed
below. The format is intended as a guide. Depending on the application
environment, a different arrangement of items or the addition of new material
may be appropriate.
Software
Development Management Plan
Sections in bold italics describe material that is to be regularly added
to the plan during the life of the Project. Other sections should be revised
and reissued if circumstances require significant changes in Approach.
Title
Page - document number, project and task names, report title, and
report date.
Table
of Contents - list of subsection titles and page numbers.
Introduction
Project
Summary
Project
Name
Proposal
Type
Business
Sponsor
Customer/User
Project
Manager
Project
Proposal/Background
Business
Objective
Project
Goals & Objectives
General
Approach/Technical Architecture
Project
Benefits
Estimated
Project Costs
Project
Deliverables
Project
Completion Criteria
Project
Constraints
Assumptions
Project
Complexity
Project
Risk/Potential Problems
Methodology
Path(s) Being Followed
Project
Resources/Timeframe
Other
Factors
Priority
Project
Plan
Project
Spreadsheet
Key
Performance Indicators
Risk
Analysis
Communication
Guide
The
project customer, sponsor and management, at the very least, need
to be kept informed regarding project progress, successes and problems.
Project are generally more successful if a specific method for communicating
and timeline is established up front. The communication
guide may be useful in outlining these requirements.
Technical
Approach
- Reuse
Strategy - description of the current plan for reusing software from
existing systems.
- Assumptions
and Constraints - that govern the manner in which the work
will be performed.
- Anticipated
and Unresolved Problems - that may affect the work and the
expected effect on each phase.
- Development
Environment - target development machine and programming languages.
- Activities,
Tools, and Products - for each phase, a matrix showing
- The
major activities to be performed.
- The
development methodologies and tools to be applied.
- The
products/deliverables of each phase. Includes discussion of any
unique approaches or activities.
- Build
Strategy - what portions of the system will be implemented
in which builds and the rationale. Updated at the end of detailed
design and after each build.
Executing
the Software Development Management Plan
The plan will be an effective management aid only to the extent that it
is followed. The manager must direct and control the execution of the
plan by:
- Maintaining
it
- Measuring
progress and performance
- Recognizing
danger signals.
- Taking
corrective action to solve problems
At the
end of each development phase or build, the manager should re-estimate
project size, effort, and schedule for inclusion in the software development/management
plan. Earlier estimates should not be removed from the plan. They provide
a record of the planning process that will be needed for the software
development history. From this information, the organization can determine
which estimation methods were effective and should be used again.
When it
is effectively maintained, the development plan documents the current
strategy for the software development effort. By providing a uniform characterization
of the project, the plan can be invaluable if changes occur in team leadership.
Significant
revisions to the plan should not be considered routine maintenance. Effort
should be invested when the plan is written to ensure that it is realistic,
rather than continually modifying it to agree with actual decisions or
experiences. Major shifts in technical approach or use of methodologies,
for example, should occur only if necessary. By measuring progress, the
manager discovers whether the development/management plan is effective
or not.
Warning
Signals and Corrective Actions
When a project is in trouble, the manager must take immediate corrective
measures to move it back on a successful course. Below is a list of warning
signals and explanations of the potential problems. The following section
identifies corresponding corrective actions for some of these common problems.
Problems
with Requirements and Specifications
Number of
TBD requirements higher than norm or not declining.
If critical
specifications are missing, design of the affected portions of the system
should not proceed until the information is obtained. In non-critical
cases, development may continue despite the incompleteness. Assess the
effect of missing requirements/specifications and determine whether
relatively safe assumptions about the missing information can be made.
Before starting the next phase, prepare a risk management plan. For
all TBD specifications, assign due dates for resolution of TBDs and
notify higher management if schedules are not met.
Number of requirements
questions submitted vs. questions answered is high and increasing
Indicates
inconsistent or confusing specifications. Difficulties become compounded
if development is permitted to continue. Stop development activity and
resolve inconsistency or confusion in consultation with the user organization.
Negotiate a reduction in the scope of the system by defining an understandable
subset of the original system. Document all assumptions about requirements
in the functional specification.
High number
of specification modifications received vs. number completed
If major
changes or additions to requirements are unavoidable, the design of
the affected portion of the system must be postponed. Split development
into two releases, with the late specifications included in the second
release. Hold a separate DDR for the second release.
Problems
with System Design
Actual number
of components designed is fewer than estimated at a particular point
in the detailed design phase
Lack
of design growth may be due to poor direction from the team leader,
inexperienced staff, use of new technology, or changing requirements.
Determine the cause of the slow growth. Based on the cause, either replace
junior personnel with senior personnel, provide training, decrease staff
size to a manageable level, set up a prototyping effort to improve technical
understanding, or decrease the scope of the system.
Problems
with Implementation
Actual number
of units coded, tested, and integrated is fewer than those estimated at
a particular point in the implementation phase
Lack
of code growth may be due to poor direction from the team leader, inexperienced
staff, changing requirements, or incomplete design. Determine the cause
of the slow growth. Based on the cause, replace junior personnel with
senior personnel, stop staff growth, or hold changes and complete implementation
of a build first.
Number of
completed units increases dramatically prior to the scheduled end
of a build or release (the "miracle finish")
Indicates
that code reading and/or unit testing were inadequately performed, and
many coding errors have not been found. Reschedule the effort so that
code reading is performed properly; otherwise, substantially more time
will be consumed during system testing in isolating and repairing errors.
Problems
with System or Acceptance Testing
Testing phase
was significantly compressed
Testing
may not have been as complete or as thorough as necessary. Review test
plan and results closely; schedule additional testing if indicated.
The number of
errors found during testing is below the norm
Test
results may have received inadequate analysis. Use personnel experienced
in the application to review test results and determine their correctness.
Rerun tests as necessary.
Problems
with System Configuration
More than
one person controls the configuration
Sharing
of configuration control responsibilities can lead to wasted effort
and the use of wrong versions for testing. Select one person as the
project librarian, who will organize configured libraries, implement
changes to configured components, and issue documentation updates about
the system. The technical leader responsible for QA must authorize component
changes.
''Corrected''
errors reappear
The
corrected version may not have been used because more than one person
controlled the configuration, or the staff was not aware of the ripple
effect of other changes that should have been made when the original
error was corrected. Consolidate configuration control responsibility
in one person. Assign more senior staff to analyze the effect of error
corrections and other changes.
Problems
with Development Schedules
Continual
schedule slippage
Staff
ability may have been misjudged or the staff needs firmer direction.
Bring in senior-level personnel experienced in the application to direct
junior-level personnel and provide on-the-job training. Decrease the
scope of the system.
Development
activity is uneven and ragged; effort drops dramatically immediately after
a milestone is reached
Personnel
have been assigned to work part-time on too many projects. Staff will
tend to concentrate on a single project at a time, sometimes to the
detriment of other project schedules. Reassign personnel, preferably
to one project, but never to more than two at a time.
Personnel turnover
threatens to disrupt development schedule
The
effect of turnover is not directly proportional to the number of staff
involved. For each key person who leaves a project, two experienced
personnel should be added. A junior project member should be replaced
by a person at least one level higher in experience. Only in this way
can a manager balance the effects on the schedule of the training and
familiarization time new staff will require.
Capabilities
originally planned for one time period are moved to a later time period
If a
corresponding move of later capabilities to an earlier time period has
not been made, the danger is that the development team will not be able
to handle the additional work in the later period. Obtain justification
for the change with detailed schedule information for the new and old
plans. If the shift of capabilities is extensive, stop development activity
until the development/management plan can be revised, then proceed.
Change or decrease
in planned use of methods or procedures occurs
The
methods or procedures had some use or expected benefit or they would
not have been included in the development plan. Obtain justification
for the change, to include showing how the expected benefit from the
planned use of the method will be realized in light of the change.
Basic
Set of Corrective Actions
Some consistent themes appear in the lists of corrective actions, regardless
of problem area. These recommendations constitute some basic approaches
to regaining control of the project when danger signals arise.
- Stop current
activities on the affected portion of the system and assess the problem.
- Complete
predecessor activities.
- Decrease
staff to manageable level.
- Replace
junior with senior personnel.
- Increase
and tighten management procedures.
- Increase
number of intermediate deliverables.
- Decrease
scope of work and define a manageable, doable thread of the system.
- Audit
project with independent personnel and act on their findings.
|
