OISProject Management Guide

OFFICE OF INFORMATION SERVICES
PROJECT MANAGEMENT GUIDE

TABLE OF CONTENTS
Project Management Responsibilities ................................................................................................................. 4
Overview ............................................................................................................................................................. 4
Assignment of Roles........................................................................................................................................... 4
Understand Project Needs............................................................................................................................... 4
Acknowledge Staff Capabilities ..................................................................................................................... 4
Align Project Needs and Staff Capabilities with Project Management Responsibilities................................ 5
Project Management Life Cycle Phases.............................................................................................................. 6
1.0 Initiating the Project................................................................................................................................. 7
1.1 Project Concept ...................................................................................................................................... 7

1.2 Project Charter....................................................................................................................................... 7
2.0 Project Planning........................................................................................................................................ 8
2.1 Project Scope .......................................................................................................................................... 8

2.1.1 Functional Requirements ................................................................................................................ 8
2.1.2 Deliverables/Milestones.................................................................................................................. 9
2.1.3 Assumptions.................................................................................................................................... 9
2.2 Project Organization ............................................................................................................................ 10
2.3 Project Work Plan............................................................................................................................... 10
2.3.1 Define and Sequence Tasks and Document Tasks Relationships................................................. 11
2.3.2 Estimate Task Duration and Resources Required to Perform Each Task..................................... 12
2.3.2.1 Create the Initial Estimate of Effort Hours ............................................................................... 12
2.3.2.2 Document the Estimate ............................................................................................................. 13
2.3.2.3 Calculate Total Effort ............................................................................................................... 13
2.4 Project Management Plans.................................................................................................................. 13
2.4.1 Communication Plan..................................................................................................................... 14
2.4.1.1 Status Reporting........................................................................................................................ 16
2.4.2 Issue Management Plan ................................................................................................................ 16
2.4.3 Change Control Plan ..................................................................................................................... 17
2.4.3.1 Identifying Changes .................................................................................................................. 19
2.4.3.2 Reviewing and Evaluating Changes ......................................................................................... 19
2.4.3.3 Communicating Change............................................................................................................ 20
2.4.4 Risk Management Plan ................................................................................................................. 20
2.4.4.1 Risk Identification..................................................................................................................... 21
2.4.4.2 Risk Assessment ....................................................................................................................... 22
2.4.4.3 Risk Planning ........................................................................................................................... 23
2.4.4.4 Risk Monitoring and Control .................................................................................................... 24
2.4.5 Quality Management Plan............................................................................................................. 24
2.4.5.1 Quality Control ......................................................................................................................... 25
Page i
2.4.5.2 Quality Assurance..................................................................................................................... 26

2.4.5.3 Project Classifications............................................................................................................... 26
2.4.6 Training Plans ............................................................................................................................... 28
2.4.6.1 Project Team Training .............................................................................................................. 28
2.4.6.2 End User and Support Team Training ...................................................................................... 28
2.4.7 Document Management ................................................................................................................ 29
2.4.7.1 Document Repository ............................................................................................................... 30
2.4.7.2 Access Rules ............................................................................................................................. 30
2.4.7.3 Logical / Physical Organization................................................................................................ 30
2.4.7.4 Naming Standards..................................................................................................................... 30
2.4.7.5 Versioning................................................................................................................................. 30
2.4.8 Project Plan Summary and Sign-Off............................................................................................. 31
3.0 Project Execution & Control ................................................................................................................. 32
3.1 Kick-Off Meeting.................................................................................................................................. 33

3.2 Manage the Project Work Plan ........................................................................................................... 33
3.3 Execute the Communication Plan....................................................................................................... 33
3.4 Manage Issues...................................................................................................................................... 35
3.5 Manage Scope and Control Change ................................................................................................... 35
3.6 Monitor and Control Risks .................................................................................................................. 36
3.7 Implement Quality Management......................................................................................................... 37
3.8 Execute the Training Plans ................................................................................................................. 38
3.9 Manage Project Documentation.......................................................................................................... 38
3.10 Other Aspects of Project Execution..................................................................................................... 40
3.10.1 Manage the Project Team ............................................................................................................. 40
3.10.2 Manage Vendors ........................................................................................................................... 41
3.10.3 Plan for Organizational Change.................................................................................................... 41
3.10.4 Plan for Implementation, Operational Transfer and Support........................................................ 42
4.0 Project Closeout ...................................................................................................................................... 44
4.1 Prepare Project Closure Report........................................................................................................... 44

4.1.1 Identify Lessons Learned from the Project Team......................................................................... 44
4.1.2 Solicit Feedback from Primary User(s) ........................................................................................ 45
4.1.3 Prepare Project Closure Report..................................................................................................... 45
4.2 Administrative Closeout....................................................................................................................... 45
4.2.1 Archive Documentation ................................................................................................................ 45
4.2.2 Close Contract............................................................................................................................... 45
4.2.3 Gain Project Acceptance and Sign-Off......................................................................................... 46
4.2.4 Celebrate Project Completion ....................................................................................................... 46
Appendix A: Project Risk Factors..................................................................................................................... 47
Page ii
Appendix B: Risk Management Strategy Table .............................................................................................. 48
Appendix C: Project Closeout Process Flowchart........................................................................................... 54
Page iii
PROJECT MANAGEMENT RESPONSIBILITIES

Overview
The project manager has primary responsibility for the quality of a project's deliverables and is expected to
create a workable plan and manage it to a successful conclusion. To succeed, the project manager must
work closely with management to ensure that adequate resources are allocated. The project manager
should be assigned early in the conceptual and planning process so the plan can be owned by the person
responsible for its execution. He or she leads the team through a planning phase and then monitors and
controls the project until it successfully concludes.
This guide was developed to help management determine who the project manager for a project will be,
and assist the project manager in developing a thorough plan for management of the project to a successful
completion. Project managers should use these guidelines to develop project documentation to fit the
project’s resources, timeline, and scope or business objectives. Because it is difficult to allocate time for
organizing and planning later in the project, project managers must make sure that time is allocated up
front to accomplish these activities. A clear understanding of what will be done, why, by whom, and when
it will be done will be invaluable for maintaining the momentum of the project.
Assignment of Roles
When assigning a project manager and project management responsibilities, there are many factors that
should be considered These factors are discussed below, and should be used in the beginning stages of a
project’s life cycle to help the project manager prepare for the role he/she will be expected to perform.
Understand Project Needs

• Is there a customer?
Not every project will have a specific customer. Ultimately, the business itself is the project customer.
For certain projects, there may be no specific end-user group involved. In these projects, end-user
communications and relationship management skills may take a back seat to pure technical and time
management skills, and therefore, project assignments can be made accordingly.
• Are external consultants or vendors involved?
In this case, the internal IT project manager may need to fill a liaison role, and communications and
organizational responsibilities will become a primary factor in project success.
Acknowledge Staff Capabilities

As project management roles and responsibilities are assigned, internal capabilities must be considered to
ensure that roles and responsibilities are realistic and that the desired results can actually be achieved.
When determining project management responsibilities, the following issues must be considered:
• Skill levels .... does any one individual have the necessary skills to successfully manage the project.
Some of the attributes of a project manger are:
o A leader to provide clear direction and inspire others.
o A planner and controller to facilitate project planning and evaluate work product.
o A communicator to serve as the central point for transmitting accurate project information.
o A negotiator to obtain the time and resources needed, and to negotiate changes in scope.
o A problem-solver to determine root causes of problems and make decisions on the best
solution.
Page 4
o An organizational change agent that knows how to get things done and how to influence the
organization to bring about change.
• Available time .... considering other priorities and existing workload, can any one individual devote
sufficient time to the project? If not can the project scope be modified, or broken down into sub-
projects assigned to different individuals?
• Priorities .... can other projects or workload be balanced differently to allow for one individual to
manage the project at hand?
• Authority ... how much authority will the project manager need to get the job done, and is that level of
authority organizationally feasible? If not, what are the risks associated with a lack of authority and
how can management responsibilities be assigned to compensate?
Align Project Needs and Staff Capabilities with Project Management Responsibilities
Considering project needs and internal staff capabilities, the project management responsibilities required
to drive the project to success need to be identified.
• Technical Responsibilities: Does the project manager have to have specific technical skills or
expertise to manage this project?
• Planning Responsibilities: What planning responsibilities will be required to manage this project?
o Identify technical requirements.
o Define scope, goals, and deliverables.
o Identify resource requirements.
o Select the project team.
o Estimate time, costs and schedules.
o Prepare and present the project plan.
• Execution Responsibilities: What execution responsibilities will be required to manage this project?
o Hands-on technical contributions.
o Maintain and monitor the project plan.
o Approve, reject and apply change requests.
o Monitor and resolve open issues.
o Track project progress.
o Manage the project budget.
o Manage vendor relationships.
• Communications Responsibilities:
o Communication with customer (end-user). What types of communication will be required?
Negotiation of requirements, acceptance criteria, schedules and scope changes.
Problems and issues communication.
Status reporting.
o Communication with Project Sponsor/Management. What types of communication will be
required?
Negotiations for resources (staff and funding)
Status reporting.
Problem escalation.
Coordination with a project steering committee.
Page 5
• Staff Responsibilities: What staff management responsibilities will be required?

o How large is the project team?
o Depending on the size and experience of the project team, what extent of staff management
experience is required?
o Will all team members report directly to the project manager or to project team leaders?
o Will project team members continue to report directly to line managers during the term of the
project?
o Will the project manager be responsible for evaluating staff performance?
o Will the project manager have the authority to remove or reassign project team members?
• Management Expertise:
Depending on the size, complexity and visibility of the project, should the project manager have
extensive management experience, or can an inexperienced manager be assigned?
PROJECT MANAGEMENT LIFE CYCLE PHASES
The Project Management Life Cycle is based on the following four phases:
1.0 Initiating Recognizing that a project or phase should begin and committing to do so.
2.0 Planning Devising and maintaining a workable scheme to accomplish the business need that the
project was undertaken to address.
3.0 Executing &
Controlling Coordinating people and other resources to carry out the plan and ensuring the project
objectives are met by monitoring and measuring progress and taking corrective action
when necessary.
4.0 Closing Formalizing the acceptance of the project or phase and bringing it to an orderly end.
Page 6
1.0 INITIATING THE PROJECT

1.1 Project Concept
The Project Concept is the foundation for initiation of the project. The purpose of the Project Concept is
to provide high-level information that describes the characteristics of the product/process to be created.
It should explain what problem or opportunity exists to improve a business function and provide the
evidence that proves the problem or opportunity exists. The Project Concept should also provide the
expected business result or desired outcome of the project and the benefits the project will provide when
it is completed. This is necessary not just to ensure that the best choices are made, but it is critical to
ensuring the acceptance of those choices by management and end-users. Estimated project costs,
including hardware and software, resource requirements, and an implementation time frame should also
be identified.
Some sample benefits to be considered when developing the Project Concept:
o implementation of new technology o lowers technical support costs

o upgrade of existing technology o facilitates technical support activities
o change in policy or procedure o improved system ease of use
o organizational changes o increased productivity
o process re-engineering o improved workflow
o maintains/improves system reliability o facilitates internal or external
o maintains/improves system security communication
o maintains/improves system performance o reduces training requirements
o to keep systems current (configuration or o eliminates or reduces the need for
version) external resources
o protects current investment in o simplifies procedures through ease of
technology operation
Information technology (IT) projects and initiatives with a total projected cost equal to or greater than
$100,000 will require initial approval by the Office of Information Technology (OIT). Refer to OIT
Guideline GUI-001 to determine whether OIT approval is required, and the appropriate OIS IT
Procurement Manual or OIS RFP/Contract Procedure Manual for the process.
1.2 Project Charter

The Project Charter is created to recognize that a project or phase should begin and obtaining
commitment and approval to do so. It will establish the initial scope of the project by defining the work
that is to be included or not included in the project. The charter should also define the project’s
objectives, which are those criteria within the project that will determine whether the project is a success
or a failure. Objectives can be described in two different ways:
• Hard Objectives - These relate to the time, cost, and operational objectives (scope) of the product or
process.
• Soft Objectives - These relate more to how the objectives are achieved, and which may include
attitude, behavior, expectations, and communications.
Page 7
Objectives need to be clearly stated and there must be a clear understanding as to why they are relevant
to the project. The objectives will be the benchmark for which project success will be set. They should
coincide and be consistent with overall project scope and schedules.
Project objectives are also used to establish performance goals, or planned levels of accomplishment
stated as measurable objectives that can be compared to actual results. Performance measures should be
stated for each goal.
The Project Charter should also describe the development approach. In a small project, there is typically
a single project development phase. In a large or complex system, however, there may be multiple
development phases often spanning multiple fiscal years and addressing different functional
requirements.
Segmenting project development phases is sometimes driven by the need to achieve certain levels of
functionality prior to the availability of the complete system (i.e., phased or iterative implementation).
Other times, the development phases are used to partition the development effort and to reduce the risks
associated with larger projects.
For large systems, the decomposition of the project into multiple development phases should be done
early and the rationale must be documented because amendments to the project tasks list and schedule
are dependent upon the rationale and may jeopardize project success. For example, if the development
phase has been defined to accommodate user needs, the phase may cross multiple functional areas of the
system. However, if the development has been divided into phases to reduce risk, the division might
represent completion of entire functional areas of the system.
Finally, the Project Charter should identify the project organization, including key agency participation
and subject matter experts needed to support the project, define the primary roles and responsibilities,
and identify project assumptions.
The objectives of creating a Project Charter are:
• To provide the initial scope on which the project will be planned.

• To obtain a common understanding of the business need or issue to be resolved by the project or
phase.
• To provide clear and, as far as possible, verifiable or quantifiable business objectives that a solution
must deliver.
• To obtain sponsorship, organizational commitment, and assign key leadership roles.
Page 7
2.0 PROJECT PLANNING

Planning is a process that includes more detailed activities to estimate the size of the project, the scope
of the effort, and the resources required to complete the project, as well as steps to produce a project
schedule, identify, assess and manage risks, and negotiate commitments. The amount of planning
performed should be proportionate with the scope and the usefulness of the information developed.
The planning process is two fold. It involves developing the core work plans – work activities,
resources, sequencing, and timing, while at the same time developing project management plans to
control the project or phase. Collectively, the plans represent what is required to create the solution and
manage all aspects of the work. Depending on the business need, the technical complexity, and who
must be involved, a project or phase may require more or less detail to manage and control the work
execution.
A Project Plan is developed from the results of the planning process activities and puts them into an
integrated, consistent, and coherent document to ensure that all of the various elements of the work are
properly coordinated.
The Project Plan forms the basis for all management efforts associated with the project. The project
manager must be able to produce a product(s) based upon information contained in the plan. As a "living
document," the plan is expected to be modified and updated during the project lifecycle as the project
proceeds through its phases and as new project information is identified.
The objectives of creating a Project Plan are:
• To create an initial plan that is focused upon the agreed scope, objectives and problems that the
project must resolve.
• To obtain a common understanding and agreement of the work and resources required, creating a
solution and managing all aspects of the phase or project.
• To reiteratively update the project plan as changes occur on the project and as new information
becomes available.
• To obtain an agreement on how the project will be managed.
The following components make up the Project Plan.
2.1 Project Scope

While the Project Charter defined the initial scope of the project (what is within the boundaries of the
project and what is outside those boundaries), the Project Plan further builds on the scope to include the
functional requirements, major deliverable milestones, and assumptions. This integrated scope will serve
as the test for every change request received, and is the basis for future project decisions.
2.1.1 Functional Requirements

While the business requirements documented in the Project Concept answered the question of
why a project is needed, the functional requirements specify what the solution will do. The
functional requirements should clearly indicate the desired functionality, capacity, or capability
expected.
Page 8
2.1.2 Deliverables/Milestones
Milestones denote the completion of key project activities, and major milestones should be
summarized in the Project Plan. Milestones pertain to a point in time and should be used as
management checkpoints to measure accomplishment. The number of tasks and milestones
identified should relate to what is known about the project, the level of risk, and the level of
detail required of management.
While milestones are unique to each project, some common information technology project
milestones are shown below:
• Requirements approved • Unit test completed

• Phase review approved • Integration test completed
• Prototype approved • Acceptance test completed
• Design reviews completed • System accepted by customer
• Code reviews completed • Documentation delivered
For contracted work, milestones are often used as a point in the project where interim payments
might be made. If this approach is used, mutual agreement is necessary on the content of each
milestone and the cost associated with that milestone.
Milestones should have the following characteristics:
• They are a point in time, and therefore have no duration. In most project management
software, you define a milestone by setting the duration of an Activity to zero.
• Milestones represent major points of progress within the project, and will provide a high
level means of communicating. Therefore they should represent events that have significant
importance for project stakeholders. As an example, if the project charter or statement of
work included committed deliverables that the stakeholders felt were important to the success
of the project, then each of these committed deliverables should have a milestone
representing its completion.
• Milestones should be named as past tense events. As an example, “Acceptance Test
Completed”. This communicates two facts: the life cycle phase or the major deliverable, and
the fact that it is completed.
• Milestones can also represent the beginning of a process, as in “Acceptance Test Started”,
but the completion milestones should always be included in the Work Breakdown Structure
(WBS) whereas the start milestones are optional.
Documenting and tracking deliverables/milestones not only keeps the project on track, it also
serves as a useful communication tool for stakeholders and the project team. Over the course of
the project, the comparison of due dates to actual dates provides an indication of project health.
2.1.3 Assumptions
Documentation of the assumptions made in planning the project is critical to the success of the
project. Without clear documentation of these assumptions, later changes to the schedule are
very difficult and risky. If, for example, a schedule was shortened because it was assumed that a
Page 9
highly skilled person would be performing the work, that assumption should be documented.
Then, if a less skilled person is actually assigned to perform the task, the project manager can
recognize the risk and make necessary changes and decisions. Without documentation of the
assumption, the schedule could be placed in serious risk without the project manager realizing it.
2.2 Project Organization

Organizing the project includes identifying, documenting, and assigning project roles and
responsibilities as they relate to the work defined. The project plan should include an organization chart
of the project team, including those internal and external to OIS. The plan should also include key
project members’ names, project position, and responsibilities. It is also important to identify all other
stakeholders. A stakeholder is someone who has a business interest in the outcome of a project, is
directly involved in the project, or will contribute resources to the project. Small projects will require
less organizational definition than larger projects, but responsibilities should always be defined.
2.3 Project Work Plan

A work plan must be prepared and used to manage the effort. This includes defining the project’s work
activities and establishing checkpoints when the project can be evaluated to ensure that it is appropriate
to continue. It is a vital tool to ensure that the project team knows what they need to do.
Schedule development means determining start and finish dates for the project activities defined and
allocation of the resources to these activities. This process is iterated as the other planning process steps
provide the inputs (especially activity definition, duration estimating and resources requirements prior to
final determination of the project schedule.
Developing the schedule can be done informally in a table or spreadsheet when the number of activities
is approximately 20, relationships are not complex, and analysis of critical path is fairly simple to
manually assess. The type of schedule associated with a project relates to the complexity of the
implementation.
For small projects, a GANTT chart (or bar graph) is adequate. These schedules are two-dimensional
representations that show the tasks and the timeframe for completion. Since task interrelationships are
not easily shown on a GANTT chart, it is considered a weak planning tool for complex information
technology projects. However, the GANTT chart is very common for reporting status and for defining
the schedule.
For moderate to complex projects, Microsoft Project will be used. Microsoft Project typically combines
critical path analysis and resource leveling based on the project calendar to establish the start and end
dates for each activity. The critical path is the path with activities that cannot be delayed or the project
finish date will be delayed, unless the time can be offset somewhere else on the critical path. Microsoft
Project will determine the critical path and can be used to produce a network diagram, or graphical
representation of how tasks interact with each other. It is a valuable tool because it forces the planner to
address sequencing constraints that might otherwise be missed.
Page 10
2.3.1 Define and Sequence Tasks and Document Tasks Relationships

Defining the project’s work activities is done by subdividing the major deliverables (as identified
in the scope statement) into smaller, more manageable components in order to:
• Improve the accuracy of time, and resource estimates.

• Define a baseline for performance measurement and control.
• Facilitate clear responsibility assignment.
These activities should represent the major deliverables and should include all work activities
including the project management work activities and work activities that are the result of the
other project plans, i.e. the Quality Management Plan.
The decomposition of the major deliverables into work activities and then tasks is referred to as
the Work Breakdown Structure (WBS). Determine the large chunks of work that must be
completed for the entire project to be completed into whatever structure makes sense for your
project. Examples:
• Traditional High level Timeline (Planning/Analysis/Design/Construct/Test/Implement); or

• By Deliverables; or
• By Functional Tasks
The WBS reflects activities associated with overall project management, requirements, design,
implementation, transition management, testing, training, installation, and maintenance. The
project manager is responsible for defining all top level tasks associated with a project and then
further decomposing them as planning continues. It is imperative that a high-level WBS be fully
decomposed into manageable and assignable work packages because the WBS serves as a
critical input to many of the project planning documents.
Some useful tips for determining if your level of breakdown is sufficient:
• Activities should be able to be completed by the same person or group of people. If not, the
activity should be further broken down into sub-activities.
• Activities should represent unique work that can be distinguished from other assignments and
can be identified and fully understood by those assigned the work. If not, then it should be
further broken down into sub-activities to provide clarity.
• Activities should have a clearly defined duration or a total effort that can be scheduled.
• Activities should follow the 8/80 guideline in which no work package should be fewer than
eight labor hours or more than 80 labor hours. The idea here is that you don’t want to track
anything that takes less than a day, but if it takes more than 10 days to complete, it should
probably be broken down into one or more work packages.
After the tasks and milestones to deliver a product are determined, they should be logically
sequenced to reflect the way the work will be performed. Sequencing establishes the
dependencies among the tasks and milestones and is used to calculate the schedule to deliver the
product.
Page 11
Task relationships exist when there are activities that must be completed before other activities
can start. The WBS structure denotes a hierarchy of task relationship. Subtask completion rolls
up into task completion, which ultimately results in project completion. However, there are also
relationships (dependencies) between tasks that need to be identified and the tasks restructured to
minimize dependencies. If the tasks are not organized efficiently, it may become difficult to
schedule and allocate resources to the tasks.
2.3.2 Estimate Task Duration and Resources Required to Perform Each Task
Estimating task duration is one of the most challenging aspects of project planning. The
estimation process is complex because activity duration is affected by numerous variables that
must be dealt with concurrently in the Planning Phase. Some of these variables include staff
availability, the skill level of the person assigned to the task, unexpected events, efficiency of
work time, and mistakes and misunderstandings during the execution of the project.
When estimating the duration of a task, reality is a major factor. The knowledgeable scheduler
takes into account absenteeism, holidays, meetings, discussions, and interaction among the staff.
No one is 100 percent productive every hour of the workday. If a scheduled task assumes 100
percent productivity, the schedule rapidly falls apart. A successful schedule builds these types of
factors into the duration estimates. An accepted rule of thumb for estimating staff productivity is
that an employee spends 85 percent of their time on productive tasks, while the remaining 15
percent accounts for staff meetings, stretch breaks, shifting from one productive task to another,
etc.
2.3.2.1 Create the Initial Estimate of Effort Hours

An estimate in a project is intended to predict how much time and the amount of
resources a project will require. Successful estimating involves the use of the following
time-tested techniques.
Historical Information
Historical information is data or documentation that may exist from a previous project
that is identical to the current project. If a project has been done before, a project
manager can learn a great deal of knowledge from the documents associated with the
project.
Analogous Information
Analogous information comes from components of other projects that are very similar,
but not identical, to components of the current project. Analogous information can
also come from operational experience.
Phased Estimating
Phased estimating is a technique in which estimates are constructed separately for each
phase of the project. This approach may be appropriate when there is enormous
uncertainty about what will be involved in a project, and an overall project estimate
Page 12
would be mostly guess work. In this scenario, the project may be separated into a
series of sequential phases, and a new estimate is created for each phase of the project.
Bottom-Up Estimating
Bottom-up estimating is very time consuming, but it the most accurate technique
available. This approach requires a WBS in which the work package estimates are
rolled up in order to calculate the total estimate for the project. However, if the work
package estimates are flawed, so will be the project estimate. The people providing the
estimates must know how the work actually gets done, and they cannot overestimate or
pad the time required.
2.3.2.2 Document the Estimate

• Add contingency hours, used to reflect the uncertainty or risk associated with the
estimate. If you have time to create a reasonably accurate estimate based on
estimating each work package, contingency may be 5-10%. If the estimate is based
on a similar project with reliable historical information, but lacks the detail
required for high accuracy, the contingency may be 15%. If the estimate was
developed without the benefit of detailed data, or the accuracy of the estimate is
not well known, the contingency could be 35%. Add contingency hours as a
separate item, do not pad estimates.
• Add time for project management activities, generally 15% of the effort hours for
full-time project management.
• Include hours of indirect project resources, i.e. administrative help.
2.3.2.3 Calculate Total Effort

Estimate duration by converting hours to duration.
• Use a factor of 6.5 productive hours per day (based on a 40 hour work week) to
account for meetings, administrative activities, sick time, and other non-productive
activities.
• Determine the number of resources to be applied to each activity.
• Factor in available workdays for the timeframe, taking into account holidays,
vacations, and training.
• Take into account any resources that are not full time.
• Calculate delays and lagtime, i.e., waiting on deliverable approval before beginning
next task.
• Determine what work can be done simultaneously.
2.4 Project Management Plans

The purpose of project management plans is to identify the mechanisms to be used to manage a project
in the areas of communication, change control, risk management, quality management, training and
documentation. The execution of the project plans is discussed in Section 3.0.
Page 13
2.4.1 Communication Plan

The purpose of a communication plan is to determine the communication needs of all people
within OIS, and possibly external to OIS, that will be affected by the project. Proactive
communication is important on all projects. The project manager must make sure team members,
stakeholders, end users, and post implementation support teams have the information needed
well in advance to prepare to accept, use, and support the project once it is implemented.
A communication plan allows the manager to think through how to communicate most
efficiently and effectively to various audiences. Effective communication means providing
information in the right format, at the right time, and with the right impact. Efficient
communication means providing the information that is needed and nothing more. This creative
and proactive communication is laid out in a communication plan, which is created as follows.
• Identify “Who” the recipients or groups of recipients of communication are intended to be.
• Identify “What” type of communications (e.g. email, memo, letter, newsletter, personal
conversation, documentation of meetings, status update) will be delivered to the various
recipient groups.
• For each recipient group, identify who is responsible for delivering the communication.
Facilitating the communications includes things like creating the agenda, scheduling the
meeting, facilitating the discussion and preparing documentation.
• For each recipient group outline “When” the schedule or dates of communication, e.g.
weekly, monthly, a specific day…are to occur.
Resulting communication activities should be documented in a communication plan and added to

the work plan. This will include assigning frequencies, due dates, effort hours and a responsible
person(s) for each communication option implemented.
OIS has developed a Project Team Communication Plan and an End User Communication Plan
for the purpose of identifying target audiences to receive various types of communication
regarding the project. The Project Team Communication Plan identifies the types of internal
communication to be used on the project. The End User Communication Plan identifies the
target groups impacted by the project and the types of communication that will be used to
communicate with the target groups. Training of target groups is documented in the training
plan. All target audiences must be notified of the anticipated timing of events to give them ample
time to prepare and participate in the project as required.
Communication is also a way to manage expectations about how the project is going and who
needs to be doing what. This can be as simple as talking to team members about how they are
doing on their assigned work, or holding a regularly scheduled status meeting. Proper
communication can go a long way toward ensuring project success.
On smaller projects, communication is simple and does not require much proactive effort.
However, communication becomes much more complex as projects increase in size and scope
and involve more people. Larger projects require project managers to plan communication in
advance, taking into account the particular needs of the people involved. This is where the
communication plan proves most useful.
Page 14
The following are guidelines on establishing a communication plan commensurate with the size
of a project:
Small Projects
Small projects usually do not need more than basic status reporting (i.e. e-mails, team status
reports) if the Project Manager is doing any hands-on work on the project. However, if the
project manager is not working on the project, a formal status reporting process may be needed.
The following process could be typical:
• Project team members communicate status to the project manager on a weekly basis.
• The project manager communicates status to the project sponsor and stakeholders on a
periodic basis.
Note: Be careful about the frequency of reporting. A more frequent status may be needed for
projects of short duration to allow stakeholders time to react to anything unusual.
• The entire project team holds informal project status meetings. The meetings would focus on
the status against the Project Work Plan and uncovering any current issues, scope change
requests or potential risks. Stakeholders could be invited to attend, but their attendance is not
mandatory. The frequency of the meeting depends on the timetable for the project, and the
need to get information in a timely manner.
Medium Projects
Medium projects should include formal status meetings and status reporting:
• Status Meetings: Stakeholders should have representation at the status meeting. If the project
manager prefers, there could be a status meeting for the project team and a separate meeting
with the stakeholders. The meetings should be held weekly or bi-weekly, and kept to no more
than one hour.
• Status Reports from Team Members to Project Manager: The project team members should
report status weekly or bi-weekly to the project manager. This is in addition to the status
meeting.
• Status Reports to Project Sponsor/Steering Committee: There should be a formal status report
sent from the project manager to the project sponsor/steering committee on a monthly basis,
including financial information about the project.
Large Projects
In a large project, all communications must be incorporated into the overall communications
strategy. Status meetings and status reporting are required, just as for a medium size project. In
addition, there are many other types of proactive communication that should be considered.
Page 15
The project team should brainstorm on how to fulfill the communication needs, determine the
effort required to create and distribute each of the identified communication options, and
determine what the potential benefit of the communication is. The options should be prioritized,
and those that require high effort for marginal benefit should be discarded. Also, discard those
that provide marginal benefit, even though they may take little effort from the project team.
Implement the communication options that provide high value and require low effort from the
project team.
2.4.1.1 Status Reporting

Status reporting involves collecting and disseminating performance information in
order to provide management and sponsor with information about how resources are
being used to achieve project objectives. How status reporting is to be carried out for
the project is defined in the project team’s communication plan. Once the project is
underway collecting performance information involves gathering and analyzing
information about the project (i.e. what deliverables are complete, how much time
and dollars have been spent, how much change has occurred, etc). This type of
information comes from work results – what deliverables are fully and partially
complete, what costs have been incurred or committed, etc, and other project records
such as the schedule, issue log, change control log, risk log, quality control review
recommendations, and training log.
The collected information can be disseminated by creating a project status report. The
purpose of a project status report is to develop a standard format for the formal
exchange of information on the progress of the project. The project status report could
be tailored to the individual project and should be in the same format throughout the
project.
OIS has developed status report templates which can be modified to fit the project,
and attached to the Project Plan.
2.4.2 Issue Management Plan

The purpose of an issue management plan is to is to outline the recommended approach for
identifying outstanding issues, tracking the progress of the resolution, and documenting the
solutions. An issue is defined as a situation, action, concern, question, or problem that could
impact or impede the progress/success of a project. Issues are identified in the form of questions,
problems, or suggestions raised by the project team, management, contractor, or stakeholders.
They can often affect the status of tasks or deliverables, which would result in changes to cost
and schedule.
All members of the project team have responsibility for raising and investigating issues. Project
managers have primary responsibility for screening issues and determining if a solution can be
reached before creating a formal issue.
The level of management involvement in the resolution approval process will be specified in the
Issue Management Plan. Depending on the level of authority needed, resolution may come from
OIS management, the project sponsor, or an oversight or steering committee.
Page 16
OIS has developed issue paper procedures, an issue form, and an issue log. These procedures
and forms can be modified to fit the project, and attached to the Project Plan.
2.4.3 Change Control Plan

The purpose of a change control plan is to insure the following occurs:
• Only necessary changes are made,

• Changes are communicated to all affected parties, and
• Changes are implemented in an orderly fashion.
Change is a reality in any project situation. It would be unwise, if not impossible, to proceed
with any project without recognizing, accepting and preparing for the possibility of change. The
basic idea is not to prevent change, but to control it. Project change control is used to identify,
evaluate and adopt changes in order to manage the impact to the project plan, budget, and
implementation schedule.
Some changes will be unavoidable – instances where changes have to be made to comply with
legal, federal / state regulations, policy changes, compliance with changes in business direction,
or where technology may dictate change. Other non-essential changes can be avoided through
management of a formal change control process.
A change control plan and procedures should be used to assess, track and manage changes. If
changes are not controlled, the project schedule and budget will be destroyed before the project
manager recognizes anything has happened. A well thought out change control plan will assist
the project manager and team in controlling “scope creep”. Scope creep is the extension of the
project scope caused by unapproved and unmanaged changes that impact the cost, quality, and/or
timing of the project
In developing a change control plan to deal with change requests in an efficient, timely manner,
the project manager should:
• Establish change approval criteria for the project. This involves establishing the boundaries
at which a change request gets escalated to higher management for the final decision.
• Name the person(s) responsible for change request review (i.e. individual team members,
the project manager or a change review team) based on the change approval criteria.
• Establish a required turn-around time for review.
Depending on project size and complexity, a change review committee may be established to
evaluate change requests. On a small project, the project manager may review and approve
change requests. On larger complex projects, a review committee may be more appropriate.
If appropriate, a change review committee should be made up of a cross selection of team

members. Review committee members should be selected who have the expertise to truly
assess the impact of the change request on the project’s scope.
Page 17
A set turnaround time should be established for the review process from submission to
acceptance or rejection. This ensures that an “approved” change, along with the appropriate
activities or tasks, is entered into the work plan in a timely manner.
Depending upon project specifics, and the size and structure of the project team, review
activities can be undertaken as a separate step, or can be combined with the related activities for
approval/rejection. A separation of review and disposition tasks can serve as a project "check
and balance", whereby one individual (or group) has responsibility for assessing and
recommending change action, and another individual (or group) has responsibility for actual
approval or rejection.
Whether one process is used, or separate steps are followed, change disposition should address
the following:
• Establish the required turn-around time for change request approval or rejection.
• Name the person(s) responsible for change request approval (i.e. the project manager or a
change review team) based on the change approval criteria.
The above information makes up a change control plan for the project. OIS has developed
project change control procedures, a change request form, and a change control log which can be
modified to fit the project, and attached to the Project Plan.
Page 18
2.4.3.1 Identifying Changes

Any project stakeholder or team member can identify a potential change request. In
order to manage changes, the project manager must be able to recognize the many
forms a change can take, and be able to implement the necessary actions to control
them. Some examples of how changes can get introduced into a project:
• Overt client requests. These are the easiest to identify. The client makes a formal
request for an additional function to be incorporated into the product.
• Covert client requests. These changes sneak in when the project manager isn’t
looking. Someone on the client team makes an informal request of someone on the
project team (e.g., one more report, one more inquiry view, or a new area of
functionality).
• Smuggled requirements. These changes need a sharp ear to catch. The changes
are introduced as part of normal information gathering / status reporting processes
and usually reflect overlapping areas of the project. “For example, your team is
conducting a workshop to determine detailed requirements for a purchasing system
and among the requirements discussed is a set of requirements for calculating
vendor payables. The scope of purchasing has just been expanded to encompass
accounts payable.”
• Project team enthusiasm (design changes). These changes represent the
“Wouldn’t it be nice if….” things or functions introduced by the enthusiasm of the
project team that involve “over design”, “over build”, or unapproved testing of new
design techniques.
• Problems. These changes are the result of problem resolutions that identify a non-
compliance to the business functional requirements or the detailed design
document.
• Issues. Issues will be created during the entire project life cycle. Issues must be
reviewed, estimated, and approved by management. Some issues may result in a
change request, while other issues may be deferred to future releases, or rejected
outright.
2.4.3.2 Reviewing and Evaluating Changes

Once change requests are submitted and documented, they have to be reviewed to
assess value, timing, cost and impact. The bottom line to every change request is that
it adds additional overhead to the project. Sometimes, the time required to perform the
analysis will cause deliverable dates to slip. If this is the case, the request should be
escalated to the proper authority to determine whether the request should be
investigated or not.
The number one consideration as the proposed change request is evaluated is:
“What effect will this change have on the project’s outcome?”
To understand this question fully, an analysis must be conducted to understand the

pressure the change will exert on the project, and to clarify how the change will affect
later tasks and milestones. The following considerations are helpful in evaluating a
Page 19
change request, determining its impact on the project, and making a recommendation
for its resolution:
• Impact of the proposed change on the project schedule.

• Impact of the proposed change on the project budget.
• Risk levels of the proposed change.
• Is it necessary in this release of the product or can it be delayed?
• Is there a more effective and preferred change to the one proposed?
• Is there an alternative way of handling the change request that would not impact
the project? (Look for alternatives, tasks that can be deleted or shortened, or
dollars that can be moved around in the project.)
• Skill level of personnel required to complete the proposed change.
• Does the proposed change require project rework?
• How and when can the change best be made with the least negative impact to the
project?
• Does the proposed change require additional resources (e.g., computer time,
materials, tools, people, and technology)?
It is imperative that all areas of the project (e.g., additional project management time,
quality assurance, testing, documentation, contingency planning, risk management) be
assessed when defining the true impact of the change request to the project.
2.4.3.3 Communicating Change

Change control procedures and standards are only part of the picture. To effectively
manage project change, the project manager will also need to sharpen communication
and negotiation skills. In the event a change request is denied, the project manager
must be able to communicate and justify that decision. In the event resistance is
encountered, a compromise will probably need to be negotiated. And, on the flip side,
should an approved change result in unexpected negative consequences, the approval
decision must be justified.
2.4.4 Risk Management Plan

‘Risk’ refers to any factor that may potentially interfere with the successful completion of a
project. In other words, a risk is a potential future problem that has not yet occurred. A reactive
project manager resolves problems when they occur. A proactive project manager tries to resolve
potential problems (risks) before they occur. Risk management is a continual process of timely
risk identification, accurate risk assessment, and effective risk mitigation.
The purpose of a risk management plan is to ensure that each risk identified is documented,
prioritized, and mitigated whenever possible by documenting the activities used to manage risks.
The risk management plan identifies the initial top risks associated with the project and the
mechanics of integrating risk management throughout the project. Effective risk management
provides the following value to the project:
• Ensures key threats are adequately addressed and responded to.

• Prevents threats from adversely affecting the project.
Page 20
• Facilitates timely communication of risk information.
The process to be used to manage project risks is defined in the planning stage, documented in
the Project Plan, and then executed throughout the life of the project. The use of a formal
process helps identify risks early in the project and incorporate actions that reduce the negative
impact to the project.
The activities used to manage risk are described in this section. OIS has developed risk
management procedures, a risk assessment and planning form, and a risk management log. The
procedures and forms can be modified to fit the project, and attached to the Project Plan.
The following sections explain each of the key elements of a risk management process.
2.4.4.1 Risk Identification

Risk identification consists of determining risks that are likely to affect the project and
documenting the characteristics of those risks. Risk identification can be accomplished
by identifying causes and effects (what could happen), or effect and causes (what
outcomes are to be avoided). Don’t try to identify all possible risks that might affect
the project, but focus on those likely to affect the project’s success.
All members of the project team can identify risk, but the project manager has overall
responsibility. Sometimes a risk identification “brainstorming” session can help in the
initial identification process. Such meetings help team members understand various
perspectives and can help the team members better understand the “big picture.”
When identifying risks, consider the nature and complexity of the project, and classify
each risk into one of the following categories.
• Management Risks - Risks that relate to the scope, structure and strategy of a
project. Some examples of management risks:
o The scope and complexity of the project is too large.
o Project requirements and outcomes are poorly defined.
o Poorly defined or understood roles and responsibilities.
o The project does not have effective sponsorship or management support.
• Technology Risks - Specific technical risks including design omissions, version

conflicts, operational failures, incompatibilities or bugs. Some examples of
technology risks:
o Potential incompatibilities exist within current desktop platforms or internally
customized applications.
o Outdated or insufficient hardware exists for running new software products.
o Early adopter's risk - early adoption of new technology will limit the ability to
benefit from the experiences of others.
• Resource Risks - Human resource risks can involve staff changes, a lack of skilled
resources, staff non-performance, or the reliability and availability of external
service providers. Some examples of resource risks:
Page 21
o Continual resource availability may be compromised during lengthy projects.

o The loss of key staff to competitors or vendors may occur once they are trained
in new products or technologies.
o Insufficiently skilled staff.
• Timing Risks - Timing and scheduling risks can include product delivery delays, or
missed deadlines along the critical path. An example of a timing risk is an overly
aggressive project schedule that may limit the execution of thorough test plans.
• Political Risks - Political risks are internal sensitivities relating to project support,
sponsorship, internal cooperation and communications. Some examples of political
risks:
o The project is dependent upon one individual for visibility and support, and that
person leaves.
o Political issues that negatively impact resource availability and cooperation.
o Competing projects within OIS.
o Pending organizational changes that impact the project.
Risk identification begins in the early planning phase of the project, but is not a one
time event. It should be performed on a regular basis throughout the project. At the end
of the planning stage, the result should be a risk identification summary of known
project risks. This list is a roadmap to the next step, analyzing and assessing the
impact of these risks.
2.4.4.2 Risk Assessment

Once risks have been identified and categorized, they must be assessed to determine
the probability of occurring, and the potential impact to the project should the risk
occur. To determine impact, consider the following questions:
• can this risk affect the quality of my product or project end-result?

• can this risk affect project budgets and costs?
• can this risk affect the project schedule?
• can this risk affect the project planning and management process?
• can this risk affect the stability of project work environment?
Once the probability of occurring, and the potential impact to the project is assessed,
each risk should be assigned a high, medium, or low overall risk level. The following
table can be used as a guide in assigning the overall risk level:
Risk Factors Overall Risk Level

High negative impact to project / Highly likely to occur High
High negative impact to project / Medium likely to occur High
High negative impact to project / Not likely to occur Medium / Low
Medium negative impact to project / Highly likely to occur Medium
Medium negative impact to project / Medium likely to occur Medium / Low
Page 22
Medium negative impact to project / Not likely to occur Low

Low negative impact to project / Highly likely to occur Low
Low negative impact to project / Medium likely to occur Low
Low negative impact to project / Not likely to occur Low
For additional help in determining project risks and probability, see Appendix A:
Project Risk Factors. The results shown should be used as guidelines, since there will
be other factors that may lower or raise the risk level. For instance, you may have a
large project, which implies higher risk. This risk could be reduced if the project
manager is experienced. Depending on where project characteristics fall, you can
evaluate whether your risk is high, medium or low. (Medium risks fall in between the
extremes.)
2.4.4.3 Risk Planning

After completion of the risk assessment process, the next step is the formation of
specific strategies for the management and control of certain risks. These strategies can
include acceptance, avoidance or mitigation.
o Acceptance is when you acknowledge the risk, but decide that any actions to avoid
or mitigate the risk are too costly or time consuming, or the risk is beyond the
control of the project (these are typically political or legislative). It may just be
possible the risk cannot be avoided or mitigated in any meaningful way, and the
benefits of the project far outweigh the risks. Contingency planning may be the
only cost-effective and feasible response to the risk.
o Avoidance/Mitigation: Avoidance is when you take steps to eliminate the risk in its
entirety. Depending upon the circumstances, you may need to change project
scope, modify project plans, assign additional resources, or adopt different
technical solutions. Avoidance can be costly, but it may be the only way to achieve
project deliverables. Mitigation is when you seek to minimize the potential impact
of any given risk through the analysis and consideration of alternative solutions. In
essence, this is a combination of acceptance and avoidance. You can alter plans
and schedules, and take specific actions to minimize the chance that a risk will
occur.
As a guideline, risk planning activities should be included for each high-level risk.
After the high-level risks have been evaluated, look at the medium-level risks to
determine if the impact is severe enough that they should also have risk planning
activities. Then look at any low-level risk items, and see whether they should be listed
as assumptions. In this way a potential for problems can be recognized, but because the
risk is low, it can be assumed the condition will not occur. The activities associated
with managing the various risks should then be moved to the project work plan.
For certain risks, contingency plans should be developed. Contingency plans are pre-
defined action plans that can be implemented if identified risks actually occur "i.e. if
this happens, I will do that, but until then, I will stick with the original plan".
Page 23
Contingency plans attempt to minimize the effects of the risk assuming the event does
occur. If a contingency plan is appropriate for the risk, a trigger mechanism should be
identified that indicates when the contingency plan should be initiated.
While mitigating strategies provide the best of both worlds, that benefit cannot be
realized without some expense in terms of time, equipment and staff resources. See
Appendix B: Risk Management Strategy Table to see high-risk factors and
examples of problems that may be encountered. The second column shows examples
of activities that can help mitigate the risk.
2.4.4.4 Risk Monitoring and Control

The risk management process is an ongoing effort that lives throughout the entire
project cycle. Risk monitoring and control during project execution is discussed
further in Section 3.0 of this guide. However, it is important for the project manager to
plan the project to include risk monitoring activities.
As the project progresses, risk once thought to be unlikely and insignificant can
suddenly become very likely and dangerous, and new risks can arise. For this reason,
potential risks must be continually monitored. Periodic risk reviews should be
conducted as often as practical and whenever needed. The frequency of periodic risk
reviews should be addressed in the risk management procedures and should be suited
to project circumstances, overall project status, and resource demands.
A risk management tracking log should also be used to summarize all relevant risk
information. The project manager must maintain the log to ensure that the information
needed for effective risk monitoring and decision support is kept current.
2.4.5 Quality Management Plan

The purpose of quality management planning is to establish a process that will aid in ensuring a
project will satisfy the needs for which it was undertaken. Quality management is an ongoing
process that should be focused on throughout the project. It addresses both quality assurance
(QA) and quality control (QC)practices. The goal is to build the deliverables with as few errors
as possible, and then to find and correct any remaining errors as early as possible. Quality
should be planned into the project as opposed to auditing it into the project. Quality activities
should be included in the project work plan.
Quality processes should be continually improved to eliminate the potential for defects and
rework within a project. Rework refers to having to do the same work twice because the original
effort was not satisfactory. It is often the result of not having rigorous quality processes in place.
Work resulting from component walk-throughs or peer reviews is not considered rework, since it
is part of building the component the first time. However, if there are subsequent errors when a
component is tied into the larger application, rework is required. This is work that is required
because the original construction and testing process was not thorough enough and errors still
existed in the deliverable.
The benefits of effective quality management include:
Page 24
• Higher productivity and less rework whereby deliverables are produced on-time with less
effort due to minimal errors and rework. Projects with poor quality management tend to miss
their deadlines and exceed their budget.
• Increased customer satisfaction through fewer system defects and higher quality service.
• Higher team morale results from smooth running development processes and low
incidences of errors and rework. The team’s motivation level goes down when it has to
continually repair and rework deliverables and deadlines are being missed.
• Less demand on the Help Desk and support staff due to fewer problems being reported.
Quality Management Plans should be developed for larger projects to guide the overall quality
management process. Smaller projects will not require a “unique” quality plan, but may be
completed under standard processes (i.e. standard OIS and team processes).
OIS has developed standard quality assurance review procedures and audit and interview
checklists. The procedures are followed by an independent QA team who may modify the audit
and interview checklists to fit the project.
The following sections describe the key considerations in quality management planning.
2.4.5.1 Quality Control

Quality control refers to the activities the project team will perform to ensure project
deliverables are of acceptable quality. Quality Control activities involve monitoring
and evaluating the products and processes to determine if the project is following
quality standards as well as identifying and implementing ways to eliminate causes of
unsatisfactory results. Quality control is conducted continually throughout a project by
the project manager and team members. Though the project manager has overall
responsibility for the quality of the final product, every team member needs to buy-in
to the responsibility of producing a quality product.
The following quality control techniques may be used to help ensure consistency of
processes and quality of deliverables:
• Testing Strategy describes the approach for each of the testing types to be
considered (may include unit, systems integration, back-up/recovery, interface,
user acceptance, conversion, security, volume/stress testing and parallel testing).
• Requirements tracing. This may include tracing system requirements through
project objectives, RFP, statement of work, requirements definition, conceptual
design, detailed design specifications, code and test plans to ensure requirements
are being met.
• Stakeholder surveys and focus groups. These may be used to obtain information
on customer needs and satisfaction.
• Prototyping. Involves developing a mock up of deliverables so that stakeholder
feedback can be obtained early in the project. Prototyping may help to reduce
change requests later in the project. A prototype is more interactive than a written
description and is more likely to stimulate thoughts about how stakeholders would
like the system to ultimately work. In addition, customer satisfaction may be
higher since the actual deliverable may be more in alignment with expectations.
Page 25
• Storyboarding. Provides simulations of what the end result might look like.
These may be electronic or paper. The customer may be walked through each view
a step at a time while the system is described by the project team. This method
works well for website development where there will be lots of visual content.
Again, the visual presentation assists in generating customer feedback early in the
project.
• Walkthroughs and peer reviews. Reviews should verify adherence to standards,
specifications and quality control processes. This could include reviews of
deliverables such as designs, code, testing and user documentation.
• Checklists. This should include checklists to verify that all parts of a process have
been completed.
• Structured methods to help ensure proven processes are used.
2.4.5.2 Quality Assurance

Quality Assurance ensures there is a good quality program in place and that it is being
followed. It provides oversight for a project’s quality program and identifies processes
that a project should follow to ensure customer requirements are met. QA reviews are
conducted by independent QA teams. They will identify deficiencies and will
recommend adjustments to project activities or tasks to help ensure the project satisfies
relevant quality standards. The QA team examines:
• Processes being followed to create project deliverables.

• Project deliverables and documentation. A QA review may not be able to verify
if the content of a deliverable is acceptable, but they should be able to assess
whether a deliverable seems acceptable based on the processes used to create it.
Project documents should be examined to assess whether appropriate information
has been completed, and if it appears work has been performed to a sufficient
depth.
2.4.5.3 Project Classifications

The following project classifications provide guidelines that can be used in
determining quality management practices to be followed:
Small Projects
Small projects should concentrate on quality control since these projects are not
usually active long enough for a QA review to make recommendations on the
processes being used. These projects should:
• Identify quality control activities.
• Utilize pre-existing OIS and team processes (standards/procedures/guidelines)
whenever possible. Some new ones may also need to be developed.
• Include basic quality control activities in the work plan including walkthroughs and
reviews.
• Get the customers involved in testing as early as possible.
Page 26
• Notify the IT management consultant upon project completion so that a Post

Implementation Review can be conducted. This may be the only QA conducted for
a small project.
Medium Projects
Medium projects should be concerned with quality control and quality assurance.
These projects should:
• Develop a basic Quality Management Plan which identifies quality control and
quality assurance activities.
• Utilize pre-existing OIS and team processes (standards/procedures/guidelines)
whenever possible. Some new ones may also need to be developed.
• Include quality control and quality assurance activities in the work plan.
• Follow the OIS QA Review Procedure to request a minimal number of QAs (2 - 3
QAs).
Large Projects
Large projects should include more detailed quality control and quality assurance
processes. These projects should:
• Develop a comprehensive Quality Management Plan which identifies quality

control and quality assurance activities including acceptance criteria for major
deliverables.
• Develop or customize team checklists and procedures to fit the needs of the project
as appropriate. Formal sign-off and acceptance procedures for vendor deliverables
should be utilized.
• Include quality control and quality assurance activities in the work plan.
• Follow the OIS QA Review Procedure to conduct relevant QAs (typically 4 –5
QAs).
• Preliminary Design QAs should be conducted on projects whose design phase is
longer than 3 months to check the project progress when the design is about 25-
50% complete. A customized checklist should be developed by the QA team for
this review using pertinent questions from the Design QA checklist.
• Preliminary Development QAs should be conducted on projects whose
development phase is longer than 3 months to check the project progress when the
development is about 25-50% complete. A customized checklist should be
developed by the QA team for this review using pertinent questions from the
Development QA checklist.
• Gather project development metrics and analyze them for process improvements.
This may include metrics on the amount of rework performed, time spent on issue
resolution, number of errors discovered during testing, response time, and customer
satisfaction surveys.
Page 27
2.4.6 Training Plans

A comprehensive training effort is necessary for a smooth and successful implementation of
information technology projects. The key to ensuring adequate training is provided is to develop
a training plan which documents the training needs and approach planned for the project team
members, end users, and support teams. Just as with the Communication Plan, the training needs
of all people that will be affected by the project must be addressed. The project manager must
make sure team members, stakeholders, end users, and post implementation support teams have
the training needed to do their jobs.
2.4.6.1 Project Team Training

It is important to the success of a project that all functional and technical team
members have the skills necessary to successfully complete the tasks assigned to
them. The project manager should assess the skills that team members possess and
identify areas where training is needed.
The objective of a project team training plan is to identify the team members that
need training, and document when the training is needed in order to complete project
tasks. The primary goal of the project team training plan is to address training for
both technical and functional staff designed to:
• Accelerate the team’s ability to effectively communicate using relevant terms and
concepts.
• Provide the project team with the functional and technical skills necessary for
project development.
• Provide a level of knowledge to the project team to enable State staff to develop
and deliver end-user training.
• If applicable, provide for training by contractor.
• Prepare State staff to assume responsibility for continued support after
implementation.
The project team training plan should describe the types of training that will be
provided including on-the-job training, vendor or state courses, knowledge transfer,
etc., and the training requirements for each team member. In addition, back-up
personnel for key roles should also be identified and trained. It is very important
during planning to identify the persons who will be responsible for developing or
obtaining training materials, and conducting project team training. This will allow all
required project resources to be properly allocated at the times needed, or for any
resource conflicts to be addressed.
2.4.6.2 End User and Support Team Training

The overall approach for training end users and support teams should be addressed
during project planning. It may only be high level information, but it should identify
target groups, estimates of the number of users in those target groups to be trained,
the training those groups need, and the types of training available or to be developed
for the target groups. It is also important at this time in the process to identify the
Page 28
resource requirements for developing the training materials, and conducting end user
training, and for the project manager to address any resource conflicts that may occur.
During the Execution and Control phase of the project, when more details become
known about training requirements, the end user training plan should be more fully
developed to include how training will be executed as well as a schedule as to when
the training will be deployed.
2.4.7 Document Management

Proper documentation is critical to a project’s success. It can serve to illustrate the life of a
project, and can help manage the burden of risks by storing facts for future reference. Document
management is the management of all work products and deliverables associated with a project.
The purpose of a document management plan is to describe where documents are created and
stored, including setting up the electronic and or hardcopy project files and supporting
procedures. If the project manager does not think about these processes ahead of time, the
project team will have problems finding relevant information.
At the start of a project, the project manager may only have a high-level view of the required
deliverables, so it may not be possible to structure a repository in detail. Following the detailed
planning phase, the project manager will be in a better position to decide which documents
would help drive the project through to a successful conclusion, and set up a logical file
repository to capture those documents.
A formal Documentation Management Plan is currently not a requirement of the Project Plan.
The information contained in this section is intended to provide the project manager with
guidelines for managing and controlling project documentation to ensure that it provides an
efficient way of sharing knowledge and information among the project team members. The
project manager is responsible for communicating his/her expectations for documentation
management to the team in a format to be determined by the project manager based on the size
and complexity of the project.
When the FileNet document management software is fully implemented, the software may
facilitate and resolve many of these issues.
Small Projects
Although small projects have fewer problems managing documents, some of the processes and
infrastructure for managing documents may still be relevant. For instance, even a small project
will need a common repository or directory structure to store project deliverables. Other aspects
of document management, such as common naming conventions, might make sense depending
on how many documents are generated. Each project manager can evaluate their own project to
see which document management areas make sense to define.
Medium / Large Projects

The larger the project, the more rigor and structure is needed to manage documents. You can end
up with a big mess trying to save and find documents if you do not think through a good
document management plan ahead of time.
Page 29
The document management plan should address all or part of the following, depending on the
size of project.
2.4.7.1 Document Repository

Specify where the project documents will be stored. The project team should have a
common area for storing documents. This could be the G: drive, FileNet, and paper
file cabinet, etc. The project manager should be sure that documents are not stored all
over based on the preference of each team member. If that happens, the team will
have difficulty finding important documents when they are needed, especially if there
is turnover among members of the team.
2.4.7.2 Access Rules

The access rules describe things like who can review documents and who can update
them. Most documents should be accessible for the entire team to read. However, you
should be clear on which documents team members can update. For instance, you
could set up a folder for final, approved document that no one should touch. You can
also establish work folders for each team member where they can put all their
personal documents, as well as project deliverables that are in-progress.
2.4.7.3 Logical / Physical Organization

Once you know where you will store documents, you should also determine the
directory or folder structure. This is so the team members know where documents
should be stored and so the team can find documents when they are needed. The first
step is to define a logical view of how the documents should be organized. Once you
have agreement on this view, you need to implement it in the specific directory
structure or tool. The structure should be one that is easy to understand and easy to
use to find relevant information.
2.4.7.4 Naming Standards

It can be hard to find documents even if you have a good organizational structure. A
common document naming standard will make it easier to find information. For
instance, within a status report folder, the naming convention might be '20031201 Joe
Smith Status Report'. In this scheme, all the status reports for a given period would
sort together. On the other hand 'Joe Smith 20031201 Status Report' groups the
reports by person. Although this exercise might seem tedious, having a common
naming standard for related documents will be very valuable as your project team
generates hundreds of documents over time.
2.4.7.5 Versioning
The project manager should determine whether multiple versions of documents will
be saved or if just the latest version will be saved. Some documents should have all
approved versions saved. For these documents, the naming convention will need
some type of version number. For instance the original document might be named
'ABC Project Plan v 1'. The document name would be changed to ‘ABC Project Plan
Page 30
v 2’ if it is revised at a later time. People can then still refer back to the prior versions
if necessary. On the other hand, documents such as the Issues Log have all current
and prior issues saved within the document. The current issues log always replaces
the prior issues log, and there is no reason to keep separate versions.
2.4.8 Project Plan Summary and Sign-Off

The Project Plan is a formal project document constructed by the project manager, sponsor,
stakeholders, and project team members with the expressed purpose of controlling the execution
of the project. The amount of time spent on the planning process should be in direct proportion to
the potential expense of mistakes due to lack of planning. The Project Plan should be reviewed
and approved by “key management” (those persons determined to be necessary for approval of
the plan). Once approved, whenever significant changes are made to the schedule, quality, scope,
or any of the project management plans, the Project Plan should be updated as necessary.
Page 31
3.0 PROJECT EXECUTION & CONTROL

The project execution and control phase is that part of a project which utilizes the schedules, plans,
procedures and forms developed during project planning. The phase begins when the project plan is
approved, and the resources necessary for executing the starting task are assembled. The project
manager and team’s focus shifts from planning the project’s efforts to participating in, observing, and
analyzing the work being done.
Executing the project consists of carrying out tasks, measuring project progress, reporting project status,
and exercising management controls to ensure that planned project activities are carried out in an
effective and efficient way.
Controlling the project requires the measurement of project performance, monitoring project risks, and
controlling change to the project baseline. Controls outlined in the project plan keep the project on
schedule, in scope, and within budget. For this reason the control plans include the procedures and
forms the project has agreed to use. As the project proceeds, the responsibility of the project team is to
review progress against the milestones and goals defined in the project plan.
The project plans with their controls are used as the basis for tracking and managing project activities,
communicating status, and if appropriate, revising plans. Progress is primarily determined by
comparing the scope, effort, cost, and schedule to the plan when selected work products are completed
or at selected milestones. When it is determined that the project's plans are not being met, the project
management team should determine the best course of action. This may include revising the project plan
to reflect the actual accomplishments and re-planning the remaining work, or taking actions to improve
the performance.
The processes of executing, controlling, and planning are continuous activities. During execution, the
project team must continuously monitor its performance in relation to the project plan. By measuring
and evaluating the actual execution of project activities against the plan, the project team and
stakeholders can gauge the progress of the project. It is also critical during the project execution that the
project manager manage the project work plan and support and monitor the execution of the project
management plans (Communications, Issue, Change Control, Risk, Quality and Training Plans). The
critical elements of execution and control for the project team are:
• Track and monitor project activities to measure actual performance to planned performance
• Review and communicate status and future actions
• Monitor and mitigate potential risks
• Execute the change management process to control changes to the project’s scope
• Execute the issue tracking process to ensure issues are addressed in a timely fashion and track plans
to correct an issue that impacts the plan.
Following a description of the execution and control of each of the project management plans, other
aspects of project execution will be briefly explained. There are currently no templates for the various
plans discussed, but as standard templates are developed, they will be made available.
Page 32
3.1 Kick-Off Meeting

Moving from planning into execution can be a major obstacle in a successful project. A project kick off
meeting can facilitate the transition from planning activities and tasks to executing them. A kick off
meeting enhances execution by focusing the team on the project and by defining a starting point for
project execution. Additionally, it is a milestone when all resources needed to begin execution are
assembled and available to the team.
A kick-off meeting can also provide an opportunity for establishing the commitment of the team and
stakeholders to the success of the project. The focus of the meeting should be communications,
identification of team members and stakeholders, reviewing the project scope and business objectives,
identifying the challenges, and identifying the next step in getting the project underway.
3.2 Manage the Project Work Plan

The baseline project work plan is used as a starting point against which performance on the project is
measured. Responsibilities of the project manager include maintaining a work plan in Excel or
Microsoft Project that minimizes team member down time. The project manager is responsible for
allocating tasks to appropriate team members at the appropriate times to ensure that the work is
completed according to the schedule. Feedback from project team members is used to track work done
against the tasks in the work plan. If the time remaining to complete a task in the work plan differs from
the estimated time, the work plan should be updated accordingly. It is recommended the project manager
update the project work plan on a regular basis. Frequent updates to the work plan not only save time in
the long run, they also allow the project manager to quickly spot potential problem areas.
Once the initial work plan is established, the critical path of the project should be determined. The
critical path is the path with activities that cannot be delayed or the project finish date will be delayed,
unless the time can be offset somewhere else on the critical path. If using Microsoft Project, the critical
path of the project will be automatically calculated. Management of the critical path is important to the
success of the project. The project manager must take a proactive approach to managing the resources
on the critical path as well as those activities that might have an indirect effect on critical path activities.
After updating the work plan, the project manager should be able to answer some of the following
questions:
• Is the project on track?

• Are there any issues that are becoming evident that need to be addressed now?
• Which tasks are taking more time than estimated? Less time?
• If a task is late, what is the effect on subsequent tasks?
• What is the next deliverable to be produced and when is it scheduled to be complete?
• What is the amount of effort expended so far and how much is remaining?
• Are any project team members over-allocated or under-allocated?
• How much of the time allocated has been expended to date and what is the time required to complete
the project?
3.3 Execute the Communication Plan

The Project Team and End User Communication Plans describe how project communications will occur,
and the way communications will be managed. During project execution, the project manager and
Page 33
project team must review whether the Communication Plans are still current, complete, and applicable to
the project. If not, the project manager should update the plans.
During project execution, the Communication Plans are carried out so that required information is made
available to the appropriate individuals at the appropriate times, and new or unexpected requests receive
a prompt response. Communications must be bi-directional. The project manager must provide required
information to the project team and appropriate stakeholders on a timely basis, and the project team and
stakeholders must provide required information to the project manager. The project manager, project
team, and stakeholders will share information among themselves and with end users using the methods
defined in the Communication Plans.
While executing the plans, the project manager must be aware of how organizations will use the
information, and whether the plans are effective. He/she must be flexible and ready to modify the plans
if portions are not working as expected or communications needs change.
In addition to having solid Communication Plans in place, it is the responsibility of members of the
project team to exercise good communication skills. Project team members must use the
communications methods documented in the Communication Plans. When composing correspondence,
status reports, meeting agendas and minutes, etc., and when speaking with individuals face to face, team
members are responsible for clear, unambiguous, and complete communication of information. The
receiver, in turn, must be sure information is not only received correctly and completely, but that it is
understood.
A large part of a project manager’s responsibility during execution is keeping stakeholders informed of
project status by providing a report communicating the performance of a project. Joint project review
meetings are also a good way to bring visibility to all areas of the project. Joint project review meetings
may involve the project manager, project team members, project stakeholders, and agency management,
depending on the issues. They provide an opportunity to discuss important issues and make management
decisions on the project with input from several sources.
If the communication plan requires team members to prepare a status report, it would generally be used
by the project manager to update the project work plan. In lieu of a status report from each team
member, the project manager could periodically assemble the project team to review the status of the
project, discuss their accomplishments, and communicate any issues or concerns in an open, honest,
constructive forum. These meetings are ideal opportunities for the project manager to gain insight into
the day-to-day activities of project team members. The project manager could review the project work
plan with the team and verify with each member the work that needs to be accomplished in upcoming
weeks. The project manager can then use information communicated during the meetings as input for
the project status report. The regularly scheduled project team meeting is also a good forum to recognize
individual accomplishments for outstanding work.
The project manager must emphasize to the team the importance of accurate reporting in order to
complete a project status report which measures the “health and progress” of the project against the
Project Plan. It is the primary communication method between the project manager and the project
sponsor.
Page 34
3.4 Manage Issues

During project planning, the process for managing issues was agreed on and documented in the Project
Plan. During project execution and control, the Issue Management Plan and corresponding forms are
used to document, track, and resolve issues that occur as a project progresses.
The Issue Paper is the means of reporting issues and is used by the project team to document the issue,
assess the impact of the issue, and make recommendations to resolve the issue. Managers use the Issue
Paper to assign responsibility and to document decisions on actions directed to resolve the issue. The
Issues Log is the master record of identified issues and is used to track progress toward resolution.
Every issue, whether technical or business related, should be documented.
Anyone involved in a project in any way can and should inform the project manager of issues. It is the
responsibility of the project manager and executive leadership to foster an environment where
communicating issues is not only acceptable but strongly encouraged. Individuals should feel a
responsibility to the organization to voice their concerns. If individuals are fearful of communicating
issues, the resulting effect on the project can be devastating.
Once the description of a new issue has been logged, the estimate of the potential impact of the issue is
documented. Based upon potential impact, the issue is prioritized. The goal of issue management is to
resolve all concerns completely and promptly, but the issues with the highest priority should be
addressed first.
While an issue remains open, its continuing impact and the status of its action plan should be discussed
at every status meeting. If appropriate resources or materials are not available to complete the action
items, or if there is disagreement about any of the issue recommendations, the project manager should
invoke applicable escalation procedures. Unresolved issues are one of the leading causes of project
failure, and the project manager must pursue issue resolution relentlessly.
3.5 Manage Scope and Control Change

During project planning, an approved Project Charter and Project Plan established the scope of the
project, and documented the process for controlling change. It is important that the project manager
enforce the change control process throughout the entire project, starting very early in project execution
and control. Although changes can be expected to occur, if the change control process is executed and
managed effectively, any negative effect on the project outcome should be avoidable.
Adhering to the change process ensures that all parties agree to the change and understand its potential
impact. The change control process also helps maintain balance between the requirements of the project
and the timeline and cost. Following the change control procedure each and every time changes are
requested will test its effectiveness, get the customer and project sponsor accustomed to the way change
will be managed, and help them understand their roles as they relate to change.
The need for change is usually discovered during project execution, as actual task work is being
performed. During this time, the project team may discover their original effort estimates were not
accurate and will result in more or less effort being required to complete their work. It is also during
execution that the project sponsor or customer may realize that, despite their best efforts to thoroughly
document the project scope, the product being produced is not exactly what they need. It is the
Page 35
responsibility of the project manager to keep a close watch on factors that could introduce potential
“scope creep” and take proactive steps to prevent it from occurring, or to manage it as it occurs.
One of the roles of the project manager in executing the change control process is to assign an
individual(s) to analyze the request and determine the overall effect of the requested change on the
project work plan in terms of effort, cost, and resource requirements and availability. This information is
documented on the change request form.
The change request approver(s) review the information and make a determination whether to approve
the change request based upon the potential benefit of its implementation. If, for example, the
implementation costs far outweigh the business benefit, the change request will most likely be rejected.
A signature is required of all approvers, whether they are accepting, rejecting, or deferring the request. If
the resolution differs from the recommendation, the approver must provide a reason. A signature of
approval on the change request form indicates that the approver accepts the consequences (impact) of
the request on the project.
Once a change request has been approved, the project manager must incorporate the effect of the change
into the project work plan. All affected tasks, estimated durations, dependencies, and resources must be
modified. A new or interim baseline should then be created and will become the new version against
which hours will be booked and project performance measured.
Throughout project execution and control, continuous communication between the project manager,
project sponsor, and customer representatives is crucial in managing change.
3.6 Monitor and Control Risks

The purpose of the executing and controlling phase of risk management is to deploy the Risk
Management Plan for the top known risks, and to develop and apply new risk strategies to unexpected
events. During planning, the initial project risks were defined as accurately as possible in terms of their
probability of occurrence and their impact to the project. In the execution and control phase, risks
become more defined, and resolution strategies emerge, allowing for the development of a realistic risk
plan for each risk.
The risk process is not just about completing the Risk Assessment and Planning Form for each risk and
then forgetting about it. Since risk identification, monitoring, and resolution are key tools for
successfully completing the project, the project manager must continually look for new risks, reassess
old ones, and re-evaluate risk plans. Risk identification meetings should be held as a means of
identifying risks and developing ways to approach the risks. These are especially helpful on high-risk or
complex projects.
The project manager should involve the whole project team in risk identification meetings, as team
members have various levels of expertise and can bring a unique perspective to risk identification.
Meeting frequency is based on the size of the project and the “perception” of the project team and key
stakeholders as to the degree of risk that exists for the full project. The format for these meetings should
be open and interactive to facilitate a wide consideration of risk areas.
The starting point for these meetings is the risk management log. Additionally, some general areas
should be considered. The group should be given some ground rules in terms of the degree of risks that
Page 36
will be tracked and ways to eliminate or include risk items. Some criteria for risk tracking include time
frame (when it would possibly occur) and value (what would be the cost if it occurred). From this
meeting, the project manager will have an updated list of risks. The group assists in the process of
prioritizing the risks by determining the probability of their occurrence and the impact these risks could
have on the project.
Sooner or later, one of the events on the Risk Management Log, or an entirely new and unexpected risk
will actually occur. The project manager and project team members must evaluate the risk event and
invoke the risk plan for that risk. There are generally three possible response scenarios:
1. If the risk occurred as expected, the existing risk plan may be adequate for dealing with it.
2. If the risk occurred in a different manner, or other circumstances have come to bear, the risk plan
may have to be modified.
3. If the risk event was unexpected and unanticipated, a new risk plan must be created to address it.
Developing and constantly updating risk plans is the key to controlling risks. Having plans and
procedures in place to control risk events when they occur is critical to delivering projects on time and
within scope. There is no silver bullet for risk management on IT projects. Project managers must
devote themselves to identifying, planning for, and dealing with risk on a daily basis.
3.7 Implement Quality Management

Quality management activities are designed to ensure that the project team can produce high quality
deliverables. During the planning phase, the project manager decided what to do and how to do it in
order to produce a deliverable that meets the standards that have been set for it. The agreed on activities
were documented in the Project Plan. The quality management execution phase involves monitoring the
project and its progress to determine if the quality control activities defined in the Project Plan are being
implemented, and whether the project is driving toward its goal.
Quality control is sometimes seen as a step in the process, or a series of activities at the end of the
process. However, quality control cannot rely on “adding” quality at the end of a process. It must be
built into the work of each individual on the team. To be effective, the project team must adopt a
continuous quality mindset. Project team members need to take ownership of the deliverables they
produce and ensure the deliverables are built with quality. It is more cost effective to have project team
members add quality into their day-to-day jobs than to have a quality assurance team find a problem
after a process has been completed. If a particular deliverable has a quality problem, the project manager
and project team should focus on how the project work processes can be improved, not on trying to
determine who is to blame. Most problems with quality are the result of poor or insufficient work
processes. Team members must realize that a quality process allows the entire project team to produce
quality deliverables, with a minimal amount of errors and rework.
Quality control reviews are especially helpful for project managers since they may not have the time or
expertise required to validate whether all deliverables are complete, correct, and of high quality.
However, they can review the results of the quality control review of the processes used to create the
deliverables and determine if the processes are sound and reasonable.
Quality assurance (QA) reviews refer to validating the processes used to create deliverables. It
incorporates a process of evaluating project performance on a scheduled basis to provide confidence the
Page 37
project will satisfy the relevant project standards and meet scheduled timeframes. Accordingly, while it
is important that each team member be responsible for quality control, an independent QA team plays an
integral role in ensuring the quality plan is executed as designed by performing QA reviews. One of the
basic principles behind a QA review is to ensure that deviations from standards will not adversely affect
the project’s successful implementation. Discussions could include ideas about things that could go
wrong, what the likelihood is of that occurring, and what the project impact could be if something did go
wrong with the process.
As a result of implementing quality management, the project manager should be able to determine and
take the appropriate actions to improve the quality of deliverables and increase the project’s
effectiveness in providing better service to the customers.
3.8 Execute the Training Plans

In developing the Project Plan, the project manager evaluated the skills of each project team member to
determine whether he/she met the current and future needs of the project, and documented the
requirements in a Project Team Training Plan. For each team member requiring training, the project
manager included the type of training the team member needed, and the approximate date or timeframe
the training is needed in order to keep the project on track.
Also during project planning, if applicable, the project manager should have created a high-level End
User and Support Team Training Plan. This plan documents the activities and resources needed for
developing training materials and conducting end user and support team training, and would have been
used to document the known tasks and resources in the work plan.
During project execution, the project manager must review the contents of the training plans to be sure
they are still applicable. A common problem in many “time-challenged” projects is that reasonable
training was not provided for in the Project Plan. If additional training is necessary, it should be added
to the appropriate plan. If it is determined that planned training is no longer necessary, it must be
removed from the plans.
If new team members have joined the project since the Project Team Training Plan was established, the
project manager must evaluate the skill level of the new members to determine if additional training is
needed. As training takes place during project execution, the project manager may want to use a
training log for project team members to document the names and actual training completion dates.
It is also during this phase that the End User and Support Team Training Plan should become fully
detailed to include how training will be developed and executed as well as the timing of when the
training will be deployed. Managing the steps that need to be taken to ensure end users will be ready to
use the product and the support team can support the product once it is implemented should be
coordinated with all other aspects of the implementation of the product.
3.9 Manage Project Documentation

If a formal documentation plan was not developed during project planning, the project manager should
re-evaluate the amount of documentation that may be produced by the project, and determine whether a
formal documentation plan should be considered. Following is a list of project related documentation
that may or may not be applicable:
Page 38
Project Concept
Project Charter
Project Plan
• Work Plan
• Communication Plans
o Status Reports
o Meeting Agendas and Minutes
• Issue Management Plan
o Issue Procedures
o Issue Forms
o Issue Log
• Change Control Plan
o Change Control Procedures
o Change Request Forms
o Change Control Log
• Risk Management Plan
o Risk Management Procedures
o Risk Assessment and Planning Forms
o Risk Management Log
• Quality Management Plan
o Quality Assurance Audit Checklists and Interview Questionnaires
o Quality Assurance Reports
• Project Management Documentation Plan
• Training Plans
o Project Team Training Plan
o End User and Support Team Training Plan
o Training Log
Design Documentation
Requirements Definition Conversion Approach
Technical Architecture Design Testing Plan
Conceptual Design Organizational Change Management Plan
Proof of Concept or Prototype User Documentation Plan
Detail Design Specifications System Documentation Plan
Coding Approach
Development Documentation
Test Results • Quick Reference Cards
User Training Materials System Documentation
• Course Materials • System Administration Guide
• Tutorials • Technical Maintenance and Support
User Documentation Guide
• Guides
Pre-Implementation Documentation
Cutover Plan
Deployment Plan
Page 39
Production Support Plan

Disaster Recovery Plan
Correspondence
Memos
Minutes of Meetings
E-mails
If it is determined that a document management plan should be developed and executed for the project,
refer to Section 2.4.7 of this guide. At the very minimum, the project manager should have guidelines
describing where documents are stored and rules concerning responsibilities, authorities and controls.
As documents are generated during project execution, the project manager is ultimately responsible for
maintaining a project document repository. Control of documentation during the project should be made
as easy an efficient as possible. Project team members should be able to access, “check out”, update, and
“check in” documents. Stakeholders should be able to easily find and access documents. The project
manager should keep track of document status, paying close attention to:
• documents that are not at their planned stage of completion,

• completed work where the documents have not been finalized,
• documents that are unnecessarily checked out,
• competing demands for a document, and
• team members not working on the correct, controlled version of a document.
The project manager should monitor the overall process of managing the project’s documentation and
deal with issues as they arise.
3.10 Other Aspects of Project Execution
3.10.1 Manage the Project Team

Human resources are vital to project execution and as a project manager, success in leading a
team depends on leadership skills. A positive team environment enhances project performance.
Project team members must learn to work together to achieve project goals. They must recognize
that there is more to team-work than simply having team members feel good about each other.
The primary objective for establishing an appropriate team environment is to improve overall
project performance. When team members are encouraged to do their best and are motivated
about a project, they are more likely to do whatever is necessary to improve their individual
skills so they are more efficient and effective in performing their assigned activities. When team
members understand the importance of interacting with each other, they are more willing to
identify and proactively deal with conflict. Resolving issues early leaves team members more
time for producing actual project work.
Page 40
Highly effective project teams are either empowered to make decisions or are included in
decision-making processes. This is the essence of project ownership. Team members participate
in all required meetings, are willing to suppress their egos for the good of the group, take their
assigned tasks seriously, and continuously strive to improve their skills.
Following are some guidelines for proactively managing team performance:
• Define expectations and hold team accountable for meeting those expectations.
• Manage individual performance by interviewing a problem employee to try to determine the
cause of the problem and the solution. Encourage the employee to help in the resolution of
the problem.
• Determine how to best handle team performance issues such as a team pulling in different
directions.
• Discuss methods of handling an extended period of overtime requirements.
• Make sure feedback mechanisms are in place to promote early detection and resolution of
issues.
• Use facilitation and coaching techniques to involve team members in problem resolution.
• Address issues of team skill gaps and devise a plan to increase performance.
3.10.2 Manage Vendors

When the work on a project is partially or fully contracted with vendors, vendor relationships are
crucial, and it is important to review the following guidelines to prevent or resolve conflicts:
• Monitor contract performance and project deliverables to ensure requirements are being met.
• Ensure that status reporting occurs as predetermined and take appropriate corrective action
when variances are detected.
• Determine if the communication plan is working well between the vendor and the project
team. Interview team members to determine if there are any significant issues with the
vendor and find out from the vendor if there are any significant issues with the team.
• Determine when and how to address delays that impact the critical path.
3.10.3 Plan for Organizational Change

Organizational change is the impact the project will have on end users in terms of people and
processes. The goals of organizational change management include:
• building acceptance and ownership of the project across organizations and business units
• building commitment to the project
• selling the benefits of the project
• managing user expectations and information needs
• providing information about the project to impacted audiences and obtaining their input
• providing information on available support and resources
• reducing uncertainty and fear of new technology and processes
• ensuring that decisions, events and activities are communicated in a timely manner
Page 41
It is extremely important for the project manager to consider the impact the project will have on
the owner agency’s business processes and employee roles. With the implementation of a new
IT application, business processes may take advantage of streamlined workflows to reduce the
flow of paper, and employee work procedures would need to be redesigned to align with the
change. In cases where implementing a project will result in a significant change to the way an
agency conducts its business, the project manager must anticipate when and how the major
impacts will occur, and document the specific activities that will adequately prepare the owner
agency and end users to accept and use the product. In preparation for implementation, all
involved parties must be made aware of the anticipated timing of events to give them ample time
to prepare and participate as required.
The redesign of existing business processes affected by the implementation, and the development
of corresponding procedures, must be managed in coordination with project development. New
processes must be integrated during project development, to coincide with or precede the
implementation, as appropriate. Most likely, the activities needed will include communication,
education, and training events that can be targeted to specific audiences affected by the changes.
These activities should be documented in the communication and training plans, which should
reflect how information about the changes will be provided well in advance of implementation so
that affected stakeholders have ample opportunity to express their concerns. Plans must be
updated as necessary to reflect new requirements. To the greatest extent possible, key
stakeholders should be given a "preview" of how the product will actually work, and also be
given adequate training on how to adjust to change or how to work in the new environment.
The project manager must recognize and manage these particular aspects of the project with
diplomacy and tact. For large projects, a full-time person dedicated to organizational change
management may be required to fulfill the critical nature of this role. The active involvement of
the project sponsor may also be required for implementing organizational changes across
organizations and business units.
3.10.4 Plan for Implementation, Operational Transfer and Support

During project execution and control, the project team should develop a good understanding of
the impact the project will have on the support team(s). A support team is any key stakeholder
group whose employees are most directly involved in supporting the product, either in terms of
technical support or functional support (such as help desk and problem resolution). The project
manager should document the activities for implementing or deploying the project and for
transitioning the responsibility from the project team to the support team(s). These activities
should begin to prepare the support team(s) to support it. Planning for implementation and
operational support includes, but is not limited to:
• Monitoring design and implementation activities and making any necessary adjustments.
• Monitoring training activities and making any necessary adjustments.
• Managing the steps that need to be taken to ensure the appropriate individuals are ready to
support the product. This may include negotiating with various internal organizations to
determine the appropriate timing of the transition of responsibility, assigning specific
agencies or individuals to support the specific products, and providing necessary training.
Page 42
The project manager must carefully manage the development effort to know when the
support team should become involved in the project. The project manager takes
responsibility for production problems, "help" or trouble calls, and for resolving the
problems.
• Managing production of all necessary documentation. The project manager must ensure that
all documents or records that will be provided with the product are produced. Overall, the
project manager must be sure each required activity is carried out according to the schedule,
and to immediately communicate any discrepancies.
Page 43
4.0 PROJECT CLOSEOUT

Project Closeout is the last phase in the project lifecycle. The intent of this phase is to bring closure to
project activities and to formalize the end of the project. A flowchart of the project closeout process is
included in Appendix C.
During the closure phase, efforts should shift from deliverables and implementation to equally important
tasks and deliverables associated with successfully ending the project. The fact that project closure
appears at the end of the project does not mean all project closure activities must be delayed until then.
As project phases come to an end, it is important to conduct milestone reviews to ensure that phase
activities have been successfully completed to the satisfaction of all involved.
The main activities in the Project Closeout phase consists of the following processes:
• Prepare Project Closure Report

• Perform Administrative Closeout
The project manager is responsible for ensuring the closeout processes are carried out while the
developed systems are rolled over into maintenance mode. The major outcome of this phase is the
Project Closure Report. Even though it may be impossible to assess now how much future projects will
benefit from lessons learned and best practices, it is certain no one will benefit at all if the lessons
learned and best practices are not communicated and disseminated across the organization.
4.1 Prepare Project Closure Report

The following tasks are performed by the project manager, project team, and QA team for the purpose of
assessing the effectiveness of the project, and bringing closure to project activities. The project manager
is responsible for creating a Project Closure Report to formalize the end of the project. OIS has
developed a Project Closure Report template for this purpose.
4.1.1 Identify Lessons Learned from the Project Team

Lessons learned come from experience gained during a project and are gathered to help eliminate
the occurrence of the same problems in future projects. The project manager should meet with
all members of the project team and appropriate OIS managers to discuss all aspects of the
completed project, gain consensus on what was successful and what was not, and derive best
practices. Conducting a “lessons learned” session can be a valuable closure mechanism
regardless of the project's success. OIS has developed a Post Implementation Assessment
template to assist the project team in identifying processes that worked well, and processes that
could be improved. The assessment should be distributed prior to the session so team members
have ample time to prepare their comments or observations.
For a lessons learned session to be successful, the problems encountered must be openly
presented. Each person attending the session should contribute a comment or observation about
the project. Responsibility and ownership for problem areas are critical to developing useful
recommendations for future projects and processes, and it is important that problem discussions
do not merely point a finger at some target.
Page 44
4.1.2 Solicit Feedback from Primary User(s)

The most important measures of the success of a project are whether the product was developed
and delivered successfully, and how well the needs of the customers have been met. The most
effective way to determine these measures is to solicit feedback. As part of the quality assurance
process, the QA Team will conduct post implementation interviews designed to assess the
success of the project in meeting its goals and the customer’s needs. The findings of the QA
Team will be documented in a Post Implementation QA Report.
4.1.3 Prepare Project Closure Report

After the lessons learned session(s) and QA interviews are conducted, the project manager
prepares a Project Closure Report. The Project Closure Report documents the effectiveness of
the project and lessons learned and best practices to be used in future projects. It may also
contain recommendations for improvement to be used by other projects of similar size and scope.
The Post Implementation QA Report, and QA Response Memo if applicable, are attached to the
Project Closure Report.
4.2 Administrative Closeout

The purpose of an administrative closeout is to perform all the administrative tasks required to bring the
project to an official close.
4.2.1 Archive Documentation

Completing the documentation and archiving the project records is the least exciting part of
project closeout. However, once the project comes to an official close, a good repository
provides an audit trail documenting the history and evolution of the project. During project
closeout, the project manager should examine the repository to ensure that all relevant project-
related material, documents produced, decisions made, issues raised and correspondence
exchanged have been completed and properly stored.
4.2.2 Close Contract

Contract closure is the process of addressing all project related contracts to determine if there are
any outstanding contract issues that must be resolved, or if there are any contracts that need to be
officially brought to closure, such as for early contract completion. These contracts may have
provided technical support, consulting, or any number of services supplied during the project. In
order to close a contract, it is important to collect all of the pertinent documentation for review to
ensure there are no contract issues that could result in legal liability. A thorough review of the
contract documents should include contract milestones, services provided or deliverables,
documentation delivered, and any outstanding invoice or payment issues.
Approximately 60-100 days prior to the end of the contract, the project manager should review
the status of any contract to ensure the contractor is on target for completing all required services
and deliverables. If they are not going to complete on time, the project manager must determine
if a contract amendment (to extend the contract period) is warranted, or what contingencies to
perform in the event there is work left uncompleted.
Page 45
Within sixty days after completion of performance under a consulting contract, a formal
evaluation of contract performance and an assessment of the utility of the final product must be
documented on a Performance Evaluation Report.
4.2.3 Gain Project Acceptance and Sign-Off

Formal acceptance and sign-off of the Project Closure Report by the project sponsor is the
confirmation that all deliverables produced during project execution and control have been
completed, tested, and accepted, and that the project is essentially over.
4.2.4 Celebrate Project Completion

Rewarding success is an effective management tool, and it is important to recognize teams that
have successfully completed a project. When a project is completed, management may want to
formally express recognition of the team at a key meeting or a large gathering of staff. Such
recognition sets the stage for future successful work. There are also informal ways to celebrate
project completion such as an after work gathering, or a congratulatory cake to commemorate the
event.
Page 46
APPENDIX A: PROJECT RISK FACTORS
Medium
Characteristics Low Risk Risk High Risk
The business benefit of the project is: Well defined Poorly defined
The scope of the project is: Well defined Poorly defined
The project sponsor is: Identified, committed and enthusiastic Not identified or not enthusiastic
The business customer commitment level is: Passionate and enthusiastic Passive and hard to engage
The Project Manager has: Similar experience on multiple projects Little experience on similar projects
The project team is: Located together Dispersed at multiple sites
Project management processes and procedures are: Familiar and will be utilized Not familiar and will not be utilized
The business requirements of the project are: Understood and straightforward Very vague or very complex
The system availability requirements include: Windows of availability and downtime Available on a 24 X 7 basis
The technical requirements are: Similar to others in the company New and complex
The data requirements are: Simple Complex
The number of locations to deploy to is: One More than four
The number of system interfaces are: One or none More than five
The number of organizations this will impact is: One or two More than five
The total estimated effort hours are: Less than 1,000 hours Greater than 5000 hours
The total estimated project duration is: Less than three months Longer than one year
The subject matter is: Well known by the project team Not well known by the project team
The project is dependent on: Zero or one outside project or team Three or more outside teams or projects
Business processes, procedures, policies require: Little or no change Substantial change
Changes to the organizational structure require: Little or no change Substantial change
Existing software, hardware, languages, New software, hardware, languages, databases or
The technology being utilized consists of:
databases and tools. tools (or new releases)
The quality of current data is: Well defined and simple to convert Poor or complex to convert
No (or minimal) customization is needed Heavy customization is needed
If a package implementation: The product or release is stable The product or release is new to the market
The vendor is familiar in this market The vendor is new to this market
Page 47
APPENDIX B: RISK MANAGEMENT STRATEGY TABLE
High Risk Factors /

Risk Management Activities
Potential Problems
The business benefit of the project – Poorly defined Try to get business customer to quantify the overall business value of the project
Project is in jeopardy of being placed on-hold or cancelled if higher Look at the major requirements and try to quantify the value of the various deliverables
value work is identified Document the intangible benefit that the project will achieve
Harder to get resources required Review prior similar projects to see how the benefits were quantified
Hard to evaluate the value of the project to the organization Don’t start the project while the business value is undefined
Hard to define scope changes in terms of cost/benefit
Hard to know if business value was achieved when project is complete
The scope of the project – Poorly Defined Focus on firming up scope in the planning process
Hard to provide sound estimates Define various components of scope such as what organizations are impacted, what deliverables are
May spend time and cost on areas out of scope expected, what type of information is required
Hard to gather concise requirement Clearly define what is out of scope for the project
Difficult to write project definition and work plan Begin to define business requirements at a high level, and then work upward to define scope
Hard to invoke scope change procedures Ask project sponsor to make decision on conflicting scope statements
Project deliverables are poorly defined Document all scope assumptions when providing estimates of work, cost or duration
Use pictures or diagrams to communicate scope and options
Establish firm scope change procedures up front
Ensure the project definition and business requirements are formally approved and signed off
Distribute scope statements to all stakeholders for confirmation
Do not begin project until scope is clear
The project sponsor is – Not identified or not enthusiastic Establish a strong steering committee to help guide the project
Project may not get the resources it needs Establish a process for resolving disputes between organizations
Project may not have the long-term commitment needed Try to identify a different sponsor
Political battles may delay the project Ask the sponsor to delegate full authority to another person who can act on their behalf
Issues and change requests may not be resolved in a timely manner Don’t start the project
Customer commitment level is – Passive / hard to engage Create an aggressive Communication Plan to keep customers engaged and communicate the business
May point out low confidence in the business value benefit
Harder to get customer time and resources needed Create User Group to surface concerns and build enthusiasm
Harder to gather business requirements Ask for customer participation in planning and requirements gathering
Customers may undermine or work against the project Ask for help from the sponsor to generate excitement
Look for opportunities to sell project in fun settings and contexts
Be proactive in gaining commitments for customer resources when you need them
Don’t start the project
Page 48
Project management experience – light Provide up-front project management training

May take longer to define the project and build work plan Designate a more senior person to coach and mentor the project manager
May make more mistakes in judgment, causing rework and project Break the project into smaller pieces that are easier to manage
delays Put a strong quality assurance process in place to ensure the project is on the right track
More difficulty organizing and managing a complex project Make sure the major deliverables are formally approved
May not be familiar with sound project management practices Utilize strong team leaders and team members to bring additional experience to bear
May not know when to call for help
Project team is located in – Dispersed locations Try to get the team into one location, at least for the length of the project
Harder to communicate effectively Create an aggressive Communication Plan to ensure the team communicates effectively
Less team interaction and cohesion Hold regular meetings where the entire team meets face-to-face
Harder to build personal relationship with the entire team Schedule team-building activities where the entire team meets face-to-face
Some members may feel isolated and not a part of the team Have backup methods to communicate if the primary technology fails
Technology problems may result in productivity decrease Maintain frequent contact by phone with remote team members
Create a central repository to hold the project documentation, that all team members can access
Project management processes – Not familiar or will not use Provide training to the project manager and project team on sound project management processes and
Team may have a difficult time understanding how to raise issues, procedures
scope changes and risks Assign an experience project management coach or mentor to the project
Project may get out of control as the internal processes become more Break the project into smaller pieces that can be managed with less rigorous project management
complex and harder to manage Define and gain approval for a set of project management procedures before the project starts, including
Communication will tend to be poorer issues management, change management, risk management and quality management
Project deliverables might be completed in different formats Create solid communication plan to ensure everyone knows what’s going on, and can provide feedback
Issues may not be addressed in a timely manner, scope changes may be Solicit input on issues, risk, scope change and quality concerns on an ongoing basis
adopted without thought of impact to the project, risks may be ignored
and quality may be compromised
Chance that the project may be in trouble before it is recognized
The business requirements of the project are – Vague or complex Use joint application design (JAD) session to gather requirements from all stakeholders together
Difficult to document the requirement properly Utilize prototyping and iterative development techniques to assist users in discovering the requirements
Difficult to use tools to document the requirements of the new system.
Difficult to understand what the expectations of the project are Get access to the sponsor and senior management people to provide overall guidance
Chance that the resulting solution will not meet business need Provide training to the customers on how to think about and express business requirements
May be a sign of a lack of focus from the customer Ensure that the final business requirements are approved in writing, and that a change management
procedure is enforced after that
Page 49
The system availability requirements are – 24x7 Allocate more time to analysis, design, testing and overall quality assurance activities
Downtime problems may result in productivity decreases or loss of Focus extra time and energy on technology architecture
revenue Focus more time and energy on database design
Redundancy may be needed, which increases system complexities Use industry best practices for all technology and process components
Newer advanced technology may be required Provide appropriate training to the team so they understand the 24x7 implications on the project
More procedures and processes are needed to maintain the system Determine exactly what portions of the system have a 24x7 requirement
environment Look for internal or outside experts to validate overall technical design and architecture
Develop solid disaster recovery procedures
Develop a strong partnership with the hardware and software vendors
The technical requirements are – new and complex Utilize system and technical design documents to clearly lay out how the technology fits together
May be difficult to understand the requirements and the implications of Define the overall system technical architecture and have it approved by knowledgeable people in your
design decisions company
May be integration issues between old and new technology Send the architecture proposal to outside consultants for further feedback and validation
May be difficulty testing the complex technology Create a pilot test or prototype to utilize the new technology in a small way at first
The more complex the technology, the greater the risk that problems Try to substitute more proven and familiar technology in the architecture
will occur Utilize multiple products from the same vendor to ease integration complexities
Problems with incompatible technologies may not be uncovered until Use products that utilize open standards and architectures to reduce the risk of integration problems
integration or system testing
The project data requirements are – Complex Utilize an automated tool to capture data elements and the relationships
Hard to understand the implications of how data relates Gain agreement on logical design before databases are built
Hard to know if and when all data elements have been captured Gather customer approval for the data models once they are completed
More likely that some data elements will be discovered missing until Utilize trained data architects to help collect the data and design what the data structures should look like
system construction
Solution may have more limited value if all required data is not present
Solution will take longer to analyze, design, construct and test
The number of locations to deploy to – Many Gather requirements from all locations you will deploy to
May be different requirements from the different locations Make sure the sponsor agrees with any customization of process or system based on different locations
May be different procedures, processes or technology Implement at a simple site first to gain experience and modify implementation process before proceeding
May be technology problems with tying all the pieces together at each with all other sites
location Make sure an overall architecture is in place that will flexibly accommodate all locations and any
Technology infrastructure may be different at different locations communication that needs to take place
Make sure the technical infrastructure is understood at each location
Number of system interfaces – Many Reduce the need for interfaces when possible
Increased complexity of testing Reduce the amount of information being passed when possible
More reliance on other projects or systems Use as flexible a technology for the interface as possible (i.e. XML)
More chance for incompatibility Break the project into smaller sub-projects with fewer interfaces to manage
Harder to track down problems, errors and bugs Work early to set expectations regarding the need for knowledgeable resources from the other systems
Test the interfaces as early in the project as possible
Add extra analysis to ensure the needs of the interfaces are well understood
Include the people that support the interfaces in the official communication and status reporting
Page 50
Number of organizations that are impacted – High Establish a formal approval process
Coordination is more complex Create a Steering Committee to represent the entire stakeholder community
Approvals can be more cumbersome and lengthy Keep the sponsor engaged and ready to intervene in the various organizations
More difficult to reach consensus Include representative from each organization in requirements, quality assurance and testing
More people and groups to involve in planning and requirements Include opportunities for people from the various organizations to meet and interact
Harder to know the major stakeholders of the various organizations Work with the team on strict adherence to overall project objectives and priorities
Implementation is harder and more complex Use consensus-building techniques when at all possible
Total estimated effort hours – High Use a project management tool to control resource utilization
Implication of a high number of effort hours is that there are many Have team members utilize weekly status reports to report on progress against their assigned work plan
people involved and more complexity activities.
Harder to communicate effectively with the team Utilize team leaders to manage sub-teams
Bottlenecks can occur when decisions are needed quickly Organize team-building activities to build cohesion
More chance of people problems Schedule status meetings to keep people informed of project status
Increased chance of turnover Utilize structured internal procedures for scope, issue, quality and risk management
More people to train Break the project into smaller, shorter sub-projects
Reduce available project work time per person, per day to recognize additional people and team related
activities
Total estimated project duration - Long Break the project into smaller, shorter sub-projects
Harder to manage to the schedule Identify clear milestones to check that the project is on schedule
Easier for the team and the customer to drift or lose focus Be diligent using formal change management procedures
More chance that project will lose organizational commitment Rotate team members into different roles to keep up the interest level
More chance business requirements will change Strive to get ahead of schedule as early as possible.
More chance of change in software or hardware versions Instill a sense of urgency from the start of the project
Difficult to instill sense of urgency at the beginning of project Organize team-building activities to build cohesion and reduce friction
More chance of team and customer turnover Ensure all major deliverables are formally approved, so that change management can be invoked
afterward
Make technical design and architecture decisions as flexible as possible to account for potential changes
The subject matter is – Not well know by the project team Take as much training as practical, as early on as possible
Longer learning curve for project team members Bring the key customers onto the project team
The project may slip behind in the early portions of the project Spend extra time understanding and documenting the requirements
No sense for whether business requirements make sense Set up approval process for requirements that require multiple subject-matter experts
Possibility that critical features or functions will be missed Use joint application design (JAD) session to gather requirements from all stakeholders together
Ned to initially rely on customer for all subject-matter expertise Utilize more frequent walkthroughs and include the users
Build extra time into the estimates for application analysis and design activities
Page 51
Dependency on outside projects or teams – Many Be very specific in defining how other projects/teams impact your project
Delays in the other projects/teams could delay your project Be very specific on the timing for when deliverables are needed form other projects/teams
Changes to deliverable from other projects/teams could force your Establish central contacts as the focal points of communication between the projects/teams
project to make changes Include the dependent projects/teams in your status reports and meetings
More complexity involved in requirements, design, testing, etc. Continually communicate expectations from the other projects/teams
More chance of incompatible standards, processes, technology
More people and groups to communicate effectively with
Harder to build consensus, longer time for decisions that impact
multiple groups
Business processes and policies require – Substantial change Document all current policies and processes and ensure that they are correct
Policy changes could delay the project Communicate precisely how the new processes differ from the old ones
People will be confused with new processes, which will effect their Communicate potential changes as far in advance as possible
ability to utilize the solution Ensure the customers are creating defining the process and policy changes
Possibility that new processes will not be fully integrated at first Have one person responsible for all process and policy changes
Possible void if new processes don’t fully cover all contingencies Create an aggressive Communication Plan to keep customers engaged and informed
System functions may not be used if not supported by correct Use the new processes in a pilot test or prototype first, to ensure they are workable and correct
procedures Include the successful implementation of new policies and processes as part of the performance criteria
Substantial change in processes may result in destructive behavior for managers
Be open to customer input on process changes – for better ideas and to allow them to feel they have
impact
Changes to organization structure – Substantial Document the concerns that come out of a new organization, and look for ways to mitigate the concerns.
Organizational uncertainty can cause fear in the organization Communicate early and often about the potential for change and the business reasons for it
People may not focus on project if they have organizational concerns Involve representatives from all stakeholder areas in the organizational design and options
People may fear loss of jobs in a new organization Get Human Resources involved to deal with potential people issues
People may not use the system if they are unhappy with the
organizational change
Uncertainty may cause decisions to be delayed
Organizational change may result in decisions made for political
purposes
The project technology is – New and unfamiliar (or new releases) Provide as much training on the new technology as practical, as early as possible
Learning curve may result in lower initial productivity Train everyone who needs to install, use or support the new technology
May be integration problems between old and new technology Make arrangements to rely on vendor technical specialists, when needed
Resistance to technology changes may cause the project to be delayed Use outside consultants who are familiar with the technology
May be difficulty testing the new technology Make sure there is an adequate test environment where the technology can be utilized without impacting
Technology may not be installed or configured correctly, which will production
lead to project delays Ensure that solid analysis is completed regarding the new technology functions, features and capabilities
New tools can lead to longer delivery times Create procedures and standards for how the new technology should be utilized
New technology may require substantial conversion efforts Create a pilot test or prototype to utilize the new technology in a small way at first
System performance may be poor while expertise is gained in
optimizing and configuring the technology
Page 52
The quality of current data is – Poor and difficult to convert Make sure that all the old data elements are correctly mapped to the new system
More work to convert the old data to the new system Test the conversion process out rigorously before proceeding with final conversion
Scrubbed data may still cause problems in the new system Determine if the cost and trouble associated with the converted data is worth the value. Ask whether the
Data conversion problems can cause significant project delays new system can start with new data only
Keep the old system around for some period to access the old data
Spend the effort to manually clean up the old data as much as possible before conversion
Package implementation – Heavy customization Consider other packages
Customization brings added complexity to the project Consider custom development
Making modifications may result in something else breaking Cut back on the business requirements so that customizations are not required
Customization can lead to poor performance Get a firm estimate of the cost and duration of the modifications from the vendor, and build into your
Customization can complicate migrating to newer releases overall work plan
Heavy customization may mean that the wrong package was selected Manage the vendor relationship to ensure all needed work is completed on schedule
Package will probably take longer to implement Make sure the sponsor has approved the customizations being proposed
Customization will require more reliance on the vendor Thoroughly test the modified package for functionality and performance
Maintain a vendor log to track issues and milestones
Package implementation – New product or release Schedule training on the package as early in the project as possible
Greater chance of problems surfacing Add an internal resource, or a consultant, with prior product experience onto the project.
More reliance on the vendor to ensure problems are corrected quickly Schedule a pilot test or a prototype to gain familiarity with the package before full implementation
Installation, testing and deployment will take longer Establish agreements with the vendor stipulating support level and problem resolution times
Hard to know up-front whether the package meets all the business See if the project can be delayed until other companies have utilized the product
requirements Seek out other companies that have used the product for their feedback and key learning’s
Package implementation – New vendor Make sure that all agreements with the vendor be in writing
Possibility that vendor may not survive and leave you with no support Insist that source code be placed in escrow in case the company does not survive
Upgrades may be in jeopardy if there are not enough sales in the Ask the vendor to be a part of the project team
marketplace Maintain a vendor log to track problems with the package
No prior relationships from which to build a quick partnership Make sure the vendor is financially sound
Legal and financial concerns may delay contracts and the project Establish agreements with the vendor stipulating support level and problem resolution times
Page 53
APPENDIX C: PROJECT CLOSEOUT PROCESS FLOWCHART
60-100 days prior to contract Conducted about 6 weeks

expiration after implementation
QA team conducts
Project Manager
Post-
reviews contracts
Implementation
for closure
Audit
Conducted within
4-6 weeks after
implementation
QA team
interviews Project
Manager and
Project Manager * primary user(s)
conducts a “Lessons
Learned” session with
project team and OIS
management and
documents
recommendations for
future projects QA team prepares
Post-
Implementation
QA Report
Must be completed within 60

days after contract
expiration.
Project Manager reviews

Project Manager
Post-Implementation QA
prepares contract
Report and if necessary,
Performance
prepares a QA Response
Evaluation
memo
Project Manager prepares Project Closure

Report and attaches Post-Implementation QA
Report, QA Response Memo (if applicable), and
contract Performance Evaluation
Project Manager
obtains project
Project Manager
acceptance and
archives project
sign-off on Project
documentation
Closure Report
* For contractor led projects, contractor’s project manager (PM) may perform this task. Otherwise, State PM is responsible.
Page 54

OISProject Management Guide

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

OISProject Management Guide

Cargado por

Copyright:

Formatos disponibles

OFFICE OF INFORMATION SERVICES

PROJECT MANAGEMENT GUIDE

Project Management Responsibilities ................................................................................................................. 4

Project Management Life Cycle Phases.............................................................................................................. 6

1.0 Initiating the Project................................................................................................................................. 7

1.1 Project Concept ...................................................................................................................................... 7

2.0 Project Planning........................................................................................................................................ 8

2.1 Project Scope .......................................................................................................................................... 8

2.4.5.2 Quality Assurance..................................................................................................................... 26

3.0 Project Execution & Control ................................................................................................................. 32

3.1 Kick-Off Meeting.................................................................................................................................. 33

4.0 Project Closeout ...................................................................................................................................... 44

4.1 Prepare Project Closure Report........................................................................................................... 44

Appendix A: Project Risk Factors..................................................................................................................... 47

Appendix B: Risk Management Strategy Table .............................................................................................. 48

Appendix C: Project Closeout Process Flowchart........................................................................................... 54

PROJECT MANAGEMENT RESPONSIBILITIES

Understand Project Needs

Acknowledge Staff Capabilities

• Staff Responsibilities: What staff management responsibilities will be required?

PROJECT MANAGEMENT LIFE CYCLE PHASES

1.0 INITIATING THE PROJECT

Some sample benefits to be considered when developing the Project Concept:

o implementation of new technology o lowers technical support costs

1.2 Project Charter

The objectives of creating a Project Charter are:

• To provide the initial scope on which the project will be planned.

2.0 PROJECT PLANNING

The objectives of creating a Project Plan are:

The following components make up the Project Plan.

2.1 Project Scope

2.1.1 Functional Requirements

• Requirements approved • Unit test completed

Milestones should have the following characteristics:

2.2 Project Organization

2.3 Project Work Plan

2.3.1 Define and Sequence Tasks and Document Tasks Relationships

• Improve the accuracy of time, and resource estimates.

• Traditional High level Timeline (Planning/Analysis/Design/Construct/Test/Implement); or

Some useful tips for determining if your level of breakdown is sufficient:

2.3.2.1 Create the Initial Estimate of Effort Hours

2.3.2.2 Document the Estimate

2.3.2.3 Calculate Total Effort

2.4 Project Management Plans

2.4.1 Communication Plan

Resulting communication activities should be documented in a communication plan and added to

The following process could be typical:

2.4.1.1 Status Reporting

2.4.2 Issue Management Plan

2.4.3 Change Control Plan

• Only necessary changes are made,

If appropriate, a change review committee should be made up of a cross selection of team

2.4.3.1 Identifying Changes

2.4.3.2 Reviewing and Evaluating Changes

“What effect will this change have on the project’s outcome?”

To understand this question fully, an analysis must be conducted to understand the

• Impact of the proposed change on the project schedule.

2.4.3.3 Communicating Change

2.4.4 Risk Management Plan

• Ensures key threats are adequately addressed and responded to.

• Facilitates timely communication of risk information.

2.4.4.1 Risk Identification