P. 1
OISProjectManagementGuide

OISProjectManagementGuide

|Views: 15|Likes:
Publicado porbksidhu

More info:

Published by: bksidhu on May 09, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/09/2011

pdf

text

original

OFFICE OF INFORMATION SERVICES PROJECT MANAGEMENT GUIDE

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 1.1 1.2 2.0 Initiating the Project................................................................................................................................. 7 Project Concept ...................................................................................................................................... 7 Project Charter....................................................................................................................................... 7 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

PROJECT MANAGEMENT GUIDE 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 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Project Execution & Control ................................................................................................................. 32 Kick-Off Meeting.................................................................................................................................. 33 Manage the Project Work Plan ........................................................................................................... 33 Execute the Communication Plan....................................................................................................... 33 Manage Issues...................................................................................................................................... 35 Manage Scope and Control Change ................................................................................................... 35 Monitor and Control Risks .................................................................................................................. 36 Implement Quality Management......................................................................................................... 37 Execute the Training Plans ................................................................................................................. 38 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

PROJECT MANAGEMENT GUIDE Appendix B: Risk Management Strategy Table .............................................................................................. 48 Appendix C: Project Closeout Process Flowchart........................................................................................... 54

Page iii

PROJECT MANAGEMENT GUIDE

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

What types of communication will be required? Negotiation of requirements. or broken down into subprojects assigned to different individuals? Priorities . o Track project progress. o Identify resource requirements.. What types of communication will be required? Negotiations for resources (staff and funding) Status reporting... o Prepare and present the project plan. o Select the project team. o Manage vendor relationships.. o Estimate time. o Approve. o Monitor and resolve open issues. Status reporting. Problems and issues communication. Page 5 • • . considering other priorities and existing workload. Execution Responsibilities: What execution responsibilities will be required to manage this project? o Hands-on technical contributions. goals. Coordination with a project steering committee. o Manage the project budget.. the project management responsibilities required to drive the project to success need to be identified. o Communication with Project Sponsor/Management. acceptance criteria. o Maintain and monitor the project plan. Available time . reject and apply change requests. can other projects or workload be balanced differently to allow for one individual to manage the project at hand? Authority . can any one individual devote sufficient time to the project? If not can the project scope be modified. • • 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. how much authority will the project manager need to get the job done. and is that level of authority organizationally feasible? If not. Problem escalation. costs and schedules. schedules and scope changes. and deliverables... 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. o Define scope. Communications Responsibilities: o Communication with customer (end-user)..PROJECT MANAGEMENT GUIDE o An organizational change agent that knows how to get things done and how to influence the organization to bring about change.

should the project manager have extensive management experience. Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address. Closing Formalizing the acceptance of the project or phase and bringing it to an orderly end. 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. Page 6 .0 2. 4.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.PROJECT MANAGEMENT GUIDE • 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.0 Initiating Planning Recognizing that a project or phase should begin and committing to do so. complexity and visibility of the project.0 3. 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.

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. 1. and the appropriate OIS IT Procurement Manual or OIS RFP/Contract Procedure Manual for the process. cost. and communications. including hardware and software. Soft Objectives . Refer to OIT Guideline GUI-001 to determine whether OIT approval is required.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.1 INITIATING THE PROJECT Project Concept The Project Concept is the foundation for initiation of the project. Page 7 . which are those criteria within the project that will determine whether the project is a success or a failure.These relate to the time. It will establish the initial scope of the project by defining the work that is to be included or not included in the project. but it is critical to ensuring the acceptance of those choices by management and end-users. This is necessary not just to ensure that the best choices are made. The purpose of the Project Concept is to provide high-level information that describes the characteristics of the product/process to be created. and which may include attitude. It should explain what problem or opportunity exists to improve a business function and provide the evidence that proves the problem or opportunity exists.000 will require initial approval by the Office of Information Technology (OIT). resource requirements. and an implementation time frame should also be identified.0 1. behavior. and operational objectives (scope) of the product or process. Objectives can be described in two different ways: • • Hard Objectives . The charter should also define the project’s objectives.These relate more to how the objectives are achieved.PROJECT MANAGEMENT GUIDE 1. expectations. Estimated project costs. Some sample benefits to be considered when developing the Project Concept: implementation of new technology upgrade of existing technology change in policy or procedure organizational changes process re-engineering maintains/improves system reliability maintains/improves system security maintains/improves system performance to keep systems current (configuration or version) o protects current investment in technology o o o o o o o o o lowers technical support costs facilitates technical support activities improved system ease of use increased productivity improved workflow facilitates internal or external communication o reduces training requirements o eliminates or reduces the need for external resources o simplifies procedures through ease of operation o o o o o o Information technology (IT) projects and initiatives with a total projected cost equal to or greater than $100.

if the development phase has been defined to accommodate user needs. Project objectives are also used to establish performance goals. However. For example. organizational commitment.e. if the development has been divided into phases to reduce risk. For large systems. They should coincide and be consistent with overall project scope and schedules. Finally. or planned levels of accomplishment stated as measurable objectives that can be compared to actual results. Page 7 . verifiable or quantifiable business objectives that a solution must deliver. and assign key leadership roles. 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. 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. Performance measures should be stated for each goal. there is typically a single project development phase. 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. however. Other times. there may be multiple development phases often spanning multiple fiscal years and addressing different functional requirements. the Project Charter should identify the project organization. the development phases are used to partition the development effort and to reduce the risks associated with larger projects. To provide clear and. including key agency participation and subject matter experts needed to support the project. In a large or complex system. define the primary roles and responsibilities. the phase may cross multiple functional areas of the system. The Project Charter should also describe the development approach.PROJECT MANAGEMENT GUIDE Objectives need to be clearly stated and there must be a clear understanding as to why they are relevant to the project. In a small project. the division might represent completion of entire functional areas of the system.. To obtain sponsorship. as far as possible. The objectives will be the benchmark for which project success will be set. phased or iterative implementation). and identify project assumptions.

Page 8 .1. and timing.PROJECT MANAGEMENT GUIDE 2. The planning process is two fold. The following components make up the Project Plan. The amount of planning performed should be proportionate with the scope and the usefulness of the information developed. sequencing. and is the basis for future project decisions. To obtain an agreement on how the project will be managed. and assumptions. The project manager must be able to produce a product(s) based upon information contained in the plan. It involves developing the core work plans – work activities. and negotiate commitments." 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.1 Functional Requirements While the business requirements documented in the Project Concept answered the question of why a project is needed. the technical complexity. as well as steps to produce a project schedule. assess and manage risks. A Project Plan is developed from the results of the planning process activities and puts them into an integrated. a project or phase may require more or less detail to manage and control the work execution. and who must be involved. major deliverable milestones. Depending on the business need. The Project Plan forms the basis for all management efforts associated with the project. the scope of the effort. resources. creating a solution and managing all aspects of the phase or project. the Project Plan further builds on the scope to include the functional requirements. and coherent document to ensure that all of the various elements of the work are properly coordinated. and the resources required to complete the project. identify. consistent. To reiteratively update the project plan as changes occur on the project and as new information becomes available. objectives and problems that the project must resolve. the functional requirements specify what the solution will do. capacity. As a "living document. the plans represent what is required to create the solution and manage all aspects of the work. or capability expected. To obtain a common understanding and agreement of the work and resources required. 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). This integrated scope will serve as the test for every change request received. The functional requirements should clearly indicate the desired functionality. 2. Collectively.0 PROJECT PLANNING Planning is a process that includes more detailed activities to estimate the size of the project. while at the same time developing project management plans to control the project or phase. The objectives of creating a Project Plan are: • • • • To create an initial plan that is focused upon the agreed scope.

Milestones represent major points of progress within the project. but the completion milestones should always be included in the Work Breakdown Structure (WBS) whereas the start milestones are optional. then each of these committed deliverables should have a milestone representing its completion. the level of risk. The number of tasks and milestones identified should relate to what is known about the project. Milestones pertain to a point in time and should be used as management checkpoints to measure accomplishment. milestones are often used as a point in the project where interim payments might be made. it also serves as a useful communication tool for stakeholders and the project team. and therefore have no duration. Milestones should be named as past tense events. and major milestones should be summarized in the Project Plan. the comparison of due dates to actual dates provides an indication of project health. 2. As an example. If. and the fact that it is completed. 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. and the level of detail required of management. later changes to the schedule are very difficult and risky. While milestones are unique to each project. Milestones should have the following characteristics: • • They are a point in time. “Acceptance Test Completed”. as in “Acceptance Test Started”. Over the course of the project. Milestones can also represent the beginning of a process. This communicates two facts: the life cycle phase or the major deliverable.3 Assumptions Documentation of the assumptions made in planning the project is critical to the success of the project. you define a milestone by setting the duration of an Activity to zero. and will provide a high level means of communicating. • • Documenting and tracking deliverables/milestones not only keeps the project on track. some common information technology project milestones are shown below: • • • • • Requirements approved Phase review approved Prototype approved Design reviews completed Code reviews completed • • • • • Unit test completed Integration test completed Acceptance test completed System accepted by customer Documentation delivered For contracted work. Therefore they should represent events that have significant importance for project stakeholders. a schedule was shortened because it was assumed that a Page 9 .PROJECT MANAGEMENT GUIDE 2. mutual agreement is necessary on the content of each milestone and the cost associated with that milestone. In most project management software.2 Deliverables/Milestones Milestones denote the completion of key project activities.1. for example. Without clear documentation of these assumptions. If this approach is used.1.

Small projects will require less organizational definition than larger projects. These schedules are two-dimensional representations that show the tasks and the timeframe for completion. The plan should also include key project members’ names. It is also important to identify all other stakeholders. 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. documenting. the GANTT chart is very common for reporting status and for defining the schedule. Then. the schedule could be placed in serious risk without the project manager realizing it. and assigning project roles and responsibilities as they relate to the work defined. Developing the schedule can be done informally in a table or spreadsheet when the number of activities is approximately 20. but responsibilities should always be defined. the project manager can recognize the risk and make necessary changes and decisions. that assumption should be documented. 2. 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 valuable tool because it forces the planner to address sequencing constraints that might otherwise be missed. project position. It is a vital tool to ensure that the project team knows what they need to do.2 Project Organization Organizing the project includes identifying. However. duration estimating and resources requirements prior to final determination of the project schedule. The critical path is the path with activities that cannot be delayed or the project finish date will be delayed. relationships are not complex. Without documentation of the assumption.PROJECT MANAGEMENT GUIDE highly skilled person would be performing the work. 2. The project plan should include an organization chart of the project team. A stakeholder is someone who has a business interest in the outcome of a project. a GANTT chart (or bar graph) is adequate. and analysis of critical path is fairly simple to manually assess. or graphical representation of how tasks interact with each other. and responsibilities. Page 10 . This process is iterated as the other planning process steps provide the inputs (especially activity definition. it is considered a weak planning tool for complex information technology projects. The type of schedule associated with a project relates to the complexity of the implementation. unless the time can be offset somewhere else on the critical path. or will contribute resources to the project. Microsoft Project will determine the critical path and can be used to produce a network diagram. if a less skilled person is actually assigned to perform the task. For moderate to complex projects. Schedule development means determining start and finish dates for the project activities defined and allocation of the resources to these activities. Microsoft Project will be used. For small projects.3 Project Work Plan A work plan must be prepared and used to manage the effort. is directly involved in the project. including those internal and external to OIS. Since task interrelationships are not easily shown on a GANTT chart.

transition management. 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. or By Deliverables.PROJECT MANAGEMENT GUIDE 2. and resource estimates. Facilitate clear responsibility assignment. requirements. the Quality Management Plan. The idea here is that you don’t want to track anything that takes less than a day. installation. design. but if it takes more than 10 days to complete.e. Sequencing establishes the dependencies among the tasks and milestones and is used to calculate the schedule to deliver the product. If not. i. testing.3. 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. Examples: • • • Traditional High level Timeline (Planning/Analysis/Design/Construct/Test/Implement). 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. it should probably be broken down into one or more work packages. or By Functional Tasks The WBS reflects activities associated with overall project management. Page 11 .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. then it should be further broken down into sub-activities to provide clarity. If not. 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. training. 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 activity should be further broken down into sub-activities. more manageable components in order to: • • • Improve the accuracy of time. After the tasks and milestones to deliver a product are determined. Activities should have a clearly defined duration or a total effort that can be scheduled. The decomposition of the major deliverables into work activities and then tasks is referred to as the Work Breakdown Structure (WBS). Activities should represent unique work that can be distinguished from other assignments and can be identified and fully understood by those assigned the work. Define a baseline for performance measurement and control. they should be logically sequenced to reflect the way the work will be performed. implementation. and maintenance.

and mistakes and misunderstandings during the execution of the project. A successful schedule builds these types of factors into the duration estimates. unexpected events. If a project has been done before. Successful estimating involves the use of the following time-tested techniques. Analogous Information Analogous information comes from components of other projects that are very similar. there are also relationships (dependencies) between tasks that need to be identified and the tasks restructured to minimize dependencies. and interaction among the staff. However.2. to components of the current project. Subtask completion rolls up into task completion.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.3. This approach may be appropriate when there is enormous uncertainty about what will be involved in a project. meetings.3. the skill level of the person assigned to the task. Historical Information Historical information is data or documentation that may exist from a previous project that is identical to the current project. 2. An accepted rule of thumb for estimating staff productivity is that an employee spends 85 percent of their time on productive tasks. The WBS structure denotes a hierarchy of task relationship. If the tasks are not organized efficiently. while the remaining 15 percent accounts for staff meetings.2 Estimate Task Duration and Resources Required to Perform Each Task Estimating task duration is one of the most challenging aspects of project planning. etc. reality is a major factor. but not identical. holidays. stretch breaks. and an overall project estimate Page 12 . 2. Analogous information can also come from operational experience. the schedule rapidly falls apart. When estimating the duration of a task. it may become difficult to schedule and allocate resources to the tasks.PROJECT MANAGEMENT GUIDE Task relationships exist when there are activities that must be completed before other activities can start. a project manager can learn a great deal of knowledge from the documents associated with the project. which ultimately results in project completion. efficiency of work time. No one is 100 percent productive every hour of the workday. discussions. Phased Estimating Phased estimating is a technique in which estimates are constructed separately for each phase of the project. Some of these variables include staff availability. If a scheduled task assumes 100 percent productivity. The estimation process is complex because activity duration is affected by numerous variables that must be dealt with concurrently in the Planning Phase. The knowledgeable scheduler takes into account absenteeism. shifting from one productive task to another.

3 Calculate Total Effort Estimate duration by converting hours to duration.3. waiting on deliverable approval before beginning next task.3.0. 2. If the estimate is based on a similar project with reliable historical information. If the estimate was developed without the benefit of detailed data. and a new estimate is created for each phase of the project. i. The execution of the project plans is discussed in Section 3. the contingency could be 35%. • Take into account any resources that are not full time. • Use a factor of 6.2. used to reflect the uncertainty or risk associated with the estimate. administrative help. if the work package estimates are flawed. risk management. quality management. so will be the project estimate. training and documentation. contingency may be 5-10%. The people providing the estimates must know how the work actually gets done. the project may be separated into a series of sequential phases. Bottom-Up Estimating Bottom-up estimating is very time consuming.. Page 13 . • Determine the number of resources to be applied to each activity.e. generally 15% of the effort hours for full-time project management.5 productive hours per day (based on a 40 hour work week) to account for meetings. If you have time to create a reasonably accurate estimate based on estimating each work package. do not pad estimates. However. • • 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. This approach requires a WBS in which the work package estimates are rolled up in order to calculate the total estimate for the project. i. • Factor in available workdays for the timeframe. vacations. In this scenario. Add time for project management activities. and other non-productive activities.2. and training. but it the most accurate technique available.PROJECT MANAGEMENT GUIDE would be mostly guess work. change control. administrative activities. sick time. taking into account holidays. 2.e.2 Document the Estimate • Add contingency hours. and they cannot overestimate or pad the time required. Include hours of indirect project resources. • Calculate delays and lagtime. or the accuracy of the estimate is not well known. but lacks the detail required for high accuracy. Add contingency hours as a separate item. the contingency may be 15%. • Determine what work can be done simultaneously.

e. email. letter. For each recipient group outline “When” the schedule or dates of communication. Facilitating the communications includes things like creating the agenda. taking into account the particular needs of the people involved.PROJECT MANAGEMENT GUIDE 2. status update) will be delivered to the various recipient groups. Resulting communication activities should be documented in a communication plan and added to the work plan. or holding a regularly scheduled status meeting. which is created as follows. due dates.g. and post implementation support teams have the information needed well in advance to prepare to accept. that will be affected by the project. Proper communication can go a long way toward ensuring project success. at the right time. 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. Communication is also a way to manage expectations about how the project is going and who needs to be doing what. memo. newsletter. Page 14 . Identify “What” type of communications (e. a specific day…are to occur. effort hours and a responsible person(s) for each communication option implemented. end users. The Project Team Communication Plan identifies the types of internal communication to be used on the project. • • • • Identify “Who” the recipients or groups of recipients of communication are intended to be. However. Efficient communication means providing the information that is needed and nothing more.1 Communication Plan The purpose of a communication plan is to determine the communication needs of all people within OIS.4. and possibly external to OIS. scheduling the meeting. This creative and proactive communication is laid out in a communication plan. and support the project once it is implemented. communication is simple and does not require much proactive effort. The project manager must make sure team members. stakeholders. and with the right impact. Training of target groups is documented in the training plan. weekly. Effective communication means providing information in the right format. personal conversation.g. For each recipient group. This is where the communication plan proves most useful. monthly. facilitating the discussion and preparing documentation. This can be as simple as talking to team members about how they are doing on their assigned work. identify who is responsible for delivering the communication. communication becomes much more complex as projects increase in size and scope and involve more people. On smaller projects. 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. This will include assigning frequencies. use. A communication plan allows the manager to think through how to communicate most efficiently and effectively to various audiences. documentation of meetings. Proactive communication is important on all projects. Larger projects require project managers to plan communication in advance. 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.

Page 15 . scope change requests or potential risks. and the need to get information in a timely manner. just as for a medium size project. The frequency of the meeting depends on the timetable for the project. Status meetings and status reporting are required. However. and kept to no more than one hour.e. including financial information about the project. In addition. • The entire project team holds informal project status meetings. there could be a status meeting for the project team and a separate meeting with the stakeholders. there are many other types of proactive communication that should be considered. Status Reports from Team Members to Project Manager: The project team members should report status weekly or bi-weekly to the project manager. Note: Be careful about the frequency of reporting. The meetings would focus on the status against the Project Work Plan and uncovering any current issues. The project manager communicates status to the project sponsor and stakeholders on a periodic basis. 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. all communications must be incorporated into the overall communications strategy. • • Large Projects In a large project. but their attendance is not mandatory. if the project manager is not working on the project. Medium Projects Medium projects should include formal status meetings and status reporting: • Status Meetings: Stakeholders should have representation at the status meeting. e-mails. 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. If the project manager prefers. team status reports) if the Project Manager is doing any hands-on work on the project.PROJECT MANAGEMENT GUIDE 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. The meetings should be held weekly or bi-weekly. Stakeholders could be invited to attend. A more frequent status may be needed for projects of short duration to allow stakeholders time to react to anything unusual. This is in addition to the status meeting.

etc). 2. The collected information can be disseminated by creating a project status report. how much change has occurred. Project managers have primary responsibility for screening issues and determining if a solution can be reached before creating a formal issue. or stakeholders. or suggestions raised by the project team. The level of management involvement in the resolution approval process will be specified in the Issue Management Plan. question. issue log.e. 2.4. and determine what the potential benefit of the communication is. An issue is defined as a situation. risk log. change control log. even though they may take little effort from the project team. resolution may come from OIS management. and documenting the solutions. what deliverables are complete. and training log. discard those that provide marginal benefit.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.1. The project status report could be tailored to the individual project and should be in the same format throughout the project. Issues are identified in the form of questions.4. contractor. 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. This type of information comes from work results – what deliverables are fully and partially complete. which would result in changes to cost and schedule. action. concern. determine the effort required to create and distribute each of the identified communication options. what costs have been incurred or committed. Also. Implement the communication options that provide high value and require low effort from the project team. problems. tracking the progress of the resolution. The options should be prioritized. All members of the project team have responsibility for raising and investigating issues. OIS has developed status report templates which can be modified to fit the project.PROJECT MANAGEMENT GUIDE The project team should brainstorm on how to fulfill the communication needs. quality control review recommendations. They can often affect the status of tasks or deliverables. how much time and dollars have been spent. or problem that could impact or impede the progress/success of a project.2 Issue Management Plan The purpose of an issue management plan is to is to outline the recommended approach for identifying outstanding issues. and other project records such as the schedule. and those that require high effort for marginal benefit should be discarded. Page 16 . and attached to the Project Plan. management. the project sponsor. or an oversight or steering committee. Depending on the level of authority needed. Once the project is underway collecting performance information involves gathering and analyzing information about the project (i. How status reporting is to be carried out for the project is defined in the project team’s communication plan. etc.

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

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

while other issues may be deferred to future releases. Issues will be created during the entire project life cycle. and to clarify how the change will affect later tasks and milestones.. or a new area of functionality). The scope of purchasing has just been expanded to encompass accounts payable. The bottom line to every change request is that it adds additional overhead to the project. one more inquiry view. • • • • 2. and be able to implement the necessary actions to control them.” things or functions introduced by the enthusiasm of the project team that involve “over design”. Someone on the client team makes an informal request of someone on the project team (e.3. The following considerations are helpful in evaluating a Page 19 . These changes are the result of problem resolutions that identify a noncompliance to the business functional requirements or the detailed design document.4. The client makes a formal request for an additional function to be incorporated into the product. Issues must be reviewed. The changes are introduced as part of normal information gathering / status reporting processes and usually reflect overlapping areas of the project.2 Reviewing and Evaluating Changes Once change requests are submitted and documented. or unapproved testing of new design techniques. the request should be escalated to the proper authority to determine whether the request should be investigated or not.PROJECT MANAGEMENT GUIDE 2. “over build”. the project manager must be able to recognize the many forms a change can take. In order to manage changes. Problems. Covert client requests. “For example.1 Identifying Changes Any project stakeholder or team member can identify a potential change request. cost and impact. These changes represent the “Wouldn’t it be nice if….g. 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. These changes need a sharp ear to catch. one more report. estimated. Smuggled requirements. Some issues may result in a change request.” Project team enthusiasm (design changes). timing. Sometimes. or rejected outright.4. and approved by management.3. they have to be reviewed to assess value. the time required to perform the analysis will cause deliverable dates to slip. 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. These are the easiest to identify. If this is the case. Issues. These changes sneak in when the project manager isn’t looking. Some examples of how changes can get introduced into a project: • • Overt client requests.

Page 20 . the project manager will also need to sharpen communication and negotiation skills.4 Risk Management Plan ‘Risk’ refers to any factor that may potentially interfere with the successful completion of a project. tasks that can be deleted or shortened. 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. materials. contingency planning. And. a compromise will probably need to be negotiated. and mitigated whenever possible by documenting the activities used to manage risks. a risk is a potential future problem that has not yet occurred. To effectively manage project 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. The risk management plan identifies the initial top risks associated with the project and the mechanics of integrating risk management throughout the project. 2. Prevents threats from adversely affecting the project.) Skill level of personnel required to complete the proposed change. quality assurance. accurate risk assessment. risk management) be assessed when defining the true impact of the change request to the project.g. documentation.4. people.. A proactive project manager tries to resolve potential problems (risks) before they occur. Effective risk management provides the following value to the project: • • Ensures key threats are adequately addressed and responded to. additional project management time. Risk management is a continual process of timely risk identification. should an approved change result in unexpected negative consequences. The purpose of a risk management plan is to ensure that each risk identified is documented. Risk levels of the proposed change. and technology)? It is imperative that all areas of the project (e.3 Communicating Change Change control procedures and standards are only part of the picture. Impact of the proposed change on the project budget. and effective risk mitigation. tools. or dollars that can be moved around in the project. 2.3. In other words. on the flip side. A reactive project manager resolves problems when they occur.PROJECT MANAGEMENT GUIDE change request. computer time. In the event a change request is denied. testing. In the event resistance is encountered..g. prioritized. the approval decision must be justified.4. the project manager must be able to communicate and justify that decision. and making a recommendation for its resolution: • • • • • • • • • • Impact of the proposed change on the project schedule. determining its impact on the project.

o Early adopter's risk . documented in the Project Plan. Resource Risks . a lack of skilled resources. Sometimes a risk identification “brainstorming” session can help in the initial identification process. version conflicts.” When identifying risks. o Project requirements and outcomes are poorly defined. or the reliability and availability of external service providers. consider the nature and complexity of the project.early adoption of new technology will limit the ability to benefit from the experiences of others. staff non-performance. and classify each risk into one of the following categories. o Poorly defined or understood roles and responsibilities. Risk identification can be accomplished by identifying causes and effects (what could happen). The process to be used to manage project risks is defined in the planning stage. incompatibilities or bugs. and a risk management log. Don’t try to identify all possible risks that might affect the project.4. o The project does not have effective sponsorship or management support.PROJECT MANAGEMENT GUIDE • Facilitates timely communication of risk information. Some examples of technology risks: o Potential incompatibilities exist within current desktop platforms or internally customized applications. The activities used to manage risk are described in this section. Technology Risks . a risk assessment and planning form. operational failures. but focus on those likely to affect the project’s success. The procedures and forms can be modified to fit the project. o Outdated or insufficient hardware exists for running new software products. All members of the project team can identify risk.Specific technical risks including design omissions. and then executed throughout the life of the project.1 Risk Identification Risk identification consists of determining risks that are likely to affect the project and documenting the characteristics of those risks. Some examples of resource risks: Page 21 • • . or effect and causes (what outcomes are to be avoided).Human resource risks can involve staff changes. structure and strategy of a project. Some examples of management risks: o The scope and complexity of the project is too large. • Management Risks . Such meetings help team members understand various perspectives and can help the team members better understand the “big picture. The following sections explain each of the key elements of a risk management process. OIS has developed risk management procedures.Risks that relate to the scope. and attached to the Project Plan. but the project manager has overall responsibility. 2. The use of a formal process helps identify risks early in the project and incorporate actions that reduce the negative impact to the project.4.

2. they must be assessed to determine the probability of occurring.Political risks are internal sensitivities relating to project support. but is not a one time event. It should be performed on a regular basis throughout the project. o The loss of key staff to competitors or vendors may occur once they are trained in new products or technologies. and the potential impact to the project is assessed. analyzing and assessing the impact of these risks. • Timing Risks . o Pending organizational changes that impact the project.4. o Insufficiently skilled staff. Some examples of political risks: o The project is dependent upon one individual for visibility and support. • Risk identification begins in the early planning phase of the project. and that person leaves. each risk should be assigned a high.Timing and scheduling risks can include product delivery delays. An example of a timing risk is an overly aggressive project schedule that may limit the execution of thorough test plans. At the end of the planning stage. the result should be a risk identification summary of known project risks. Political Risks . This list is a roadmap to the next step.2 Risk Assessment Once risks have been identified and categorized. o Competing projects within OIS. or low overall risk level.PROJECT MANAGEMENT GUIDE o Continual resource availability may be compromised during lengthy projects. internal cooperation and communications. medium. o Political issues that negatively impact resource availability and cooperation. 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 should the risk occur. To determine impact. sponsorship. The following table can be used as a guide in assigning the overall risk level: Risk Factors High negative impact to project / Highly likely to occur High negative impact to project / Medium likely to occur High negative impact to project / Not likely to occur Medium negative impact to project / Highly likely to occur Medium negative impact to project / Medium likely to occur Page 22 Overall Risk Level High High Medium / Low Medium Medium / Low .4. or missed deadlines along the critical path.

and the benefits of the project far outweigh the risks. You can alter plans and schedules. you may have a large project. or adopt different technical solutions. look at the medium-level risks to determine if the impact is severe enough that they should also have risk planning activities. Contingency plans are predefined action plans that can be implemented if identified risks actually occur "i.4. which implies higher risk. but decide that any actions to avoid or mitigate the risk are too costly or time consuming. modify project plans. Mitigation is when you seek to minimize the potential impact of any given risk through the analysis and consideration of alternative solutions. Contingency planning may be the only cost-effective and feasible response to the risk.) 2. It may just be possible the risk cannot be avoided or mitigated in any meaningful way. These strategies can include acceptance. it can be assumed the condition will not occur. In essence. The results shown should be used as guidelines. (Medium risks fall in between the extremes. o Avoidance/Mitigation: Avoidance is when you take steps to eliminate the risk in its entirety.3 Risk Planning After completion of the risk assessment process. As a guideline. Then look at any low-level risk items. see Appendix A: Project Risk Factors. contingency plans should be developed.4.PROJECT MANAGEMENT GUIDE Medium negative impact to project / Not likely to occur Low negative impact to project / Highly likely to occur Low negative impact to project / Medium likely to occur Low negative impact to project / Not likely to occur Low Low Low Low For additional help in determining project risks and probability. and take specific actions to minimize the chance that a risk will occur. but because the risk is low.e. I will do that. I will stick with the original plan". For instance. o Acceptance is when you acknowledge the risk. but it may be the only way to achieve project deliverables. risk planning activities should be included for each high-level risk. Avoidance can be costly. The activities associated with managing the various risks should then be moved to the project work plan. this is a combination of acceptance and avoidance. but until then. or the risk is beyond the control of the project (these are typically political or legislative). medium or low. you can evaluate whether your risk is high. if this happens. and see whether they should be listed as assumptions. avoidance or mitigation. since there will be other factors that may lower or raise the risk level. Depending upon the circumstances. In this way a potential for problems can be recognized. This risk could be reduced if the project manager is experienced. assign additional resources. After the high-level risks have been evaluated. the next step is the formation of specific strategies for the management and control of certain risks. For certain risks. Depending on where project characteristics fall. Page 23 . you may need to change project scope.

A risk management tracking log should also be used to summarize all relevant risk information. The goal is to build the deliverables with as few errors as possible. For this reason. it is important for the project manager to plan the project to include risk monitoring activities. Risk monitoring and control during project execution is discussed further in Section 3. While mitigating strategies provide the best of both worlds. The project manager must maintain the log to ensure that the information needed for effective risk monitoring and decision support is kept current. that benefit cannot be realized without some expense in terms of time. and resource demands. potential risks must be continually monitored. It addresses both quality assurance (QA) and quality control (QC)practices.4. Quality management is an ongoing process that should be focused on throughout the project.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. As the project progresses. However. Rework refers to having to do the same work twice because the original effort was not satisfactory. a trigger mechanism should be identified that indicates when the contingency plan should be initiated. The frequency of periodic risk reviews should be addressed in the risk management procedures and should be suited to project circumstances. However. This is work that is required because the original construction and testing process was not thorough enough and errors still existed in the deliverable. 2. rework is required.0 of this guide. overall project status. If a contingency plan is appropriate for the risk.4. if there are subsequent errors when a component is tied into the larger application.4. equipment and staff resources. and new risks can arise. and then to find and correct any remaining errors as early as possible. 2.PROJECT MANAGEMENT GUIDE Contingency plans attempt to minimize the effects of the risk assuming the event does occur. risk once thought to be unlikely and insignificant can suddenly become very likely and dangerous.4 Risk Monitoring and Control The risk management process is an ongoing effort that lives throughout the entire project cycle. Work resulting from component walk-throughs or peer reviews is not considered rework. Quality processes should be continually improved to eliminate the potential for defects and rework within a project. The second column shows examples of activities that can help mitigate the risk. It is often the result of not having rigorous quality processes in place. See Appendix B: Risk Management Strategy Table to see high-risk factors and examples of problems that may be encountered. Quality should be planned into the project as opposed to auditing it into the project. The benefits of effective quality management include: Page 24 . Periodic risk reviews should be conducted as often as practical and whenever needed. Quality activities should be included in the project work plan. since it is part of building the component the first time.

conversion.5. Page 25 • • . requirements definition. Stakeholder surveys and focus groups.1 Quality Control Quality control refers to the activities the project team will perform to ensure project deliverables are of acceptable quality. but may be completed under standard processes (i. standard OIS and team processes). Projects with poor quality management tend to miss their deadlines and exceed their budget. Involves developing a mock up of deliverables so that stakeholder feedback can be obtained early in the project. Prototyping. Less demand on the Help Desk and support staff due to fewer problems being reported. code and test plans to ensure requirements are being met. Smaller projects will not require a “unique” quality plan. 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. user acceptance. customer satisfaction may be higher since the actual deliverable may be more in alignment with expectations. Requirements tracing. 2. Prototyping may help to reduce change requests later in the project. RFP. The following sections describe the key considerations in quality management planning. Higher team morale results from smooth running development processes and low incidences of errors and rework. Increased customer satisfaction through fewer system defects and higher quality service. volume/stress testing and parallel testing). In addition.4. These may be used to obtain information on customer needs and satisfaction.e. The procedures are followed by an independent QA team who may modify the audit and interview checklists to fit the project.PROJECT MANAGEMENT GUIDE • • • • Higher productivity and less rework whereby deliverables are produced on-time with less effort due to minimal errors and rework. Quality control is conducted continually throughout a project by the project manager and team members. systems integration. interface. conceptual design. back-up/recovery. 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. Quality Management Plans should be developed for larger projects to guide the overall quality management process. 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. Though the project manager has overall responsibility for the quality of the final product. This may include tracing system requirements through project objectives. every team member needs to buy-in to the responsibility of producing a quality product. OIS has developed standard quality assurance review procedures and audit and interview checklists. detailed design specifications. statement of work. The team’s motivation level goes down when it has to continually repair and rework deliverables and deadlines are being missed. security.

Page 26 . the visual presentation assists in generating customer feedback early in the project. Provides simulations of what the end result might look like.5. Again. Project deliverables and documentation. Structured methods to help ensure proven processes are used. • Utilize pre-existing OIS and team processes (standards/procedures/guidelines) whenever possible. • Include basic quality control activities in the work plan including walkthroughs and reviews. 2. They will identify deficiencies and will recommend adjustments to project activities or tasks to help ensure the project satisfies relevant quality standards. Walkthroughs and peer reviews.5. specifications and quality control processes. 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. code. Project documents should be examined to assess whether appropriate information has been completed.2 Quality Assurance Quality Assurance ensures there is a good quality program in place and that it is being followed. The customer may be walked through each view a step at a time while the system is described by the project team. and if it appears work has been performed to a sufficient depth. Some new ones may also need to be developed.4. • • • 2. This could include reviews of deliverables such as designs. These projects should: • Identify quality control activities.PROJECT MANAGEMENT GUIDE • Storyboarding. It provides oversight for a project’s quality program and identifies processes that a project should follow to ensure customer requirements are met. This should include checklists to verify that all parts of a process have been completed.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. This method works well for website development where there will be lots of visual content. These may be electronic or paper. Checklists.4. Reviews should verify adherence to standards. QA reviews are conducted by independent QA teams. testing and user documentation. The QA team examines: • • Processes being followed to create project deliverables. • Get the customers involved in testing as early as possible.

Follow the OIS QA Review Procedure to request a minimal number of QAs (2 . These projects should: • • • • • Develop a comprehensive Quality Management Plan which identifies quality control and quality assurance activities including acceptance criteria for major deliverables. and customer satisfaction surveys. 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 2550% complete. This may include metrics on the amount of rework performed.3 QAs). • • Page 27 . These projects should: • • • • Develop a basic Quality Management Plan which identifies quality control and quality assurance activities. Follow the OIS QA Review Procedure to conduct relevant QAs (typically 4 –5 QAs).PROJECT MANAGEMENT GUIDE • Notify the IT management consultant upon project completion so that a Post Implementation Review can be conducted. number of errors discovered during testing. time spent on issue resolution. Gather project development metrics and analyze them for process improvements. Large Projects Large projects should include more detailed quality control and quality assurance processes. This may be the only QA conducted for a small project. Include quality control and quality assurance activities in the work plan. Develop or customize team checklists and procedures to fit the needs of the project as appropriate. Utilize pre-existing OIS and team processes (standards/procedures/guidelines) whenever possible. response time. Some new ones may also need to be developed. Include quality control and quality assurance activities in the work plan. 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. Formal sign-off and acceptance procedures for vendor deliverables should be utilized. Medium Projects Medium projects should be concerned with quality control and quality assurance. A customized checklist should be developed by the QA team for this review using pertinent questions from the Design QA checklist. A customized checklist should be developed by the QA team for this review using pertinent questions from the Development QA checklist.

. It may only be high level information. the training those groups need. The project manager should assess the skills that team members possess and identify areas where training is needed. back-up personnel for key roles should also be identified and trained. the training needs of all people that will be affected by the project must be addressed. The project manager must make sure team members. Prepare State staff to assume responsibility for continued support after implementation. and document when the training is needed in order to complete project tasks. If applicable.6. and conducting project team training.2 End User and Support Team Training The overall approach for training end users and support teams should be addressed during project planning.PROJECT MANAGEMENT GUIDE 2.4. 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. knowledge transfer.6 Training Plans A comprehensive training effort is necessary for a smooth and successful implementation of information technology projects. It is also important at this time in the process to identify the Page 28 . estimates of the number of users in those target groups to be trained. etc. The project team training plan should describe the types of training that will be provided including on-the-job training.4.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. and post implementation support teams have the training needed to do their jobs.6. 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. Just as with the Communication Plan. end users. provide for training by contractor. but it should identify target groups. 2. 2. This will allow all required project resources to be properly allocated at the times needed. stakeholders. 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. and the types of training available or to be developed for the target groups. The objective of a project team training plan is to identify the team members that need training. In addition.4. end users. It is very important during planning to identify the persons who will be responsible for developing or obtaining training materials. or for any resource conflicts to be addressed. and the training requirements for each team member. and support teams. vendor or state courses.

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. the more rigor and structure is needed to manage documents. 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. some of the processes and infrastructure for managing documents may still be relevant. 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. and for the project manager to address any resource conflicts that may occur.4. even a small project will need a common repository or directory structure to store project deliverables. when more details become known about training requirements. and can help manage the burden of risks by storing facts for future reference. the software may facilitate and resolve many of these issues. including setting up the electronic and or hardcopy project files and supporting procedures. When the FileNet document management software is fully implemented. 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. such as common naming conventions. If the project manager does not think about these processes ahead of time. and conducting end user training. so it may not be possible to structure a repository in detail. Other aspects of document management. 2. Small Projects Although small projects have fewer problems managing documents. At the start of a project. For instance. the project team will have problems finding relevant information. Following the detailed planning phase.PROJECT MANAGEMENT GUIDE resource requirements for developing the training materials. might make sense depending on how many documents are generated. the project manager may only have a high-level view of the required deliverables. the project manager will be in a better position to decide which documents would help drive the project through to a successful conclusion. A formal Documentation Management Plan is currently not a requirement of the Project Plan. It can serve to illustrate the life of a project. Medium / Large Projects The larger the project. The purpose of a document management plan is to describe where documents are created and stored. and set up a logical file repository to capture those documents. Each project manager can evaluate their own project to see which document management areas make sense to define. Document management is the management of all work products and deliverables associated with a project. Page 29 . During the Execution and Control phase of the project.7 Document Management Proper documentation is critical to a project’s success.

4. 2. On the other hand 'Joe Smith 20031201 Status Report' groups the reports by person. 2. within a status report folder. depending on the size of project.7. 2. etc. approved document that no one should touch.2 Access Rules The access rules describe things like who can review documents and who can update them.7. all the status reports for a given period would sort together.3 Logical / Physical Organization Once you know where you will store documents. If that happens. For instance the original document might be named 'ABC Project Plan v 1'.7. having a common naming standard for related documents will be very valuable as your project team generates hundreds of documents over time. The first step is to define a logical view of how the documents should be organized. you could set up a folder for final.4. This is so the team members know where documents should be stored and so the team can find documents when they are needed.4. For instance. you should be clear on which documents team members can update. 2. You can also establish work folders for each team member where they can put all their personal documents.5 Versioning The project manager should determine whether multiple versions of documents will be saved or if just the latest version will be saved.7.4 Naming Standards It can be hard to find documents even if you have a good organizational structure. the naming convention might be '20031201 Joe Smith Status Report'.7. Most documents should be accessible for the entire team to read.4. you need to implement it in the specific directory structure or tool. FileNet.PROJECT MANAGEMENT GUIDE The document management plan should address all or part of the following. Once you have agreement on this view. the team will have difficulty finding important documents when they are needed. as well as project deliverables that are in-progress. and paper file cabinet. Although this exercise might seem tedious. you should also determine the directory or folder structure. The project manager should be sure that documents are not stored all over based on the preference of each team member. the naming convention will need some type of version number. 2. The structure should be one that is easy to understand and easy to use to find relevant information. This could be the G: drive. For instance. The project team should have a common area for storing documents. However. For these documents. Some documents should have all approved versions saved.1 Document Repository Specify where the project documents will be stored.4. especially if there is turnover among members of the team. In this scheme. A common document naming standard will make it easier to find information. The document name would be changed to ‘ABC Project Plan Page 30 .

documents such as the Issues Log have all current and prior issues saved within the document. The Project Plan should be reviewed and approved by “key management” (those persons determined to be necessary for approval of the plan). whenever significant changes are made to the schedule. and there is no reason to keep separate versions. The current issues log always replaces the prior issues log. quality. On the other hand. sponsor. 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.PROJECT MANAGEMENT GUIDE v 2’ if it is revised at a later time. Page 31 . the Project Plan should be updated as necessary. scope. stakeholders.8 Project Plan Summary and Sign-Off The Project Plan is a formal project document constructed by the project manager. or any of the project management plans. People can then still refer back to the prior versions if necessary.4. and project team members with the expressed purpose of controlling the execution of the project. 2. Once approved.

For this reason the control plans include the procedures and forms the project has agreed to use. Executing the project consists of carrying out tasks. and the resources necessary for executing the starting task are assembled. During execution. but as standard templates are developed. revising plans. or taking actions to improve the performance. cost. Controlling the project requires the measurement of project performance. procedures and forms developed during project planning. and analyzing the work being done. The project manager and team’s focus shifts from planning the project’s efforts to participating in. 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. The phase begins when the project plan is approved. observing. 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. controlling. monitoring project risks. and within budget. When it is determined that the project's plans are not being met. in scope. This may include revising the project plan to reflect the actual accomplishments and re-planning the remaining work. Following a description of the execution and control of each of the project management plans. Progress is primarily determined by comparing the scope. and planning are continuous activities. There are currently no templates for the various plans discussed. Issue. Risk. the project team and stakeholders can gauge the progress of the project. plans. 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. and controlling change to the project baseline. measuring project progress. and exercising management controls to ensure that planned project activities are carried out in an effective and efficient way. The processes of executing. Quality and Training Plans). By measuring and evaluating the actual execution of project activities against the plan. they will be made available. the project management team should determine the best course of action. reporting project status. As the project proceeds.0 PROJECT EXECUTION & CONTROL The project execution and control phase is that part of a project which utilizes the schedules. Page 32 . Change Control. effort. the project team must continuously monitor its performance in relation to the project plan. Controls outlined in the project plan keep the project on schedule. communicating status. other aspects of project execution will be briefly explained.PROJECT MANAGEMENT GUIDE 3. and schedule to the plan when selected work products are completed or at selected milestones. and if appropriate.

Once the initial work plan is established. reviewing the project scope and business objectives. The focus of the meeting should be communications. It is recommended the project manager update the project work plan on a regular basis. Additionally. 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. 3. the critical path of the project will be automatically calculated. Management of the critical path is important to the success of the project. The critical path is the path with activities that cannot be delayed or the project finish date will be delayed. After updating the work plan. the work plan should be updated accordingly. If using Microsoft Project. and the way communications will be managed. they also allow the project manager to quickly spot potential problem areas.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.1 Kick-Off Meeting Moving from planning into execution can be a major obstacle in a successful project. identification of team members and stakeholders. the project manager and Page 33 . A project kick off meeting can facilitate the transition from planning activities and tasks to executing them.3 Execute the Communication Plan The Project Team and End User Communication Plans describe how project communications will occur. A kick off meeting enhances execution by focusing the team on the project and by defining a starting point for project execution. identifying the challenges. it is a milestone when all resources needed to begin execution are assembled and available to the team. the critical path of the project should be determined.PROJECT MANAGEMENT GUIDE 3. unless the time can be offset somewhere else on the critical path. 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. Frequent updates to the work plan not only save time in the long run. Feedback from project team members is used to track work done against the tasks in the work plan. Responsibilities of the project manager include maintaining a work plan in Excel or Microsoft Project that minimizes team member down time. 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. 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. A kick-off meeting can also provide an opportunity for establishing the commitment of the team and stakeholders to the success of the project. and identifying the next step in getting the project underway. During project execution. If the time remaining to complete a task in the work plan differs from the estimated time.

The project manager. and communicate any issues or concerns in an open. and stakeholders will share information among themselves and with end users using the methods defined in the Communication Plans. constructive forum. 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. Project team members must use the communications methods documented in the Communication Plans. depending on the issues. 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. These meetings are ideal opportunities for the project manager to gain insight into the day-to-day activities of project team members. During project execution. 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. and whether the plans are effective. It is the primary communication method between the project manager and the project sponsor. Page 34 . unambiguous. it would generally be used by the project manager to update the project work plan. the Communication Plans are carried out so that required information is made available to the appropriate individuals at the appropriate times. and applicable to the project. In lieu of a status report from each team member. When composing correspondence. honest. Joint project review meetings may involve the project manager. While executing the plans. the project manager should update the plans. and complete communication of information. meeting agendas and minutes. in turn. and agency management. The project manager can then use information communicated during the meetings as input for the project status report. If not. In addition to having solid Communication Plans in place.. They provide an opportunity to discuss important issues and make management decisions on the project with input from several sources. discuss their accomplishments. must be sure information is not only received correctly and completely. complete. He/she must be flexible and ready to modify the plans if portions are not working as expected or communications needs change. etc. If the communication plan requires team members to prepare a status report. Joint project review meetings are also a good way to bring visibility to all areas of the project. and when speaking with individuals face to face. Communications must be bi-directional. project stakeholders. and new or unexpected requests receive a prompt response. team members are responsible for clear. status reports. project team members.PROJECT MANAGEMENT GUIDE project team must review whether the Communication Plans are still current. The regularly scheduled project team meeting is also a good forum to recognize individual accomplishments for outstanding work. it is the responsibility of members of the project team to exercise good communication skills. 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. the project manager must be aware of how organizations will use the information. the project manager could periodically assemble the project team to review the status of the project. project team. The receiver.

If individuals are fearful of communicating issues. 3. the project manager should invoke applicable escalation procedures. the Issue Management Plan and corresponding forms are used to document. 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. It is the Page 35 . Adhering to the change process ensures that all parties agree to the change and understand its potential impact. track. Individuals should feel a responsibility to the organization to voice their concerns. if the change control process is executed and managed effectively. It is also during execution that the project sponsor or customer may realize that. Based upon potential impact. Every issue. If appropriate resources or materials are not available to complete the action items. whether technical or business related. The Issues Log is the master record of identified issues and is used to track progress toward resolution. Following the change control procedure each and every time changes are requested will test its effectiveness. the product being produced is not exactly what they need. get the customer and project sponsor accustomed to the way change will be managed. its continuing impact and the status of its action plan should be discussed at every status meeting. The Issue Paper is the means of reporting issues and is used by the project team to document the issue. should be documented.4 Manage Issues During project planning. but the issues with the highest priority should be addressed first. the issue is prioritized. and resolve issues that occur as a project progresses. The change control process also helps maintain balance between the requirements of the project and the timeline and cost. While an issue remains open. During this time. and documented the process for controlling change. despite their best efforts to thoroughly document the project scope. assess the impact of the issue. The goal of issue management is to resolve all concerns completely and promptly. the estimate of the potential impact of the issue is documented. as actual task work is being performed. It is important that the project manager enforce the change control process throughout the entire project. and the project manager must pursue issue resolution relentlessly.PROJECT MANAGEMENT GUIDE 3. the process for managing issues was agreed on and documented in the Project Plan. the resulting effect on the project can be devastating. and make recommendations to resolve the issue.5 Manage Scope and Control Change During project planning. Once the description of a new issue has been logged. Unresolved issues are one of the leading causes of project failure. Managers use the Issue Paper to assign responsibility and to document decisions on actions directed to resolve the issue. starting very early in project execution and control. Anyone involved in a project in any way can and should inform the project manager of issues. The need for change is usually discovered during project execution. and help them understand their roles as they relate to change. an approved Project Charter and Project Plan established the scope of the project. any negative effect on the project outcome should be avoidable. Although changes can be expected to occur. or if there is disagreement about any of the issue recommendations. During project execution and control. 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.

During planning. rejecting. The format for these meetings should be open and interactive to facilitate a wide consideration of risk areas. and re-evaluate risk plans. the implementation costs far outweigh the business benefit. 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. and to develop and apply new risk strategies to unexpected events. some general areas should be considered. 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. A signature is required of all approvers. dependencies. The starting point for these meetings is the risk management log. Risk identification meetings should be held as a means of identifying risks and developing ways to approach the risks. whether they are accepting. Throughout project execution and control. and customer representatives is crucial in managing change. The risk process is not just about completing the Risk Assessment and Planning Form for each risk and then forgetting about it. and resolution strategies emerge.PROJECT MANAGEMENT GUIDE 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. 3. and resolution are key tools for successfully completing the project. estimated durations. reassess old ones. the project manager must continually look for new risks. and resource requirements and availability. for example. The project manager should involve the whole project team in risk identification meetings. These are especially helpful on high-risk or complex projects. In the execution and control phase. 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. A signature of approval on the change request form indicates that the approver accepts the consequences (impact) of the request on the project. monitoring. Since risk identification. If.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 resources must be modified. the change request will most likely be rejected. If the resolution differs from the recommendation. All affected tasks. This information is documented on the change request form. risks become more defined. the approver must provide a reason. cost. The group should be given some ground rules in terms of the degree of risks that Page 36 . project sponsor. the project manager must incorporate the effect of the change into the project work plan. continuous communication between the project manager. as team members have various levels of expertise and can bring a unique perspective to risk identification. Additionally. or to manage it as it occurs. 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. the initial project risks were defined as accurately as possible in terms of their probability of occurrence and their impact to the project. Once a change request has been approved. or deferring the request. allowing for the development of a realistic risk plan for each risk.

the existing risk plan may be adequate for dealing with it. If the risk occurred as expected. Project team members need to take ownership of the deliverables they produce and ensure the deliverables are built with quality. If a particular deliverable has a quality problem. 3. There is no silver bullet for risk management on IT projects. To be effective. 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. From this meeting. not on trying to determine who is to blame. Most problems with quality are the result of poor or insufficient work processes. It must be built into the work of each individual on the team. However. and whether the project is driving toward its goal. quality control cannot rely on “adding” quality at the end of a process. correct. During the planning phase. and of high 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. 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. or other circumstances have come to bear. The agreed on activities were documented in the Project Plan. the project team must adopt a continuous quality mindset. Sooner or later. or a series of activities at the end of the process. Developing and constantly updating risk plans is the key to controlling risks. Project managers must devote themselves to identifying. with a minimal amount of errors and rework.7 Implement Quality Management Quality management activities are designed to ensure that the project team can produce high quality deliverables. or an entirely new and unexpected risk will actually occur. a new risk plan must be created to address it. Quality control is sometimes seen as a step in the process. the project manager will have an updated list of risks. and dealing with risk on a daily basis. planning for. 3. If the risk event was unexpected and unanticipated. 2. There are generally three possible response scenarios: 1. one of the events on the Risk Management Log. 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. Some criteria for risk tracking include time frame (when it would possibly occur) and value (what would be the cost if it occurred). It incorporates a process of evaluating project performance on a scheduled basis to provide confidence the Page 37 . Quality assurance (QA) reviews refer to validating the processes used to create deliverables.PROJECT MANAGEMENT GUIDE will be tracked and ways to eliminate or include risk items. the project manager and project team should focus on how the project work processes can be improved. Having plans and procedures in place to control risk events when they occur is critical to delivering projects on time and within scope. The project manager and project team members must evaluate the risk event and invoke the risk plan for that risk. However. Team members must realize that a quality process allows the entire project team to produce quality deliverables. 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 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. If the risk occurred in a different manner. the risk plan may have to be modified.

an independent QA team plays an integral role in ensuring the quality plan is executed as designed by performing QA reviews. For each team member requiring training. As a result of implementing quality management. and what the project impact could be if something did go wrong with the process. Accordingly. If new team members have joined the project since the Project Team Training Plan was established. and would have been used to document the known tasks and resources in the work plan. the project manager may want to use a training log for project team members to document the names and actual training completion dates. 3. the project manager must evaluate the skill level of the new members to determine if additional training is needed. If additional training is necessary. while it is important that each team member be responsible for quality control. Also during project planning. if applicable. and determine whether a formal documentation plan should be considered. Discussions could include ideas about things that could go wrong. 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. 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. As training takes place during project execution. 3. and documented the requirements in a Project Team Training Plan. and the approximate date or timeframe the training is needed in order to keep the project on track. A common problem in many “time-challenged” projects is that reasonable training was not provided for in the Project Plan. the project manager included the type of training the team member needed. 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. the project manager should re-evaluate the amount of documentation that may be produced by the project. it should be added to the appropriate plan. the project manager must review the contents of the training plans to be sure they are still applicable. During project execution. 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. If it is determined that planned training is no longer necessary. Following is a list of project related documentation that may or may not be applicable: Page 38 . 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.8 Execute the Training Plans In developing the Project Plan. This plan documents the activities and resources needed for developing training materials and conducting end user and support team training. it must be removed from the plans.PROJECT MANAGEMENT GUIDE project will satisfy the relevant project standards and meet scheduled timeframes. what the likelihood is of that occurring.9 Manage Project Documentation If a formal documentation plan was not developed during project planning. the project manager should have created a high-level End User and Support Team Training Plan.

PROJECT MANAGEMENT GUIDE 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 Technical Architecture Design Conceptual Design Proof of Concept or Prototype Detail Design Specifications Coding Approach Development Documentation Test Results User Training Materials • Course Materials • Tutorials User Documentation • Guides Pre-Implementation Documentation Cutover Plan Deployment Plan Page 39 Conversion Approach Testing Plan Organizational Change Management Plan User Documentation Plan System Documentation Plan • Quick Reference Cards System Documentation • System Administration Guide • Technical Maintenance and Support Guide .

When team members understand the importance of interacting with each other. competing demands for a document. The project manager should keep track of document status.1 Manage the Project Team Human resources are vital to project execution and as a project manager. they are more willing to identify and proactively deal with conflict. 3.10. When team members are encouraged to do their best and are motivated about a project.10 Other Aspects of Project Execution 3. Project team members should be able to access. authorities and controls. They must recognize that there is more to team-work than simply having team members feel good about each other. As documents are generated during project execution. completed work where the documents have not been finalized. the project manager is ultimately responsible for maintaining a project document repository. controlled version of a document. documents that are unnecessarily checked out. A positive team environment enhances project performance. and team members not working on the correct. Project team members must learn to work together to achieve project goals.7 of this guide. The primary objective for establishing an appropriate team environment is to improve overall project performance. 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.4. and “check in” documents. Page 40 . At the very minimum. Control of documentation during the project should be made as easy an efficient as possible. refer to Section 2. update.PROJECT MANAGEMENT GUIDE 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. the project manager should have guidelines describing where documents are stored and rules concerning responsibilities. The project manager should monitor the overall process of managing the project’s documentation and deal with issues as they arise. Resolving issues early leaves team members more time for producing actual project work. success in leading a team depends on leadership skills. Stakeholders should be able to easily find and access documents. paying close attention to: • • • • • documents that are not at their planned stage of completion. “check out”.

Determine when and how to address delays that impact the critical path. events and activities are communicated in a timely manner Page 41 . 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. Discuss methods of handling an extended period of overtime requirements.2 Manage Vendors When the work on a project is partially or fully contracted with vendors. Team members participate in all required meetings.10. Encourage the employee to help in the resolution of the problem. Make sure feedback mechanisms are in place to promote early detection and resolution of issues.10. Following are some guidelines for proactively managing team performance: • • • • • • • Define expectations and hold team accountable for meeting those expectations. This is the essence of project ownership. take their assigned tasks seriously. Use facilitation and coaching techniques to involve team members in problem resolution. 3. 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.PROJECT MANAGEMENT GUIDE Highly effective project teams are either empowered to make decisions or are included in decision-making processes. 3. Determine how to best handle team performance issues such as a team pulling in different directions. Determine if the communication plan is working well between the vendor and the project team. Address issues of team skill gaps and devise a plan to increase performance. are willing to suppress their egos for the good of the group. and continuously strive to improve their skills. Manage individual performance by interviewing a problem employee to try to determine the cause of the problem and the solution.3 Plan for Organizational Change Organizational change is the impact the project will have on end users in terms of people and processes. vendor relationships are crucial. Ensure that status reporting occurs as predetermined and take appropriate corrective action when variances are detected. 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.

as appropriate. must be managed in coordination with project development. key stakeholders should be given a "preview" of how the product will actually work. and training events that can be targeted to specific audiences affected by the changes. Plans must be updated as necessary to reflect new requirements. Most likely. but is not limited to: • • • Monitoring design and implementation activities and making any necessary adjustments. the activities needed will include communication. In preparation for implementation. Monitoring training activities and making any necessary adjustments. all involved parties must be made aware of the anticipated timing of events to give them ample time to prepare and participate as required. 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. The project manager must recognize and manage these particular aspects of the project with diplomacy and tact. These activities should be documented in the communication and training plans. 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). Managing the steps that need to be taken to ensure the appropriate individuals are ready to support the product. A support team is any key stakeholder group whose employees are most directly involved in supporting the product. With the implementation of a new IT application. either in terms of technical support or functional support (such as help desk and problem resolution). the project team should develop a good understanding of the impact the project will have on the support team(s). Operational Transfer and Support During project execution and control. Planning for implementation and operational support includes. In cases where implementing a project will result in a significant change to the way an agency conducts its business.4 Plan for Implementation. and the development of corresponding procedures. These activities should begin to prepare the support team(s) to support it. This may include negotiating with various internal organizations to determine the appropriate timing of the transition of responsibility. The active involvement of the project sponsor may also be required for implementing organizational changes across organizations and business units.PROJECT MANAGEMENT GUIDE 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. New processes must be integrated during project development. assigning specific agencies or individuals to support the specific products. a full-time person dedicated to organizational change management may be required to fulfill the critical nature of this role. 3. and providing necessary training. To the greatest extent possible. and also be given adequate training on how to adjust to change or how to work in the new environment. to coincide with or precede the implementation. Page 42 . 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.10. and document the specific activities that will adequately prepare the owner agency and end users to accept and use the product. the project manager must anticipate when and how the major impacts will occur. For large projects. The redesign of existing business processes affected by the implementation. education.

"help" or trouble calls. The project manager must ensure that all documents or records that will be provided with the product are produced. the project manager must be sure each required activity is carried out according to the schedule. Page 43 . Overall. The project manager takes responsibility for production problems. and for resolving the problems.PROJECT MANAGEMENT GUIDE The project manager must carefully manage the development effort to know when the support team should become involved in the project. and to immediately communicate any discrepancies. • Managing production of all necessary documentation.

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.0 PROJECT CLOSEOUT Project Closeout is the last phase in the project lifecycle. and processes that could be improved. and bringing closure to project activities.PROJECT MANAGEMENT GUIDE 4.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 problems encountered must be openly presented. Each person attending the session should contribute a comment or observation about the project. Conducting a “lessons learned” session can be a valuable closure mechanism regardless of the project's success.1 Prepare Project Closure Report The following tasks are performed by the project manager. Responsibility and ownership for problem areas are critical to developing useful recommendations for future projects and processes. The project manager is responsible for creating a Project Closure Report to formalize the end of the project. and it is important that problem discussions do not merely point a finger at some target.1. 4. 4. As project phases come to an end. and derive best practices. For a lessons learned session to be successful. and QA team for the purpose of assessing the effectiveness of the project. gain consensus on what was successful and what was not. it is certain no one will benefit at all if the lessons learned and best practices are not communicated and disseminated across the organization. Even though it may be impossible to assess now how much future projects will benefit from lessons learned and best practices. efforts should shift from deliverables and implementation to equally important tasks and deliverables associated with successfully ending the project. project team. 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. The fact that project closure appears at the end of the project does not mean all project closure activities must be delayed until then. The major outcome of this phase is the Project Closure Report. Page 44 . OIS has developed a Project Closure Report template for this purpose. The project manager should meet with all members of the project team and appropriate OIS managers to discuss all aspects of the completed project. OIS has developed a Post Implementation Assessment template to assist the project team in identifying processes that worked well. it is important to conduct milestone reviews to ensure that phase activities have been successfully completed to the satisfaction of all involved. The assessment should be distributed prior to the session so team members have ample time to prepare their comments or observations.

In order to close a contract. or if there are any contracts that need to be officially brought to closure. 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.1 Archive Documentation Completing the documentation and archiving the project records is the least exciting part of project closeout. During project closeout. The Post Implementation QA Report.PROJECT MANAGEMENT GUIDE 4. or what contingencies to perform in the event there is work left uncompleted. 4.1. and any outstanding invoice or payment issues.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. issues raised and correspondence exchanged have been completed and properly stored. If they are not going to complete on time.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.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. The findings of the QA Team will be documented in a Post Implementation QA Report.1. the project manager should review the status of any contract to ensure the contractor is on target for completing all required services and deliverables. once the project comes to an official close. decisions made.3 Prepare Project Closure Report After the lessons learned session(s) and QA interviews are conducted. the project manager must determine if a contract amendment (to extend the contract period) is warranted. Page 45 .2.2. A thorough review of the contract documents should include contract milestones. a good repository provides an audit trail documenting the history and evolution of the project. and QA Response Memo if applicable. are attached to the Project Closure Report. However. 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. 4. and how well the needs of the customers have been met. 4. or any number of services supplied during the project. the project manager prepares a Project Closure Report. the project manager should examine the repository to ensure that all relevant projectrelated material. services provided or deliverables. These contracts may have provided technical support. consulting. documentation delivered. The most effective way to determine these measures is to solicit feedback. It may also contain recommendations for improvement to be used by other projects of similar size and scope. The Project Closure Report documents the effectiveness of the project and lessons learned and best practices to be used in future projects. documents produced. Approximately 60-100 days prior to the end of the contract. such as for early contract completion.

and accepted. or a congratulatory cake to commemorate the event. 4. 4. There are also informal ways to celebrate project completion such as an after work gathering.2. Page 46 . management may want to formally express recognition of the team at a key meeting or a large gathering of staff.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. and that the project is essentially over.4 Celebrate Project Completion Rewarding success is an effective management tool. and it is important to recognize teams that have successfully completed a project. a formal evaluation of contract performance and an assessment of the utility of the final product must be documented on a Performance Evaluation Report.2. tested.PROJECT MANAGEMENT GUIDE Within sixty days after completion of performance under a consulting contract. When a project is completed. Such recognition sets the stage for future successful work.

languages. databases and tools. Well defined and simple to convert No (or minimal) customization is needed The product or release is stable The vendor is familiar in this market High Risk Poorly defined Poorly defined Not identified or not enthusiastic Passive and hard to engage Little experience on similar projects Dispersed at multiple sites Not familiar and will not be utilized Very vague or very complex Available on a 24 X 7 basis New and complex Complex More than four More than five More than five Greater than 5000 hours Longer than one year Not well known by the project team Three or more outside teams or projects Substantial change Substantial change New software.000 hours Less than three months Well known by the project team Zero or one outside project or team Little or no change Little or no change Existing software. languages. committed and enthusiastic Passionate and enthusiastic Similar experience on multiple projects Located together Familiar and will be utilized Understood and straightforward Windows of availability and downtime Similar to others in the company Simple One One or none One or two Less than 1. hardware. policies require: Changes to the organizational structure require: The technology being utilized consists of: The quality of current data is: If a package implementation: Low Risk Well defined Well defined Identified. databases or tools (or new releases) Poor or complex to convert Heavy customization is needed The product or release is new to the market The vendor is new to this market Page 47 . procedures.PROJECT MANAGEMENT GUIDE APPENDIX A: PROJECT RISK FACTORS Medium Risk Characteristics The business benefit of the project is: The scope of the project is: The project sponsor is: The business customer commitment level is: The Project Manager has: The project team is: Project management processes and procedures are: The business requirements of the project are: The system availability requirements include: The technical requirements are: The data requirements are: The number of locations to deploy to is: The number of system interfaces are: The number of organizations this will impact is: The total estimated effort hours are: The total estimated project duration is: The subject matter is: The project is dependent on: Business processes. hardware.

what type of information is required Clearly define what is out of scope for the project Begin to define business requirements at a high level.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE High Risk Factors / Potential Problems The business benefit of the project – Poorly defined Project is in jeopardy of being placed on-hold or cancelled if higher value work is identified Harder to get resources required Hard to evaluate the value of the project to the organization 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 Hard to provide sound estimates May spend time and cost on areas out of scope Hard to gather concise requirement Difficult to write project definition and work plan Hard to invoke scope change procedures Project deliverables are poorly defined Risk Management Activities Try to get business customer to quantify the overall business value of the project Look at the major requirements and try to quantify the value of the various deliverables Document the intangible benefit that the project will achieve Review prior similar projects to see how the benefits were quantified Don’t start the project while the business value is undefined Focus on firming up scope in the planning process Define various components of scope such as what organizations are impacted. what deliverables are expected. 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 Establish a strong steering committee to help guide the project Establish a process for resolving disputes between organizations Try to identify a different sponsor Ask the sponsor to delegate full authority to another person who can act on their behalf Don’t start the project Create an aggressive Communication Plan to keep customers engaged and communicate the business benefit Create User Group to surface concerns and build enthusiasm Ask for customer participation in planning and requirements gathering 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 The project sponsor is – Not identified or not enthusiastic Project may not get the resources it needs Project may not have the long-term commitment needed Political battles may delay the project Issues and change requests may not be resolved in a timely manner Customer commitment level is – Passive / hard to engage May point out low confidence in the business value Harder to get customer time and resources needed Harder to gather business requirements Customers may undermine or work against the project Page 48 . and then work upward to define scope Ask project sponsor to make decision on conflicting scope statements Document all scope assumptions when providing estimates of work.

scope changes may be Solicit input on issues. including complex and harder to manage issues management. Assign an experience project management coach or mentor to the project scope changes and risks 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 Define and gain approval for a set of project management procedures before the project starts. change management. and can provide feedback Project deliverables might be completed in different formats Issues may not be addressed in a timely manner. 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. causing rework and project delays More difficulty organizing and managing a complex project May not be familiar with sound project management practices May not know when to call for help Project team is located in – Dispersed locations Harder to communicate effectively Less team interaction and cohesion Harder to build personal relationship with the entire team Some members may feel isolated and not a part of the team Technology problems may result in productivity decrease Provide up-front project management training Designate a more senior person to coach and mentor the project manager Break the project into smaller pieces that are easier to manage Put a strong quality assurance process in place to ensure the project is on the right track Make sure the major deliverables are formally approved Utilize strong team leaders and team members to bring additional experience to bear Try to get the team into one location. that all team members can access Provide training to the project manager and project team on sound project management processes and Project management processes – Not familiar or will not use procedures Team may have a difficult time understanding how to raise issues. at least for the length of the project Create an aggressive Communication Plan to ensure the team communicates effectively Hold regular meetings where the entire team meets face-to-face Schedule team-building activities where the entire team meets face-to-face Have backup methods to communicate if the primary technology fails Maintain frequent contact by phone with remote team members Create a central repository to hold the project documentation. risk. risk management and quality management Communication will tend to be poorer Create solid communication plan to ensure everyone knows what’s going on.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Project management experience – light May take longer to define the project and build work plan May make more mistakes in judgment. and that a change management procedure is enforced after that Page 49 . 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.

testing and overall quality assurance activities Focus extra time and energy on technology architecture Focus more time and energy on database design Use industry best practices for all technology and process components Provide appropriate training to the team so they understand the 24x7 implications on the project Determine exactly what portions of the system have a 24x7 requirement 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 Utilize system and technical design documents to clearly lay out how the technology fits together The technical requirements are – new and complex 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. construct and test Gather requirements from all locations you will deploy to The number of locations to deploy to – Many 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. design. 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 Reduce the need for interfaces when possible Number of system interfaces – Many 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. 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 Utilize an automated tool to capture data elements and the relationships The project data requirements are – Complex 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.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Allocate more time to analysis.e. 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 The system availability requirements are – 24x7 Downtime problems may result in productivity decreases or loss of revenue Redundancy may be needed. XML) More chance for incompatibility Break the project into smaller sub-projects with fewer interfaces to manage Harder to track down problems. design. which increases system complexities Newer advanced technology may be required More procedures and processes are needed to maintain the system environment Page 50 .

so that change management can be invoked afterward Make technical design and architecture decisions as flexible as possible to account for potential changes Take as much training as practical.Long Harder to manage to the schedule Easier for the team and the customer to drift or lose focus More chance that project will lose organizational commitment More chance business requirements will change More chance of change in software or hardware versions Difficult to instill sense of urgency at the beginning of project More chance of team and customer turnover Establish a formal approval process Create a Steering Committee to represent the entire stakeholder community Keep the sponsor engaged and ready to intervene in the various organizations Include representative from each organization in requirements.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Number of organizations that are impacted – High Coordination is more complex Approvals can be more cumbersome and lengthy More difficult to reach consensus More people and groups to involve in planning and requirements Harder to know the major stakeholders of the various organizations Implementation is harder and more complex Total estimated effort hours – High Implication of a high number of effort hours is that there are many people involved and more complexity Harder to communicate effectively with the team Bottlenecks can occur when decisions are needed quickly More chance of people problems Increased chance of turnover More people to train Total estimated project duration . quality and risk management Break the project into smaller. Instill a sense of urgency from the start of the project Organize team-building activities to build cohesion and reduce friction Ensure all major deliverables are formally approved. as early on as possible Bring the key customers onto the project team Spend extra time understanding and documenting the requirements Set up approval process for requirements that require multiple subject-matter experts Use joint application design (JAD) session to gather requirements from all stakeholders together Utilize more frequent walkthroughs and include the users Build extra time into the estimates for application analysis and design activities The subject matter is – Not well know by the project team Longer learning curve for project team members The project may slip behind in the early portions of the project No sense for whether business requirements make sense Possibility that critical features or functions will be missed Ned to initially rely on customer for all subject-matter expertise Page 51 . quality assurance and testing Include opportunities for people from the various organizations to meet and interact Work with the team on strict adherence to overall project objectives and priorities Use consensus-building techniques when at all possible Use a project management tool to control resource utilization Have team members utilize weekly status reports to report on progress against their assigned work plan activities. Utilize team leaders to manage sub-teams Organize team-building activities to build cohesion Schedule status meetings to keep people informed of project status Utilize structured internal procedures for scope. shorter sub-projects Identify clear milestones to check that the project is on schedule Be diligent using formal change management procedures Rotate team members into different roles to keep up the interest level Strive to get ahead of schedule as early as possible. per day to recognize additional people and team related activities Break the project into smaller. issue. shorter sub-projects Reduce available project work time per person.

PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Dependency on outside projects or teams – Many Delays in the other projects/teams could delay your project Changes to deliverable from other projects/teams could force your project to make changes More complexity involved in requirements. as early as possible Train everyone who needs to install. which will lead to project delays New tools can lead to longer delivery times New technology may require substantial conversion efforts System performance may be poor while expertise is gained in optimizing and configuring the technology Document all current policies and processes and ensure that they are correct Communicate precisely how the new processes differ from the old ones Communicate potential changes as far in advance as possible Ensure the customers are creating defining the process and policy changes Have one person responsible for all process and policy changes Create an aggressive Communication Plan to keep customers engaged and informed Use the new processes in a pilot test or prototype first. processes. technology More people and groups to communicate effectively with Harder to build consensus. and look for ways to mitigate the concerns. etc. features and capabilities Create procedures and standards for how the new technology should be utilized Create a pilot test or prototype to utilize the new technology in a small way at first Page 52 . longer time for decisions that impact multiple groups Business processes and policies require – Substantial change Policy changes could delay the project People will be confused with new processes. to ensure they are workable and correct Include the successful implementation of new policies and processes as part of the performance criteria for managers Be open to customer input on process changes – for better ideas and to allow them to feel they have impact Document the concerns that come out of a new organization. More chance of incompatible standards. Communicate early and often about the potential for change and the business reasons for it Involve representatives from all stakeholder areas in the organizational design and options Get Human Resources involved to deal with potential people issues Provide as much training on the new technology as practical. design. when needed Use outside consultants who are familiar with the technology Make sure there is an adequate test environment where the technology can be utilized without impacting production Ensure that solid analysis is completed regarding the new technology functions. which will effect their ability to utilize the solution Possibility that new processes will not be fully integrated at first Possible void if new processes don’t fully cover all contingencies System functions may not be used if not supported by correct procedures Substantial change in processes may result in destructive behavior Be very specific in defining how other projects/teams impact your project Be very specific on the timing for when deliverables are needed form other projects/teams Establish central contacts as the focal points of communication between the projects/teams Include the dependent projects/teams in your status reports and meetings Continually communicate expectations from the other projects/teams Changes to organization structure – Substantial Organizational uncertainty can cause fear in the organization People may not focus on project if they have organizational concerns People may fear loss of jobs in a new organization 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) Learning curve may result in lower initial productivity May be integration problems between old and new technology Resistance to technology changes may cause the project to be delayed May be difficulty testing the new technology Technology may not be installed or configured correctly. testing. use or support the new technology Make arrangements to rely on vendor technical specialists.

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 Schedule training on the package as early in the project as possible Package implementation – New product or release Greater chance of problems surfacing Add an internal resource. Ask whether the 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 Consider other packages Package implementation – Heavy customization 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. or a consultant. 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 Make sure that all agreements with the vendor be in writing Package implementation – New vendor 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 The quality of current data is – Poor and difficult to convert More work to convert the old data to the new system Scrubbed data may still cause problems in the new system Data conversion problems can cause significant project delays Page 53 . with prior product experience onto the project.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Make sure that all the old data elements are correctly mapped to the new system Test the conversion process out rigorously before proceeding with final conversion Determine if the cost and trouble associated with the converted data is worth the value.

prepares a QA Response memo Project Manager prepares Project Closure Report and attaches Post-Implementation QA Report. and contract Performance Evaluation Project Manager archives project documentation Project Manager obtains project acceptance and sign-off on Project Closure Report * For contractor led projects. contractor’s project manager (PM) may perform this task. Project Manager prepares contract Performance Evaluation Project Manager reviews Post-Implementation QA Report and if necessary.PROJECT MANAGEMENT GUIDE APPENDIX C: PROJECT CLOSEOUT PROCESS FLOWCHART 60-100 days prior to contract expiration Conducted about 6 weeks after implementation Project Manager reviews contracts for closure QA team conducts PostImplementation Audit Conducted within 4-6 weeks after implementation QA team interviews Project Manager and primary user(s) Project Manager * conducts a “Lessons Learned” session with project team and OIS management and documents recommendations for future projects QA team prepares PostImplementation QA Report Must be completed within 60 days after contract expiration. Otherwise. QA Response Memo (if applicable). Page 54 . State PM is responsible.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->