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

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

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

0 1. This is necessary not just to ensure that the best choices are made. but it is critical to ensuring the acceptance of those choices by management and end-users. behavior. and the appropriate OIS IT Procurement Manual or OIS RFP/Contract Procedure Manual for the process. It will establish the initial scope of the project by defining the work that is to be included or not included in the project. Page 7 .These relate to the time. Objectives can be described in two different ways: • • Hard Objectives . Refer to OIT Guideline GUI-001 to determine whether OIT approval is required. The charter should also define the project’s objectives.000 will require initial approval by the Office of Information Technology (OIT). It should explain what problem or opportunity exists to improve a business function and provide the evidence that proves the problem or opportunity exists. Soft Objectives . including hardware and software. expectations.PROJECT MANAGEMENT GUIDE 1. and communications.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. resource requirements. Estimated project costs. 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 INITIATING THE PROJECT Project Concept The Project Concept is the foundation for initiation of the project. cost. and which may include attitude. 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. and an implementation time frame should also be identified. which are those criteria within the project that will determine whether the project is a success or a failure. and operational objectives (scope) of the product or process. 1.These relate more to how the objectives are achieved. The purpose of the Project Concept is to provide high-level information that describes the characteristics of the product/process to be created.

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

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

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

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

or By Deliverables. and maintenance. Define a baseline for performance measurement and control. then it should be further broken down into sub-activities to provide clarity. transition management. training. Examples: • • • Traditional High level Timeline (Planning/Analysis/Design/Construct/Test/Implement). it should probably be broken down into one or more work packages. they should be logically sequenced to reflect the way the work will be performed. The project manager is responsible for defining all top level tasks associated with a project and then further decomposing them as planning continues. 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. the Quality Management Plan. 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. Activities should represent unique work that can be distinguished from other assignments and can be identified and fully understood by those assigned the work. The idea here is that you don’t want to track anything that takes less than a day. Facilitate clear responsibility assignment.1 Define and Sequence Tasks and Document Tasks Relationships Defining the project’s work activities is done by subdividing the major deliverables (as identified in the scope statement) into smaller. more manageable components in order to: • • • Improve the accuracy of time. the activity should be further broken down into sub-activities. and resource estimates. If not. i. 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. installation. but if it takes more than 10 days to complete. requirements. Page 11 . If not. It is imperative that a high-level WBS be fully decomposed into manageable and assignable work packages because the WBS serves as a critical input to many of the project planning documents. Some useful tips for determining if your level of breakdown is sufficient: • • • • Activities should be able to be completed by the same person or group of people. implementation. Sequencing establishes the dependencies among the tasks and milestones and is used to calculate the schedule to deliver the product. The decomposition of the major deliverables into work activities and then tasks is referred to as the Work Breakdown Structure (WBS).e.PROJECT MANAGEMENT GUIDE 2. or By Functional Tasks The WBS reflects activities associated with overall project management. After the tasks and milestones to deliver a product are determined. testing. Activities should have a clearly defined duration or a total effort that can be scheduled.3. design.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 .

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

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

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

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

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

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

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

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. languages. hardware. databases and tools. hardware.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. 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. procedures.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. 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 .

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 type of information is required Clearly define what is out of scope for the project Begin to define business requirements at a high level. 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 . what deliverables are expected. 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.

and that a change management procedure is enforced after that Page 49 . 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. risks may be ignored and quality may be compromised Chance that the project may be in trouble before it is recognized The business requirements of the project are – Vague or complex Use joint application design (JAD) session to gather requirements from all stakeholders together Difficult to document the requirement properly Utilize prototyping and iterative development techniques to assist users in discovering the requirements Difficult to use tools to document the requirements of the new system. Difficult to understand what the expectations of the project are Get access to the sponsor and senior management people to provide overall guidance Chance that the resulting solution will not meet business need Provide training to the customers on how to think about and express business requirements May be a sign of a lack of focus from the customer Ensure that the final business requirements are approved in writing. including complex and harder to manage issues management. risk management and quality management Communication will tend to be poorer Create solid communication plan to ensure everyone knows what’s going on. 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. scope changes may be Solicit input on 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. 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. scope change and quality concerns on an ongoing basis adopted without thought of impact to the project. risk. change management. and can provide feedback Project deliverables might be completed in different formats Issues may not be addressed in a timely manner.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.

XML) More chance for incompatibility Break the project into smaller sub-projects with fewer interfaces to manage Harder to track down problems. errors and bugs Work early to set expectations regarding the need for knowledgeable resources from the other systems Test the interfaces as early in the project as possible Add extra analysis to ensure the needs of the interfaces are well understood Include the people that support the interfaces in the official communication and status reporting The system availability requirements are – 24x7 Downtime problems may result in productivity decreases or loss of revenue Redundancy may be needed. 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. which increases system complexities Newer advanced technology may be required More procedures and processes are needed to maintain the system environment Page 50 . 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.e. design. 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.PROJECT MANAGEMENT GUIDE APPENDIX B: RISK MANAGEMENT STRATEGY TABLE Allocate more time to analysis. 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.

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 . 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. 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. quality and risk management Break the project into smaller. per day to recognize additional people and team related activities Break the project into smaller. 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 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 Reduce available project work time per person. issue.

and look for ways to mitigate the concerns. 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. More chance of incompatible standards. processes. 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. 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. design. 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. 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 . testing. 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. technology More people and groups to communicate effectively with Harder to build consensus. 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. use or support the new technology Make arrangements to rely on vendor technical specialists. as early as possible Train everyone who needs to install. etc.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.

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. 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. 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 . 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. 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. or a consultant. with prior product experience onto the project.

contractor’s project manager (PM) may perform this task. State PM is responsible. Otherwise. prepares a QA Response memo Project Manager prepares Project Closure Report and attaches Post-Implementation QA Report. Page 54 . 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. Project Manager prepares contract Performance Evaluation Project Manager reviews Post-Implementation QA Report and if necessary. QA Response Memo (if applicable).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.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times