Project management Framework

Ohio State University—Office of the CIO

The Ohio State University

Office of the CIO

Project Management Framework

DRAFT Version 1.00 July 27, 2004

Prepared by: Office of Project Management Services

Reena Chaba & E.J. Shaffer

CIO Workgroup Contributors: Linda Ayres, OIT/Partnership Management

Linda DeBula, OIT/ATS Glenn Donaldson, OIT/ADS

Bill Karl, OAA/OUS Nanci Gobey, OIT/ADS Cindy Gray, CIO/TELR

Jamie Lambert, OIT/UNITS David Lindstedt, CIO/OPMS

External Consultant:

Bob Wysocki, Enterprise Information Insights, Inc.

Project Management Framework Draft V.1.00 Page 1 of 136


Introduction The project work environment within the Offices of the CIO and the Ohio State University customers we support is dynamic and fast-paced. Our projects must deal with dynamic business scenarios and sometimes unclear customer requirements. It is the Project Manager’s job to manage uncertainty and change in a manner that does not negatively affect the outcome of their projects. The OSU CIO Project Management Framework was built to make the Project Manager’s job a little easier. This framework contains definitions, guidelines and templates for the various project management activities undertaken to deliver successful projects. We live in very tight fiscal times, short-staffed organizations, burgeoning requests for our services, and often times unrealistic schedule deadlines. Given this environment, we simply cannot afford to perform activities that do not add value to the final deliverables of our projects. As such, our project management approach was designed to support our ability to complete quality work at the lowest cost, in the shortest period of time, with the requisite level of quality. The project management processes focus on those activities, which are clearly value-added. The Offices of the CIO has built the Project Management Framework, which is a customized project management methodology, in order to enable project leaders to focus on those processes that bring value. Our methodology:

• Provides a common language for communicating about the function of project management within the organization,

• Encourages appropriate communication and planning prior to the start of project work,

• Establishes a means for managing projects more efficiently, • Enables the tracking of progress against pre-determined metrics and facilitates

standardized reporting, • Leads to effective project outcomes which achieve institutional objectives, and • Builds on a set of best practices learned over time.

The methodology development process was guided by the following objectives:

• The design should seek to be reasonably comprehensive, flexible, and accessible; • The content will enforce discipline but not disallow application of a manager’s

critical judgment and insight, The Framework will provide a clear communications vehicle about project management, inform key stakeholders about the process, and enable all participants to mitigate project risks. The framework establishes common ground for all projects within the Offices of the CIO at the Ohio State University. With the glossary of Project management terms, it will also ensure common terminology between different areas within the university. The long-term intent is to build a project management repository to document best practices, lessons learned, and examples of various documents that may be developed during a project.



A great number of people within the university have been planning, managing and executing projects for a long time. The framework exists to help build on our successes and learn from our failures. It is meant to grow our project management capabilities over time. It is important to note that the framework is meant as a guide; it is not rigid and can be tailored to suit your project’s requirements. In order to follow the framework, one must first understand the project classification process. Project Classification All projects can be classified into a category based on the amount of work effort and risk. A small project would fall into Class 1 while a big project would fall into Class 5. Why classify?

• “One size doesn’t fit all” when it comes to managing projects • The amount of documentation and required project management activities must

scale to size of project How do we classify?

• Size is determined based on work effort, represented by the estimated number of person-hours required to complete the work (not duration) and the budget for staff resources, both internal and external to the organization.

• It is not necessary to use actual staff salaries in calculating internal cost. A blended rate for the department can be used.

• The point of estimating staff costs is that staff time is not “free.” Considering the Project Risk Although work effort and staff budget are good indicators for the amount of project management that should be expended, certain factors can also bring about the need for the application of more robust project management practices. The Risk Matrix identifies five risk factors to be evaluated once the initial classification level is determined. In the event that the total risk score is greater than 10, the classification level could be increased. 5 Phase Project Life Cycle The Project Life Cycle has been divided into 5 phases:

• Define • Plan • Launch • Execute • Close

Each phase has activities associated with it. Each activity has an activity definition, guidelines and may have a template. These components facilitate the activities performed by the Project Manager.



Project Classification—Framework Requirements Matrix The number of activities recommended depends upon the class into which the project is categorized. A class 1 project will involve only a few of these activities. A class 5 will involve all the activities in the framework. Also the activities recommended for each class are the bare minimum and it depends upon the discretion of the Project Manager to perform other activities (even if they are not recommended) if s/he feels that the activity is required for the project. The Framework Requirements matrix shows how the activities are currently mapped to the project classes.



TABLE OF CONTENTS Introduction ...........................................................................................................2 OSU CIO Project Management Framework..........................................................8 Project Classification—Sizing Matrix.....................................................................9 Project Classification—Risk Matrix .......................................................................9 Project Classification—Framework Requirements Matrix ...................................10 DEFINE Phase—Activity Overview.....................................................................11 PLAN Phase—Activity Overview.........................................................................13 LAUNCH Phase—Activity Overview ...................................................................17 MANAGE Phase—Activity Overview ..................................................................18 CLOSE Phase—Activity Overview......................................................................21 Project Request Approval—Activity Definition ....................................................22 Project Request Form Template .........................................................................24 Project Request Approval—Guidelines...............................................................26 Project Overview Statement—Activity Definition.................................................27 Project Overview Statement Template................................................................28 Project Overview Statement—Guidelines ...........................................................29 Business Case—Activity Definition .....................................................................31 Business Case Template ....................................................................................32 Business Case—Guidelines ...............................................................................34 Project Governance—Activity Definition .............................................................37 Project Governance Document Template ...........................................................38 Project Governance—Guidelines........................................................................39 Phase Gate—Activity Definition ..........................................................................41 Phase Gate Form Template................................................................................42 Phase Gate—Guidelines ....................................................................................43 Planning Kick-off Meeting—Activity Definition ....................................................44 Planning Kick-off Meeting Agenda Template ......................................................45 Planning Kick-off meeting—Guidelines...............................................................46 Project Approach—Activity Definition..................................................................47 Project Approach Document Template ...............................................................48 Project Approach—Guidelines............................................................................49 Quality Strategy—Activity Definition....................................................................52 Quality Strategy Template ..................................................................................53 Quality Strategy—Guidelines..............................................................................54 Work Plan- Work Breakdown Structure—Activity Definition................................56 Work Plan—Work Breakdown Structure—Guidelines.........................................58 Work Plan—Estimating Time and Cost—Activity Definition ................................60 Work Plan—Estimating Time and Cost—Guidelines ..........................................61 Work Plan—Schedule Development—Activity Definition ....................................62 Work Plan—Schedule Development—Guidelines ..............................................63 Risk Management Strategy Plan—Activity Definition..........................................65 Risk Management Strategy Plan Template.........................................................66 Risk Management Strategy Planning—Guidelines .............................................67 Communication Management Plan—Activity Definition ......................................68 Communication Plan Template...........................................................................69 Communication Planning—Guidelines................................................................70 Issue Management—Activity Definition...............................................................71



Issue Management Plan Template .....................................................................72 Issues Log Template...........................................................................................73 Issue Management—Guidelines .........................................................................74 Quality Assurance Plan—Activity Definition........................................................75 Quality Assurance Planning Template ................................................................76 Quality Assurance Planning—Guidelines ...........................................................77 Resource Plan—Activity Definition......................................................................78 Resource Plan Template ....................................................................................79 Resources Planning—Guidelines .......................................................................80 Procurement Planning—Activity Definition..........................................................81 Procurement Plan Template ...............................................................................82 Procurement Planning—Guidelines ....................................................................83 Operational Transfer Plan—Activity Definition ....................................................85 Operational Transfer Plan Template ...................................................................86 Operational Transfer—Guidelines.......................................................................87 Integrated Project Plan—Activity Definition.........................................................88 Integrated Project Planning—Guidelines ............................................................89 Team Assignment—Activity Definition ................................................................90 Team Assignment—Guidelines ..........................................................................91 Launch Kick-off meeting—Activity Definition.......................................................92 Launch Kick-off Meeting Agenda Template ........................................................93 Launch Kick-off Meeting—Guidelines .................................................................94 Initial Risk Identification—Activity Definition........................................................95 Risk Management Matrix Template ....................................................................96 Initial Risk Identification—Guidelines ..................................................................97 Team Readiness—Activity Definition ..................................................................98 Team Readiness—Guidelines ............................................................................99 Performance Tracking & Reporting—Activity Definition ....................................100 Project Status Report Template........................................................................101 Performance Tracking and Reporting—Guidelines...........................................103 Schedule Control—Activity Definition................................................................104 Schedule Control—Guidelines..........................................................................105 Change Control—Activity Definition ..................................................................106 Change Request Form Template......................................................................107 Change Control—Guidelines ............................................................................109 Cost Control—Activity Definition .......................................................................110 Cost Control—Guidelines .................................................................................111 Quality Assurance & Control—Activity Definition ..............................................112 Quality Assurance & Control—Guidelines ........................................................113 Procurement Management—Activity Definition.................................................114 Procurement Management—Guidelines ...........................................................115 Risk Management—Activity Definition ..............................................................116 Risk Management—Guidelines ........................................................................117 Information Distribution—Activity Definition ......................................................118 Information Distribution—Guidelines.................................................................119 Time Tracking & Management—Activity Definition ...........................................120 Time Tracking and Management—Guidelines..................................................121 Transition to Production—Activity Definition .....................................................122



Transition to Production—Guidelines................................................................124 Wrap-up Meeting—Activity Definition................................................................125 Wrap-up meeting—Guidelines..........................................................................126 Lessons Learned—Activity Definition................................................................127 Lessons Learned—Guidelines..........................................................................128 Administrative Closure—Activity Definition .......................................................129 Administrative Closure—Guidelines..................................................................130 GLOSSARY ......................................................................................................131



OSU CIO Project Management Framework DRAFT—July 27, 2004 (Version 0.89)

Project Management Phases and Activities

DEFINE PLAN LAUNCH MANAGE CLOSE

Project Request Approval

Planning Kick-off Meeting Launch Kick-off Meeting Project Plan Execution Transition to Production

Assign Project Manager Project Approach Initial Risk Identification Performance Tracking & Reporting Wrap-up Meeting

Project Overview Statement Quality Strategy Initial Team Development Schedule Control Lessons Learned

Business Case Work Plan—Work breakdown Structure Change Control Administrative Closure

Project Governance Work Plan—Estimating time and cost Cost Control Celebrate!

Phase Gate—Gain approval to develop project plan

Work Plan—Schedule Development Quality Assurance &

Control

Assign Core project team Risk Management Plan Procurement

Management

Communications Management Plan Risk Management

Issue Management Plan Information Distribution

Quality Assurance Plan Time Tracking & Management

Resource Plan Phase Gate—Gain approval to move to production

Procurement Plan

Operational Transfer Plan

Integrated Project Plan

Phase Gate—Gain approval for plan

Team Assignment



Project Classification—Sizing Matrix

Project Class

Work Effort (Hours)

Staff Budget (internal & external)

1 80 – 159 <$8,000

2 160 – 499 $8,000 – $24,999

3 500 – 4,999 $25,000 – $249,999

4 5,000 – 9,999 $250,000 – 499,999

5 >10,000 >$500,000

Project Classification—Risk Matrix

Risk Factor Low (0)

Medium (1)

High (2)

Very High (3) Score

Team Size (# of bodies) <5 5 – 9 10 – 14 >15

# Workgroups Involved 1 – 2 3 – 4 5 – 6 >7

Technology / Technique / Process

Expert Familiar New to OSU Break-through

Complexity The solution is

well defined and no problems are

expected

The solution is known but some

problems are expected

There is more than one approach to

achieving the project goal

The solution is not known or only vaguely

defined

Political Profile / Impact Org Unit Director Area VP/Dean Area Enterprise-wide

Scoring 0 – 10 No change to classification 11 – 13 Increase class 1 level 14 – 15 Increase class 2 levels

TOTAL



Project Classification—Framework Requirements Matrix

Project Class 1 2 3 4 5 Define Project Request Approval X X X X X Assign Project Manager/Lead X X X X X Project Overview Statement X X X X X Business Case X X Project Governance X X Phase Gate - Develop Plan Approval X X X Assign Core Project team X X X Plan Planning Kick-off Meeting X X X Project Approach X X X X Quality Strategy X X X X X Work Plan-Work Breakdown Structure X X X X X Work Plan-Estimating time and cost X X X X X Work Plan-Schedule Development X X X X X Risk Management Plan X X X Communications Management Plan X X X Issue Management Plan X X Quality Assurance Plan X Resource Plan X X Operational Transfer Plan X X Procurement Plan X Integrated Project Plan X X X Phase Gate - Plan Approval X X X Team Assignment X X X Launch Launch Kick-off meeting X X X X Initial Risk Identification X X X Team Readiness X X XManage Project Plan Execution X X X X X Performance Tracking & Reporting X X X X X Time Tracking & Management X X X Schedule Control X X X Change Control X X X Cost Control X X X Risk Management X X X Quality Assurance & Control X Procurement Management X Information Distribution X X X Phase Gate - MTP Approval X X X Close Transition to Production X X X X Wrap-up Meeting X X Lessons Learned X X Administrative Closure X X X X X Celebrate! X X X X X



DEFINE Phase—Activity Overview

Activity Purpose Highlights Outputs

Project Request Approval

The objective of this activity is to formalize and institutionalize the initiation of projects. By doing this, we ensure that only those projects that warrant investment are actually undertaken and executed. This will also help in managing the workload of individual departments.

Anyone can make a Project Request. The Project Request form needs to be signed by the Operating Unit Head. The Project Approver needs to evaluate the request on the basis of pre-set criteria.

Approved or denied Project Request form

Assign Project Manager

Project Overview Statement

The Project Overview Statement (POS) essentially is a short document that establishes the purpose of the project, and explains what business value it will provide to the organization. The objective of this activity is to secure management approval and to provide the Project Manager with the authority to apply organizational resources to project activities. The POS becomes a source of reference for the project team.

The problem is identified. The project goal and objectives are determined. The success criteria are identified. The required effort is estimated. Assumptions, risks and obstacles are identified.

Project Overview Statement

Business Case

The objective of this activity is to help Initiators in justifying a business need. This activity is needed so as to ensure that the costs and benefits for all projects are weighed before investment is made.

The Business Need is established. Dependencies are identified. A Cost-Benefit analysis is done. Funding requirements and risks are identified.

Business Case

Project GovernanceThe objective of this activity is to define the roles and responsibilities of the various team members and stakeholders, and to define the decision-making structure for the project.

Escalation procedures are defined. Rules and responsibilities are defined.

Project Governance document

Phase Gate—Gain approval to develop project plan

The objective of this activity is to ensure that management approves the transition of a project across its various phases. This will ensure that projects that are not likely to succeed are ‘killed’ early.

Senior management analyzes status reports and the communication with the customer, and in conjunction with the Project Manager makes a decision if the project should move to the next phase.

Approved or rejected Phase gate form



Assign Core Project team



PLAN Phase—Activity Overview


Planning Kick-off Meeting

The objective of this activity is to review the approved Project Overview statement, set expectations, and articulate any risks that are likely to occur and dispel any doubts that the team may have.

The Project Manager calls for this meeting. S/he sets the guidelines for project execution and articulates expectations from the project team. Project timelines, Project Approach, risks, assumptions, and constraints are discussed.

Minutes of the kick-off meeting

Project Approach

The objective of this activity is to establish a high-level approach of how to implement the project goals by developing an implementation approach, and project policies/standards. The purpose is also to define the solution for the project and the method of delivering that solution. This activity will also validate which planning activities will be needed for the project.

The Project life cycle and the various phases for the project are determined. Any reusable components from other projects are identified. The various methods in which the project objective can be achieved are evaluated and the best method is chosen. A rationale is provided for this decision.

Project Approach Document

Quality Strategy

The objective of this activity is to decide on the Quality Strategy that will be used for the project.

The Project Manager and team decide which Quality Assurance and which Quality control activities will be carried out for the project.

List of QA and QC activities

Work Plan—Work Breakdown Structure

The objective of this activity is to decompose the project into activities, sub-tasks, and work packages. This allows the Project Manager to estimate the duration of the project, determine the required resources and schedule the work.

The project work is decomposed into smaller components to give better management control.

Work Breakdown structure

Work Plan—Estimating time and cost

The objective of this activity is to estimate the time and cost for each task. This will be an input to the development of the Work Plan.

Time duration estimates are given for each task depending upon resource availability and capability.

Time and cost estimates

Work Plan—Schedule Development

The objective of this activity is to document the various tasks that need to be executed during the project duration, to assign responsibility for each of the tasks, and to

Resources are assigned to tasks. Quality reviews and testing are planned for. Once the overall schedule is set, the Project Manager is responsible for closely

Work Plan





establish timelines for the tasks. It also establishes dependencies between various tasks. This will ensure that the project can be completed on time and that the business scope of the Overview statement is addressed.

monitoring progress.

Risk Management Strategy Plan

The objective of this activity is to define how risks will be identified, determine who owns the responsibility of identifying risks, decide at what frequency the risks need to be revisited, identify the risk monitoring tool, determine to whom risks will be escalated, define how to manage risks, and how to handle issues that are likely to become risks.

The process of identifying risks is defined. Roles and responsibilities for the risk management process are defined. Frequency of updating the matrix is determined.

Risk Management Strategy Plan

Communications Management Plan

The objective of this activity is make sure that team members, customers and stakeholders have the information they need to do their jobs.

Target groups for different types of communication are defined. The frequency, format, and results of the communication are defined.

Communication Management Plan

Issue Management Plan

The objective of this activity is to ensure that issues are identified, evaluated and assigned for resolution. This process brings visibility to issues, accountability as to how they are acted upon, and their timely resolution.

An issue management process is defined. Roles and responsibilities are assigned. An issue log is documented and tracked.

Issue Management Plan, Issues log

Quality Assurance Plan

The objective of this activity is to validate that the major deliverables are completed and that the processes are being implemented with an acceptable level of quality.

Acceptance criteria for deliverables, quality assurance activities, in-process control plans, and quality -related responsibilities are defined. Frequency of project plan reviews, frequency of receiving and sending status reports, and frequency of checking for process improvements are determined.

Quality Plan, checklists





Resource Plan

The objective of this activity is to document how many resources will be needed during the various phases of the project and how they will be acquired, to examine if any of the resources need training, and if so, to ensure that they receive the required training.

The type and amount of resources needed are determined. The estimated output, availability, and cost of the resources are determined. Training needs are identified and planned for.

Procurement Plan

The objective of this activity is to identify procurement strategies that will be used, outline the scope of products and/or services to be procured, and identify responsibilities for the full procurement lifecycle.

Items that will be procured are identified. Inability of currently used products to fulfill this need must be described. Evaluation criteria of vendors are set. Officials who must approve the purchase are identified.

Procurement Plan


The objective of this activity is to lay down the pre-requisites of rolling out an application. This is to ensure the smooth transition from the ‘project’ to the ‘going live’ stage.

Roles and responsibilities for the installation process are identified. Dependencies that exist are identified.



The objective of this activity is to ensure that the various elements of the project are properly coordinated.

Assumptions used are reviewed. This activity ensures the following: Roles and responsibilities are identified, a quality plan is written, reviews are planned for, and most importantly that all the plans have considered all relevant factors.


Team Assignment

The objective of this activity is to ensure that individuals with the required skills are assigned to a project, and to level resources in the Work Plan.

The Project Manager resolves conflict between resource availability and Work Plan. Work packages are defined, assigned and any questions regarding work packages are discussed.

Team Assignments Fine tuned Work Plan

Phase Gate—Gain approval for plan

The objective of this activity is to ensure that management approves the transition of a project across its various

h hi ill h j h lik l

Senior management analyzes status reports and the communication with the customer, and in

j i i h h j k

Approval or rejection





phases. This will ensure that projects that are not likely to succeed are ‘killed’ early.

conjunction with the Project Manager makes a decision on whether the project should move to the next phase.



LAUNCH Phase—Activity Overview


Launch Kick-off Meeting

The objective of this activity is to ensure that all the project team members are aware of the ground rules of the project.

The Project Manager should inform the team of the ground rules for the project, the working style, the communication plan and the escalation process for conflict resolution.

Minutes of the meeting

Initial Risk Identification

The objective of this activity is to ensure that the entire team identifies risks for the project. This ensures that all perspectives are taken into account while planning for risks.

Risks are identified and categorized. For each risk identified, assess the risk event in terms of likelihood of occurrence and its effect on project objectives if the risk event occurs.

Risk matrix

Team Readiness

The objective of this activity is to ensure that individuals assigned to a project are provided the requisite training in order to perform the job and that key goals and responsibilities are identified for the team members at the start of the project.

Training needs identified need to be met. Team members identify key goals at the start of the project.

Key goals for each team member



MANAGE Phase—Activity Overview


Project Plan Execution

Performance Tracking & Reporting

The objective of this process is to ensure that the team is making satisfactory progress toward the project goals. The purpose is to: 1.Track cost, time, scope and quality, 2. Track actual accomplishments and results, and 3. Provide visibility into progress.

Team meetings can be held so that information can be exchanged. The Project Manager monitors—at least weekly—progress to plan on key elements. The status of the project is reported to the relevant stakeholders.

Weekly Status Reports, Tracked Project Schedule

Schedule Control

The objective of this activity is to ensure that tasks are executed as per Work Plan so that the deadline for the project can be met. If the schedule cannot be met, the relevant stakeholders need to be informed.

The Project Manager is responsible for tracking the various tasks in a project. Tracking is done by exchanging task status information with team members and then incorporating the latest status information into your project Work Plan. If the any task, schedule or resource information has been changed, the Project Manager needs to communicate the revised Work Plan to the project team.

Tracked Work Plan

Change Control

The objective of this activity is to ensure that all changes to scope are documented and authorized by the relevant stakeholders.

Any change to scope has to be communicated to the Project Manager. The Project Manager ensures that the Change Request Form has been filled out. The Project Manager analyzes the change request. The Project Manager and established governance may approve or deny a change request.

Approved or denied Change Request Form

Cost ControlThe objective of this activity is to manage project cost such that it is aligned with budgeted cost.

Costs are agreed upon with the sponsor at the start and upon completion of the project. The budget has to be constantly monitored by the Project Manager.

Status reports




Activity Purpose Highlights Outputs The variance between Budgeted cost and Project cost needs to be communicated to and approved by the sponsor/customer. This should also be present in the status report.

Quality Assurance & Control

The objective of this activity is to ensure that the project team meets the project requirements and that all requisite quality criteria are met.

This process comprises project reviews, product reviews, code reviews, testing, and any other process that the Project Manager might think necessary. Defects are identified, and categorized. Root causes are analyzed.

Review reports, Bug reports

Procurement Management

The objective of this activity is to ensure that appropriate resources are employed, that the process of selection is fair and that the quality of work is acceptable.

Any guidelines set by the University in this regard supersedes this process. A vendor is chosen on pre-set criteria. The contract needs to be signed by authorized signatories.

Signed Contract(s) / Purchase Order(s) /Statement(s) of Work

Risk Management

The objective of this activity is to identify risks, to reduce the probability of the identified risks, to identify mitigation strategies, to identify contingency plans for the bigger risks, and if realized, to reduce the impact of these risks.

Management monitors risks with a risk exposure over the threshold limit. Risk mitigation strategies are planned and contingency plans are developed. The Risk Matrix is revisited at and appropriate frequency.

Revised Risk Matrix

Information Distribution

The objective of this activity is to ensure that all appropriate parties are kept informed.

All relevant information needs to be communicated to the appropriate parties at the right time and in the appropriate format.

Status reports, Minutes of meetings

Time Tracking & Management

The objective of this activity is to ensure that all time spent on a project is logged in.

Time spent is tracked at a project level, and analyzed at an organizational level.

Time Sheets, Variance Reports,




Activity Purpose Highlights Outputs Estimates for future projects

Phase Gate—Gain approval to move to production

The objective of this activity is to ensure that management approves the transition of a project across its various phases. This will ensure that projects that are not likely to succeed are ‘killed’ early.

Senior management analyzes status reports and the communication with the customer, and in conjunction with the Project Manager makes a decision on whether the project should move to the next phase.

Approved or rejected Phase gate form



CLOSE Phase—Activity Overview


Transition to Production

The objective of this activity is to ensure that the Operational Transfer Plan is carried out after the required checks are done.

Its ensured that all planned testing is carried out, all customer requirements are met and that the product is fully operational. The Project Manager ensures that the customer accepts the product before Transition to Production.

Summary Report, Customer Sign-off

Wrap-up Meeting

The objective of this activity is to ensure that the Project team discusses the project after the project has been executed so that Lessons Learned are captured and issues are analyzed.

The Project Manager calls this meeting. The Project Manager, and the team members discuss the project experience including problems faced during project execution. Solutions to such problems are suggested and discussed. Lessons Learned are discussed.

Minutes

Lessons Learned The objective of this activity is to ensure that the Lessons Learned during the project are documented and incorporated in the knowledge base for future use.

The Project Manager develops this ‘Lessons Learned’ document with the help of the project team. This document is deposited in the knowledge base.

Lessons Learned Document

Administrative Closure

The objective of this activity is to ensure that the Project is approved, accepted and closed.

The Project Manager ensures that the project is approved and accepted by the relevant stakeholders. All documentation and records are reviewed, organized and archived. Backups are taken. Resources are released and the project is closed.

Celebrate!



Project Request Approval—Activity Definition Purpose: The objective of this activity is to formalize the process by which new projects/service requests are initiated. By doing this, we can ensure that only those projects that warrant investment are actually undertaken and executed. This will also help in managing the workload of individual departments. This process applies to all projects undertaken by the Office of the CIO of the Ohio State University. Participants: Initiator: Any customer or member of the Office of the CIO who submits a request Operating Unit Manager: Resource Owner Approver: The appropriate decision maker Sponsor: The body or person who funds the project Inputs: Project Request Approval form [1] Process: 1. The Initiator completes the Project Request form and requests approval (signature)

from the appropriate person as established via the standard operating procedure of the work unit. Anyone can initiate a request. The form contains information such as:

a. Customer name, phone, and department b. Description of the business need or production problem c. High-level business reason category for the request d. Goal of the project e. Impact on the business unit

2. The appropriate area manager reviews the request to determine a high-level work effort range for planning purposes.

3. The request goes to the Project Approver for a decision. Approval signifies authorization to invest effort.

4. The Governance Body/Process evaluates the Project Request form and makes a decision to accept or deny the request based on the following criteria: a. Value to organization b. Criticality c. Estimated effort and resource availability d. Risks e. Impact and/or dependence on other projects f. Any other criteria thought necessary and relevant to the organization/project

5. If the Governance Body grants approval, the project moves to the next stage, based upon the Project Class, where a Project Overview Statement is created. In some cases, the creation of a separate Business Case document may be required.

6. Depending on the size and scope of the project, the Project Manager and the Core Project team may be assigned at any time after project initiation and definitely prior to project kick-off.



Outputs: Approved or denied Project Request form Top



Project Request Form Template Request Identifier (To be completed by OIT): Initiator Operating Unit Manager Customer/Sponsor Name Department Date Email ID Phone Description of business need/problem/opportunity

Type of Request

Internal mandate (University Policy, System Upgrade)

External mandate (Legal requirement, Government)

Correct an error (Malfunction/Fix)

Value-add/Process improvement/Business opportunity Goal

Business Impact

Estimated labor hours (optional)

Date needed (Explain in Impact) (optional)

Project Initiator:

Date Sign To be completed by the Project Approvers Project request Approved / Denied Comments, if any:

Sign: Date:

Governance Sign: Date:

Sponsor Sign: Date:

Customer Sign: Date:

Others Sign: Date:





Project Request Approval—Guidelines

1. Customer details: - The customer name, phone number, and customer department need to be filled out in the form.

2. Description of business need or problem or opportunity: - Why is this project required? A brief description of the business need has to be filled in. e.g. Different departments of the University use different email systems. This increases the amount of training provided to people taking calls in the help desk. Supporting documentation (if available) for the ‘Business Need’ field needs to be provided by the Initiator.

3. Classify the request by type: This field will help assign priority to the project. Is this project being created to correct errors that exist? Or is this project request a result of an internal or external mandate? Is it a process improvement, a value add or a business opportunity? e.g. A change in legal requirement would be an external mandate while a system upgrade or a change that is mandated by the Department Head would be an internal mandate.

4. Goal: Describe the project goal. What does the project plan to achieve? e.g. The goal is to route all help desk inquiries through a single point. OR The goal is to ensure that all university departments use the same email system.

5. Business Impact: Determine if any area of work will be affected by decisions on the project. What will be accomplished if the project is undertaken? What will be the result if the project is not undertaken? The Initiator needs to identify related projects i.e. projects which are dependent on this initiative, or projects upon which this initiative is dependent.

6. High-level effort range: Estimate approximately how many person-hours will be required for executing the project.

7. Date Needed: This is an optional field and needs to be filled in only if there is a deadline before which the project definitely needs to be completed.

8. To grant or deny approval to the project request: The criteria that need to be taken into account while evaluating a project request are as follows:

• Value to organization: Is this project aligned with the overall strategy? • Criticality- How critical is the project? Is the need being satisfied by a less

efficient method or is it not being satisfied at all? • Amount of effort to be spent • Workload of resources- If the existing workload doesn’t allow for immediate

assignment, then the project priority must be reviewed with the initiator. • Risks • Impact on other projects • Any other criteria thought necessary and relevant to the organization/project

9. Additional approvals from the sponsor or customer may be required.



Project Overview Statement—Activity Definition Purpose: The Project Overview Statement (POS) is a short document that establishes the purpose of the project, and explains what business value it hopes to provide to the organization. The objective of this activity is to secure management approval and to provide the Project Manager with the authority to apply organizational resources to project activities. The POS becomes a source of reference for the project team. Participants: The Project Manager prepares this document. The intended audience is management, stakeholders, sponsor and the project team. Inputs: Approved Project Request form[1] Process: 1. State the Problem or opportunity that the project addresses. 2. Establish the Project Goal. The goal gives purpose and direction to the project. 3. Clearly state the project objectives that are concise, verifiable, feasible, and

measurable. 4. List the criteria that will be considered while measuring the success of a project. 5. Determine the effort that will be required for the project. This estimate should be a

more fine-tuned estimate compared to the one made in the Project Request Form. 6. Estimate the total cost of the project i.e. effort, operating expenses, and any capital

costs like licensing costs. 7. Determine the Class of the project. 8. List any assumptions made, and any known constraints or obstacles imposed by the

environment or management. Identify any project risks that might be present. 9. Attach documentation, if necessary to support any of the above. 10. This document needs to be approved by the relevant stakeholders. 11. Maintain versions and details of what changes are made in what version. Outputs: Project Overview Statement



Project Overview Statement Template Project Overview Statement

Project Name Date Version Project Sponsor/Customer Project Manager/Lead Problem/Opportunity

Goal

Objectives

Success Criteria

Effort

Total Cost Class of Project Assumptions, Risks, Obstacles

Supporting Documents

Prepared By: Date:

Approved By: Date:



Project Overview Statement—Guidelines

1. Project Name and Date 2. Revision History and versions: Date, what changes were made and who made the

amendments. Version is incremented for each significant change or edit. The signed off version becomes v1.0. Changes after this acceptance are incremented.

3. Project Sponsor/Customer 4. Project Manager 5. Problem/Opportunity: State the problem that the project will resolve. 5. Goal: What does the project hope to accomplish? 6. Objectives: A concrete statement describing what the project is trying to achieve.

The objective should be written at a low level, so that it can be evaluated at the conclusion of a project to see whether it was achieved or not. A well-worded objective will be specific, measurable, attainable/achievable, realistic and time-bound. e.g. there should be no more than 2 queries in a day regarding the use of function X after the project is executed.

7. Success Criteria: Success criteria should be identified. To the extent possible, these factors should be quantifiable and measurable. These success criteria should be determined based upon the following considerations: a. Metrics and User Surveys, b. Financial Savings, c. Operational/Readiness Improvements, etc. e.g. all web pages should download on a 64kbps line within 2 seconds. OR there should be an increase in savings by 0.10 dollar per transaction.

8. Effort: Estimate the time that team members will spend on the project. 9. Total Costs: An estimate of the effort that will be required to execute the project is

required. Costs are divided into three types: a. Capital Items are costs associated with the procurement of assets such as hardware and software. b. Expense Items are costs associated with operating expenses, material, travel, training, supplies, books, copying, printing, etc. c. Effort are costs associated with the total time team members work on a project based on an hourly rate for each skill set or the actual salary of the team members.

10. Class of Project: The Project Classification matrix needs to be used in order to determine the class of the project. When using the Classification matrix, the work effort; not the entire cost needs to be taken into account.

11. Assumptions: Project assumptions are circumstances and events that need to occur for the project to be successful but are outside the total control of the project team. Assumptions are made to fill knowledge gaps; they may later prove to be incorrect and can have a significant impact on the project. List only those assumptions that have a reasonable chance of occurring. If an assumption is invalidated at a later date, then the activities and estimates in the project plan should be adjusted accordingly.

Risks: Project risks are circumstances or events that exist outside of the control of the project team and will have an adverse impact on the project if they occur. (In other words, whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred.) All projects contain some risks. It may not be possible to eliminate risks entirely but they can be anticipated and managed,



thereby reducing the probability that they will occur. Risks that have a high probability of occurring and have a high negative impact should be listed.

Obstacles/Constraints List any known constraints imposed by the environment or by management. Typical constraints may include fixed budget, limited resources, imposed interim and/or end dates, predetermined software systems and packages, and other predetermined solutions.

12. Supporting Documents: Include in this section copies of pertinent documents such as: Business Case or Plan University guidelines or policies applicable to this project

13. Approval: Use this section for approval signatures from project stakeholders.



Business Case—Activity Definition Purpose: The objective of this activity is to help Initiators in justifying a business need to senior management. This activity is needed to ensure that the costs and benefits for all projects are weighed before a commitment of resources is made. This also ensures that the projects invested in bring the greatest value to the organization. Participants: Initiator: Person from whom the project idea originated Sponsor: Person or body who will be funding the project Approver: Established governance Inputs: Approved Project Request form [1] Process: 1. Draft a project summary. 2. Establish the business need that the project intends to fulfill. Collect necessary data

and information to support this. Establish dependencies that exist. Establish that the project fits within the overall organizational strategy.

3. Consider various options that might be considered in order to fulfill this business need. Choose an option and state why this option was preferred and chosen.

4. Perform a Cost-Benefit Analysis. Identify the Total Cost of Operation and the Opportunity Costs. Identify funding requirements and risks.

5. Identify competitive offerings and assess the proposed solution against these offerings. (Optional)

6. Describe the overall approach as to how the project will be executed. 7. Identify factors that need to be in place in order for the project to succeed. 8. Identify measures that will be used to determine if the project was a success. Outputs: Complete Business Case with cost-benefit analysis Notes: Clearly mention what is and is not included under costs. Top



Business Case Template

BUSINESS CASE 1. Project Summary a. Project Initiator b. Project Sponsor c. Project Description d. Needs and scope e. Target customer f. Objectives, outcomes, and benefits

g. Features to be included and the need they satisfy

h. Costs i. Risks j. Complexity assessment k. Duration l. Leadership requirements m. Team skill requirements 2. Statement of Need a. Unmet Need or Opportunity b. Anticipated Benefits c. Rationale for assigning priority d. Specific Business needs (current and future)

e. How was the need determined f. Supporting data g. Names of stakeholders consulted

h. Names of stakeholders supporting this proposal

i. Consequences of not proceeding

3. Consideration and selection of Preferred Option a. Options considered b. Strengths and weaknesses of each option

c. Reason preferred option was chosen

d. Investment alternatives e. Assumptions made f. Alignment with University policies and strategies



g. Any Business Process changes? If so, outline them

4. Financial Analysis – Outputs, Benefits, costs, and Risks a. Costs Year 1 Year 2 Year 3 i. Capital costs ii. Operating costs iii. Total cost of ownership iv. Impact on other projects v. Impact on HR policies/requirements

b. Benefits i. Savings ii. Potential Revenue iii. Expected Outcomes Summary c. Funding i. Net Impact (Cost –Benefit analysis)

ii. Funding Requirements iii. Other sources of funding d. Unquantifiable impact e. ROI f. Risks 5. Competitive Analysis 6. Implementation Strategy 7. Factors critical to project success

8. Criteria for measuring success



Business Case—Guidelines A Business Case must include the level of detail appropriate to the project or initiative. The most important aspect of the documentation is that it be detailed enough to enable sound judgments to be made about the merit of what is being proposed, and whether funding and other resources should be allocated to it. 1. Project Summary

a. Identify the project initiator and the project sponsor b. Describe the Project c. Present the Needs and Scope. Define the needs that drive the investment proposal.

Define the scope of the project clearly. Be clear about what the project will include and what it will not include.

d. List the Target customers or population. e. List the Objectives, Outcomes and Benefits f. List the features to be included and cite the specific business needs they satisfy.

The developer of the Business Plan should present sufficient detail to allow the decision-makers to understand the business solution in order to evaluate it properly.

g. List the Costs and Risks h. Assess the Complexity i. Duration j. Project leadership requirements: Are there any specific skills required of the

person leading the project? k. Team skill Requirement: Identify the project resources by role and quantity, but

not by name, over the life cycle of the proposed project. State how the resource estimate was calculated. Include an explanation of the split of effort between in-house and external resources, if appropriate. Examples of resource requirements are: Technical skills, Management skills, Technology resources, Capital Partnerships, alliances, etc.

2. Statement of Need—Establishing the business need, issues definition, opportunity description

a. Describe the extent of an unmet need, demand for services or opportunity that has been identified and which is considered to be a high priority. Identify why this need or demand has not been met with existing systems and facilities.

b. Identify anticipated benefits to various groups. c. Explain the rationale for assigning the priority and the reasons that the timing is

appropriate to implement the project. d. Define the specific business needs that drive the investment proposal. Account for

both current and future needs of the business. e. Supporting data and information—Explain how the need was determined and how

critical, urgent or important it is. Provide data or other evidence of need. f. Identify which stakeholders have been consulted. g. Identify how many stakeholders support the proposal. h. Look at the consequences of not proceeding with the project.



3. Consideration and Selection of Preferred Option Generate a wide range of options that can be considered to address the identified need. Evaluate each option by summarizing the strengths and weaknesses of each option. State why the preferred option has been chosen. Include financial and investment alternatives. State the assumptions that have been made in choosing the preferred option. Comment on the strategic alignment of the project with University policies and strategies. Outline Business Process changes proposed to facilitate this project. 4 Financial Analysis – Outputs, Benefits, Costs and Risks a. Costs Identify the capital and operating cost of the preferred option for Year 1, Year 2 and beyond. The proposed budget must include:- Capital and recurrent expenditure, including salaries, equipment, and consumables for

• Software • Hardware • Maintenance • Training • Ongoing support • Operating cash

Identify total cost of ownership Identify impact upon other projects and initiatives Identify impact upon Human Resources requirements and policies. Do we need to train people or recruit people for this project? b. Benefits Identify any savings and how those savings will be used Identify any potential revenue Describe the expected outcomes in terms that are as specific as possible, and relate to the needs identified. e.g.

• Compliance with statutory or other obligations • Improved decision making as a result of better information • Reduced cost

Summarize benefits and costs, and explain why the benefits outweigh the costs involved. c. Funding Calculate net impact of project by combining cost and benefits. Identify funding requirements. If funds have not been allocated or approved, state the means by which funds will be acquired. Identify other sources of funding being considered or investigated. d. Unquantifiable Cost and Benefit Analysis Identify unquantifiable impact to • The University • The economy • Society • Distribution of benefits e. ROI



ROI benefits may either be earned once upon the implementation of the proposed solution or recur over the operational life of the solution. They may yield direct revenue, or strategically position the enterprise for market gains. Identify the ROI benefits and classify them as such. 4.6 Risks Identify the expected risks to which the project will be exposed. Assess the likelihood of each risk occurring and its impact on the project. Outline a plan for managing the risks; include risk-minimization measures and contingency plans for recovery and damage limitation. 5. Competitive Analysis Describe how the proposed solution is competitive in the marketplace. Assess it against the top three competitors’ offerings, including price and quality. 6. Implementation Strategy Describe the proposed implementation strategy including:

• How will the project be implemented • Project milestones and key dates • Who will be accountable for managing implementation • What resources (human, physical, other) and skills are required • What changes are required to working practices, and • Integration with existing and proposed systems.

7. Factors critical to project success List those factors that must be in place to ensure success of the proposed solution. Be specific. e.g. Commitment and awareness from Executive Sponsors Access to necessary source data Cooperation by affected business or IT areas Full-time staff assignments to project Architecture fit (Status of interfacing systems) 8. Criteria for measuring success Describe what measures will be applied to measure the success of the proposed solution. e.g.

• Financial (Cost vs. Revenue) • Performance • User acceptance • Schedule • Competitive differentiation



Project Governance—Activity Definition Purpose: The objective of this activity is to define the roles and responsibilities of the various team members and stakeholders, and to define the decision-making structure for the project. Participants: Project Manager and stakeholders Inputs: Approved Project Request form [1], Project Overview Statement [1], Business Case [4] Process: 1. Identify the various roles that exist. e.g. Project Manager, team member, reviewer. 2. Identify the responsibilities that each role has. e.g.

a. Define who will establish project requirements with the customer. b. Define who can interface with external providers, internal and external

resources and customers. c. Define who reviews and approves the project plan. d. Define who authorizes project scope, schedule, and cost. e. Define who authorizes change in scope. f. Define who can sign a contract with a vendor. g. Define who can communicate with vendors. h. Define who can assign work.

3. Define the rules of communication. e.g. a. Define who reports the status of the project to the stakeholders and at what

frequency. b. Communication to the project resources from the management should go

through the Project Manager. 4. Define the organizational structure that the project will follow. e.g. even if a

functional team member has a designation higher than the Project Manager, for the purpose of the project, the team member will be reporting to the Project Manager.

5. Determine the person to whom the customer can escalate issues. 6. Define the decision-making structure. 7. Define the team operating rules. 8. Outline the team meeting structure. Outputs: Project Governance Document Top



Project Governance Document Template

1. Role Definitions and Responsibilities: Roles Responsibilities e.g. Project Manager Mentor Reviewer Quality Manager Testing Team Project team 2. Rules of Engagement e.g. a. Communication b. Status Reports c. Procurement of human resources d. Resource acquisition 3. Organizational structure for the project

4. Escalation Procedure 5. Decision-making Structure a. Technical decisions b. Changes in scope c. Conflict resolution 6. Team Operating Rules 7. Team Meeting Structure e.g. Who facilitates the meeting? Who records the minutes of the meeting?



Project Governance—Guidelines 1. Identify roles that will exist in your project. e.g. Project Manager, mentor, reviewer,

Quality Manager, Testing Team, Project team etc. 2. Define the roles. Identify the responsibilities of each role.

e.g. Project Manager may be responsible for the following: · Developing the project plan · Directing project resources · Managing project schedule · Managing project budget · Estimating project resources · Communicating project status · Tracking project status · Defining, assessing and mitigating project risks · Ensuring project meets technical requirements

3. Define the rules of engagement. Some examples are:

a. Communication. e.g. communication to project resources from say, the Program Director must flow through the appropriate Project Manager.

b. Status reports e.g. the status of individual work assignments needs to be communicated on a daily basis to the Project Manager, bi-weekly status reports need to be sent by the Project Manager to the Operating Unit Head.

c. Procurement of human resources e.g. the Project Manager acquires human resources for the project after speaking with the Operating Unit Head and the Resource Manager

4. Organizational structure for the project. e.g. all team members report to the Project

Manager, the Project Manager reports to the reviewer of the project, etc.

5. Escalation Procedure - In case of issues, a person should be identified as the ‘go-to’

person for a customer in order to escalate issues that the team cannot manage.

Senior Project Manager

Project Reviewer

Project Manager

Functional Heads

Project team

Operating Unit Head



6. Decision-making Structure: e.g. Identify sponsoring groups for decisions related to costs, Define who will decide on technical issues. Define who authorizes change in scope. Define who will resolve conflicts.

7. Team Operating Rules: e.g. in the absence of the Project Manager on a certain day,

does the Project Technical Lead assign work to the technical team? 8. Team meeting structure: Does the Project Manager facilitate the meeting? Who

records the minutes? Who will validate the minutes before sending it out to stakeholders?



Phase Gate—Activity Definition Purpose: The objective of this activity is to ensure that management approves the transition of a project across its various phases. This will ensure that projects that are not likely to succeed are ‘killed’ early. Participants: The Project Manager, relevant stakeholders Inputs: Project Status Report [1], important customer communication [1], Phase gate form of earlier phases (if applicable)[3] Process: 1. At the end of every phase, the Project Manager prepares a project status report and

submits it to senior management to get approval to move on to the next phase of the project.

2. The Project Manager also submits any important customer communication, which shows satisfaction or unhappiness with the project progress.

3. The relevant stakeholders analyze the status report and the communication, and in conjunction with the Project Manager make a decision on whether the project should move to the next phase.

4. The relevant stakeholders sign off the phase gate form. Outputs: Approved or denied Phase gate form



Phase Gate Form Template

Project Name Project Manager Phase End of the Define phase

End of the Plan phase

End of the Manage phase Status Significant Variances Comments by Project Manager

Problems to be resolved Comments/Recommendations by approver

Areas to be examined in next phase gate

Approved/Kill project/Revise/Delay/Other changes

Governance: Name: Sign: Date:



Phase Gate—Guidelines 1. In a lot of projects, this might seem a mere formality but this process proves to be

very useful in ventures where there is no clarity of objective, and effort is being wasted.

2. Where it seems that a few recommendations might put the project back on track, the established governance should document and communicate these recommendations to the Project Manager. It is the responsibility of the Project Manager to implement the suggestions or provide an explanation why the recommendation cannot be implemented.

3. In some cases, senior management may approve at the phase gate while in other cases, the approval may be sought from an external body e.g. the customer may decide whether the project should move to the next phase.

4. Questions to be asked are: a. Is the project on time? Were all milestones met? b. Is the project on budget? c. Is the project according to specification? d. Is the customer satisfied with results up to this point? e. What are the barriers standing in the way of the success of the project? f. What are the problems that the project faces? g. Were recommendations given in the past implemented?

5. The documents that accompany the phase gate form will be different for each phase of the project.

6. At the end of the definition phase, check if any comments have been listed by the governance in the Project Request Form. Also read through the assumptions, risks, and obstacles section in the Project Overview Statement and see if any assumption is untrue now, or if any risk is critical.

7. At the end of the planning phase, check if all the planning activities that were needed for the project have been performed. Ensure that the Quality Strategy activities are carried out. Ensure that the Work Plan is realistic. Ensure that the communication matrix has identified all relevant stakeholders for the various communications.

8. At the end of the launch phase, ensure that the Risk Matrix has identified all risks relevant to the project.

9. At the end of the management phase, ensure that all change requests are taken into account during transition to production during project closure.



Planning Kick-off Meeting—Activity Definition Purpose: The objective of this activity is to review the approved Project Overview Statement, to set expectations, to articulate any risks that are likely to occur, and to dispel any doubts that the team may have. Participants: The Project Manager calls for the meeting. The audience includes the relevant stakeholders (i.e. customer representative and affected business units) and the core project team. Inputs: Project Overview Statement [1], Business Case [4], Governance Document [4] Process: 1. Schedule the meeting. Send out the agenda of the meeting in advance. The

management and the project team need to be present for the meeting. 2. Walk the team through the Project Overview Statement. 3. Set guidelines for the project planning phase and articulate expectations for the

planning activities from the core project team. 4. Hand out copies of the Project Overview Statement and discuss the roles and

responsibilities/governance document. 5. Discuss project timelines. 6. Discuss the overall approach of the project. This is the point at which brainstorming

for the project starts. 7. Discuss risks, constraints and assumptions. 8. Answer any questions that the management or project team may have. 9. Assign someone to take notes during the meeting. Identify action items and timelines.

Send out the notes to relevant stakeholders. 10. Determine (in advance) whether you want to discuss the Project Approach in the

same meeting or in a separate meeting.

Outputs: Notes taken during the kick-off meeting Top



Planning Kick-off Meeting Agenda Template Project Name:

Attendees:

Date:

Time:

Location:

Project Manager:

Core Project team Members:

Stakeholders:

Items:

• Introduction of meeting participants

• Start Date of the planning phase

• End Date of the planning phase

• Guidelines and expectations

• Discussion of the Project Overview Statement elements

• Discussion of Roles and responsibilities/Governance document (if applicable)

• Project Approach and overall timeline

• Existing Issues

• Project Resources/Tools/Repository

• Questions

• Recap / summary/Acton Items



Planning Kick-off meeting—Guidelines Prior to the meeting:

1. Send out a meeting announcement with a meeting agenda to attendees with the project objective, meeting objective and time frames. Team members are required to ‘RSVP’ to you. That requirement needs to be stated in the meeting announcement.

2. Take copies of the agenda to the meeting for the participants. 3. Prepare handouts for the meeting, if necessary

During the meeting: 4. Make sure all the items in the agenda are discussed. 5. The start and end date of the planning phase needs to be articulated. 6. The Project Overview Statement and the Business Case (if applicable) could be

handed out during the meeting. Discuss all the elements in the Project Overview Statement.

7. Distribute the Project team Organizational Chart from the Governance document. It is imperative this is distributed during this meeting. If it is not official yet, create a draft. Discuss roles and responsibilities.

8. The team needs to know their part in the project. Inform them that you will be discussing their responsibilities with them.

9. Project team Rules need to be set in the Kick-Off meeting. Start them off with one rule and give them a time limit to come up with more.

10. You need to let the team know what you expect from them as a group. e.g. They need to know that all information regarding the project needs to be validated by you before anyone else receives the information.

11. Discuss any existing issues and assign the issues to team members for resolution. 12. Discuss what resources and tools will be used for the project. Discuss where the

project repository will reside. 13. Consider what skills the team can bring to determine the Project Approach and

the WBS. 14. Emphasize the importance of the planning activities schedule. 15. The Project Manager may choose to discuss the overall approach of the project in

this meeting or arrange for a separate meeting for this purpose. The Project Manager should consider which stakeholders need to be involved in the Project Approach meeting. Other factors that could be considered are the length of the meeting, the information that one would want the customer to hear, and the decisions that the customer should participate in.

16. Answer any questions that the team or other stakeholders may have.

After the meeting: 17. Identify action items and send out the notes taken during the meeting to all

relevant stakeholders



Project Approach—Activity Definition Purpose: The objective of this activity is to establish a high-level approach of how to achieve the project goals specified in the Project Overview Statement, by developing an implementation approach and project policies/standards. The purpose of this Approach document is to define the type of solution for the project and the method of delivering that solution. This document will re-state the project goal and articulate how this will be achieved. It will also validate which planning elements will be needed for the project. Participants: Project Manager, Project team, relevant stakeholders, and customer Inputs: Project Overview Statement [1], Business Case [4], Governance Document [4] Process: 1. The Project Manager can decide whether the project approach should be discussed in

the planning kick-off meeting or a separate meeting should be held for this purpose. 2. An explanation of the project life cycle and the various phases of the project will be

given in the Project Approach document. Determine if any tailoring of the normal project life cycle will be done.

3. Determine if there are examples of similar projects. 4. Identify any reusable components from other projects that can save effort, cost, and

time for this project. 5. Arrive at the project guidelines. Define ground rules for the project. 6. Document the various steps that need to be executed in order to meet the project

objective. Discuss the various methods in which these steps can be executed. 7. Evaluate each method and select the best method. 8. Reasons for selecting a method need to be given. 9. Determine which planning activities would be necessary for the project. 10. Identify dependencies that exist for the project. 11. Define a conflict resolution process for the project. Outputs: Project Approach Document Top



Project Approach Document Template 1. Product/Service Life Cycle INSERT LIFE CYCLE HERE 2. Similar projects 3. Reusable components: 4. Project guidelines

5. Method 6. Justification of method a. Cost vs. benefits b. Risks

7. Planning elements required 8. Dependencies 9. Conflict Resolution Process



Project Approach—Guidelines Virtually every project needs to have a defined approach, however the degree of formality depends on the size and complexity of the project. Without some description of a Project Approach, it is difficult to plan the activities and results of the project. A defined life cycle helps to ensure relevance of work being done and continuity of the results of that work. The best method in which the project can be executed is chosen. Relevant planning elements for the project are determined. A team meeting is the best way to agree upon the Project Approach.

1. Project Life Cycle a. Phases: How are the project activities grouped and sequenced? Will the

regular project life cycle hold good for this project or will the life cycle be tailored for this project?

b. Testing: How does each phase contribute to testing of project results? c. Reviews: What kinds of reviews are needed for results of each phase? Who

needs to participate in the reviews?

An example is given below:

Phase Major Deliverables Testing Walkthrough/Review Requirements Analysis

Outputs: Customer Specifications, Project Overview Statement Inputs: Customer requirements Rules: The technical lead needs to accompany the Project Manager for the specifications discussion with the customer. Dependencies: Storyboard needs to be sent by the customer.

Acceptance Test Plan

Specifications Document to be reviewed by the Stakeholders and the Development Team

Planning Outputs: Integrated Project Plan Inputs: Specifications document, Approved Project Request. Rules: All task durations need to be validated by the project reviewer. Dependencies: 1.The specifications document needs to be signed off. 2. Standards to arrive from Dept A

Test cases Plan review by relevant stakeholders

Production Outputs: Components of product Inputs: Plans, specifications. Rules: If there is schedule slippage, the resource needs to inform the Project Manager as soon as s/he becomes aware of the

System Test Plan

Peer code review by team members Content review by Project Manager



delay. Dependencies: Component A and B should be complete before work on Component C starts.

Testing Outputs: Defect reports Inputs: Product, Test cases, Test Plans Rules: All defects to be rectified within 2 days of capturing the defect. Dependencies: All defects to be corrected before second round of testing.

Defect Reports Test cases to be reviewed by the Project Manager.

2. Similar project life cycles: Check to see if there have been any other projects, which followed a similar life cycle.

3. Reusable components: Speak with team members, project reviewers, the operating unit head and determine if any code, hardware, or any other element can be reused in this project. e.g. the code for Functionality X used in Project A can be reused for Functionality X in this project, or e.g. The work breakdown structure for Project B can be used as a work breakdown structure template for this project.

4. Project guidelines: Guidelines and ground rules can be defined and agreed upon. e.g. The customer will review each module when its ready. or e.g. Production of a module will begin once the customer approves the storyboard of a module.

5. Methods: Discuss various approach options that can be used in order to meet the project objective. Evaluate the various methods and choose the best one.

6. Justification: The reason for choosing a certain method should be given. e.g. a. Cost vs. Benefits: A blended training method was agreed upon because only classroom training is likely to put a strain on the budget. Blended training has worked well in the past. b. Risks: The risks in this option are lower because we have expertise in using this version of Macromedia Flash.

7. Discuss with the team which of the planning activities are required. The various risks, the complexity of the project, and the customer should be kept in mind while deciding which planning activities are required.

a. Work Planning b. Risk Management Planning c. Communications Planning d. Quality Assurance Planning e. Resources Planning f. Procurement Planning g. Operational Transfer Planning

8. Dependencies: Any dependencies outside of the Project Manager's direct control, or outside of the scope of the project (but which may still influence the project success) should be identified. e.g.We will be able to start work on Project A only when Dept. X has tested their Project B successfully.



9. Define a conflict resolution process. This ensures that at the time of conflict, team members learn to resolve it effectively between themselves and escalate the conflict only, if necessary.



Quality Strategy—Activity Definition Purpose: The objective of this activity is to decide on the Quality Strategy that will be used for the project. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Project Overview Statement [1], Project Plan [3] Process: 1. Determine what Quality Assurance activities need to be carried out for the project. 2. Determine what Quality control activities will be carried out. 3. Define the Quality Assurance activities for the project including documentation,

requirement verification processes, and continuous improvement processes. 4. Define in-process control plans, which address quality control areas, what audits and

reviews are required, when these audits and reviews will be conducted and how variance to acceptance criteria will be reported and resolved.

5. The project team and major stakeholders should agree on the completeness and correctness criteria up-front:

a. Break down the generic term of “quality” into a number of areas that define the characteristics of quality.

b. Look at each of the individual characteristics and determine one or more metrics that can be collected to mirror the characteristic.

c. The deliverables are then evaluated against these criteria before they are assigned to be approved.

6. Establish clarity of purpose. Ensure that you have understood the client’s requirements clearly and that the Project Overview Statement reflects these requirements accurately.

7. Build customer checkpoints so that the customer is involved at critical junctures in the project.

Outputs: Quality Strategy Top



Quality Strategy Template Project Name Date Created By 1. Quality Assurance e.g. Quality Assurance activities

Responsibility

Checklist for coding Project Technical Lead

Project Checklist Project Manager

Training on Dreamweaver to Content developers

Person A

Customer Review of graphics

Project Manager and Customer 2. Quality Control e.g. Quality Control activity

Responsibility Frequency/ Milestone

Variance to acceptance criteria

Unit testing Developer After development of unit

If not working according to plan, correct the error.

System testing

Technical Lead After planning and launch of project, but before development begins.

If the system-testing plan is different from the acceptance criteria (e.g. if the customer needs to use the learning program on a PC and the system testing will be done on a Mac), the plan needs to be revisited.

Peer code review

Team members At the time of delivery of code to the next task.

If not working according to plan, correct the error.

Test cases Project Manager

Before development begins

If test cases are different from what the customer requires, change the test cases and check to see if other plans are according to what the customer requires.

User acceptance testing

Project Manager, panel of users

After development of product

If not working according to test cases, correct error.

3. Acceptance criteria e.g. all transactions to be executed without

encountering an error.



Quality Strategy—Guidelines 1. Determine what Quality Assurance activities are required for the project. e.g.

• Will checklists ensure that the product matches the customer’s requirements? • Will style sheets ensure uniformity and consistency in code? • Will mentoring help in bridging the gap in skill for some team members? • Is training required?

Once you have agreed upon which quality assurance activities are needed for the project, define them. Determine when and at what frequency they will be conducted. Determine whose responsibility it will be to execute the activity, e.g. user acceptance testing will be done at the end of production. 2. Determine what in-process control plans are required for the project. Decide what reviews will be conducted. e.g. will there be peer reviews or external reviews. Decide if user acceptance testing is required or if system and integration testing will suffice. In-process control plans should be defined. e.g. peer code reviews will be done. 3. The success criteria from the POS will be an input to the completeness and correctness criteria. Agree upon completeness and correctness criteria with the customer. The customer should sign off the project if the product is of acceptable quality. What constitutes acceptable quality is defined in the completeness and correctness criteria, e.g. the file size of each webpage should not be more than 20k, or e.g. A user should be able to execute all the transactions without encountering an error. 4.Establish clarity of purpose. A face-to-face meeting may be held with the customer to ensure that you have understood their requirements correctly. 5.Build customer checkpoints so that the customer is involved at critical junctures in the project. This ensures that what mistakes were discovered and learned are adjusted quickly.



Introduction to the WBS The Work Planning process is divided into three phases, viz. Work Breakdown Structure (WBS) Development, Time and Cost estimation, and Schedule development. The Work Breakdown Structure (WBS) is a hierarchical description of all the work that must be done to meet the needs of the customer. While the three activities, viz. WBS development, time and cost estimation, and schedule development are listed in a certain order in the framework, a Project Manager who has gained some experience in the process may actually perform the three activities in a different order. No particular software or tool is recommended for a project work plan. The Project Manager could use MS Project, MS Excel, or even a whiteboard (reserved for the project through the project life cycle).



Work Plan- Work Breakdown Structure—Activity Definition Purpose: The objective of this activity is to identify and organize the project into activities, sub-tasks, and work packages needed to achieve goals. This establishes the base for the Project Manager to estimate the duration of the project, determine the required resources and schedule the work. The Work Breakdown Structure (WBS) is a hierarchical description of all the work that must be done to meet the needs of the customer. Participants: The Project Manager develops the Work Breakdown Structure in consultation with the core project team. Inputs: Project Request Approval Form [1], Project Overview Statement [1], Quality Strategy [1], Project Approach [2], Business Case [4] Process: 1. Two approaches can be used to identify project activities. 2. The first is the top-down approach.

a. Be clear about the goal in the Project Overview Statement. b. Break down the goal into deliverables. c. Identify activities that must be performed from the beginning to the

completion of the project. d. Break down the deliverables into activities. e. Successively decompose work into smaller, more manageable components

until you are satisfied that the work is defined at a sufficient level of detail to allow you to estimate time, cost and resource requirements. The purpose is to provide better management control.

3. Another approach to identify project activities is the bottom-up approach. a. The entire planning team agrees to the first-level breakdown. b. The team is divided into as many groups as there are first-level activities. c. Each group then makes a list of the activities that need to be completed in

order to complete the first-level activities. d. Someone in the group identifies an activity and tells it to the group. If the

group agrees, then the activity is written on a slip of paper and put in the middle of the table. The process repeats itself until no new ideas are forthcoming.

e. The group then sorts the slips into activities that seem to be related to one another. This helps the planning team add missing activities or remove redundant ones.

f. Once the team is satisfied it has completed the activity list for the first-level breakdown, the members are finished. Each group then reports to the entire planning team the results of its work. Final critiques are given, missing activities added, redundant activities removed.

4. Define for each task how the work will actually be organized and accomplished. 5. Check that all deliverables have been accounted for.



6. Account for reviewing tasks and documentation. 7. Verify to see if the lower-level items are both necessary and sufficient for completion

of the decomposed items. 8. Verify to see if each item is clearly and completely defined.

Outputs: Work Breakdown Structure



Work Plan—Work Breakdown Structure—Guidelines

1. The Work Breakdown Structure (WBS) is used to develop and confirm a common understanding of the scope of the project.

2. Each descending level represents an increasingly detailed description of the project deliverables.

3. Breaking down work into a hierarchy of activities, tasks, sub-tasks, and work packages is called decomposition. Decomposition involves subdividing the major project deliverables or subdeliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities.

4. The items at the lowest level of a branch may be referred to as work packages. 5. The top-down approach begins at the goal level and successively partitions work

down to lower levels of definition until the participants are satisfied that the work has been sufficiently defined.

6. The bottom-up approach is more like a brainstorming session than an organized approach to building the WBS.

7. Check to see that all deliverables have been accounted for. 8. Ensure that testing and training is accounted for. 9. Ensure that documentation and review activities are planned. Ensure that

product/service launch and implementation activities are planned. Ensure that delivery approval cycles are accounted for.

10. Include Project Management deliverables on the project as well e.g. delivery of the specifications document or preparation of test cases. Include any deliverables that must be met or delivered by the customer. Review the Communications document and the Project Approach for any deliverables that need to be included in the WBS.

11. A top-down approach or a bottom-up approach can be used in order to develop a Work Breakdown Structure. The top-down approach is recommended though.

12. The six criteria to test for completeness are: a. Status/completion is measurable. If someone asks about the status of the

task, and the task is defined properly, the question should be easily answered.

b. Start/end events are clearly defined. Once the start event has occurred, work can begin on the task and the deliverable is most likely the end event.

c. The activity has a deliverable. The deliverable is a visible sign that the task is complete.

d. Time/cost is easily estimated. This allows you to aggregate to higher levels and estimate the total project cost and the completion date.

e. Activity duration is within acceptable limits. There is no fixed rule for the duration of an activity.

f. Work assignments are independent. Once work has begun on the task, it can continue without interruption and without the need of additional input or information until the task is complete. You can however choose to schedule it in parts because of resource availability.



13. The WBS activities at the lowest levels of granularity must always be expressed in verb form.

14. There are 3 general structures to the WBS: a. Deliverables-based structures: The components of the WBS are the

deliverables. b. Task-based structures: This defines the deliverables in terms of the actions

that must be done to produce the deliverable. c. Organizational structures: This defines the deliverable of the project work

in terms of the organizational units that will work on the project. 15. WBS templates of similar projects can be used effectively.



Work Plan—Estimating Time and Cost—Activity Definition Purpose: The objective of this activity is to estimate the time and cost for the lowest level of your WBS. This will be an input to the development of the schedule. Participants: The Project Manager estimates the duration and cost for each task in conjunction with the task owners or other Subject Matter Experts. Inputs: Work Breakdown Structure [1] Process: 1. Look at the lowest level of the WBS. 2. Estimate the likely amount of labor/effort that will be spent on the activity keeping in

mind resource capabilities. 3. Estimate the cost likely to be incurred on the activity. Cost may not be tracked for all

classes of projects. 4. Project teams may also choose to incorporate an additional time frame called

contingency or buffer that can be added to the activity duration in recognition of schedule risk. This can be a percentage of the estimated duration or a fixed number of hours.

5. Validate the time estimates with the task owners. 6. Allocate time for reviewing tasks. Also allocate rework time. 7. The cost for each task is the product of the blended rate and the effort for that task. Outputs: Time and cost estimates



Work Plan—Estimating Time and Cost—Guidelines 1. There are many approaches to estimate time and cost for the lowest level tasks of a WBS.

a. Historical Information b. Similarity to other tasks c. Expert advice d. Delphi method e. Three-point method f. Wide-band Delphi method

2. Historical information is often available from one or more of the following sources: a. Project Files/Historical data b. Project team knowledge

3.There is a difference between effort/labor and duration. The duration of a task is the elapsed time in business working days (not including weekends, holidays, or other non-work days) required to complete the task. Work effort is labor required to complete a task. That labor can be consecutive or nonconsecutive hours. e.g. If 2 persons work simultaneously for 4 hours each continuously, the duration is 4 hours but the effort is 8 hours. OR e.g. if a person needs a document to be reviewed, the review itself takes around 30 minutes but the time for the document to reach the reviewer’s office, the time the document is in the ‘in-tray’, and the time for the reviewed document to be sent back adds to say, 7 days. In this case, the duration is 7 days but the effort is 30 minutes.

4.Keep in mind resource capabilities. There might be norms with regard to average productivity in your department.

5.Estimate task duration based on using people of average skills. 6.Assume that the average person works at 75% efficiency during a workday. 7.If there are hand-offs during the project due to a team member moving out of the

organization or moving to another project, take into account the learning curve of the person who will be replacing him/her.

5. The actual task duration could vary depending upon the skill level of the person who is actually assigned to the task. 6. Task duration could also depend on resource availability. Planned vacations should be considered while estimating time. 7. For estimating cost, use the blended rate agreed upon in your department. Cost may not be tracked for all classes of projects.



Work Plan—Schedule Development—Activity Definition Purpose: The objective of this activity is to identify dependencies between tasks, assign resources for each task, look at overall dates, and identify start and end dates for the tasks. The Project Manager can use the schedule to plan, and implement project tasks and monitor the progress of the project. Participants: The Project Manager develops the Work Plan/schedule with assistance from the core project team, customer representation, and experts within and outside the organization. Inputs: Project Overview Statement [1], Work Breakdown structure [1], Time and cost estimates[1], Project Approach[2], Business Case[4], Governance Document[4] Process: 1. Identify outputs of which tasks are required in order to perform a certain task. This

identifies dependencies between tasks. 2. Sequence the tasks. 3. For each task, identify resources that are required. You may not know the name of the

person who will be assigned to your project at this stage. 4. Conduct an informal review with key resources to see if all elements of the Project

Approach have been incorporated into the Work Plan. 5. Check if testing and training are accounted for. 6. Check if implementation activities are accounted for. 7. Identify the critical path. 8. Once an overall schedule is set, the Project Manager is responsible for monitoring the

progress of the project and revising the schedule if needed. This must be done in consultation with the task owners.

9. Once the Project Manager knows who will be working in the project team, s/he can identify the resource by name. Identify resource availability.

10. Once the schedule is developed, check to see if resources are over-allocated. If they are, figure out ways to level resources so that they are allocated with the right amount of work.

11. For Class 1 and 2 projects, the Work Plan needs to be approved by the project sponsor, and the appropriate managers. For Class 3,4, 5 projects, the Work Plan is part of the Integrated Project Plan, which needs to be approved.

Outputs: Work Plan Top



Work Plan—Schedule Development—Guidelines 1.The WBS should be used as a guide while preparing the schedule. 2.Determine if any code or elements from any other project can be reused. 3.All the tasks associated with the project deliverables need to be identified. Define the

activities that must occur to produce each deliverable. 4.The task names should adequately describe the task to be completed. 5.Check to see if any code/element from any other project can be reused. 6.Identify dependencies. Dependencies can be FS (Finish-to-start), SF (start –to-finish), SS (start-to-start) or FF (finish-to-finish).

• FS dependency for Task 44 means that the predecessor tasks need to finish before task 44 can start.

• SF dependency for task 44 means that the predecessor tasks need to start before task 44 can finish.

• SS dependency for task 44 means that the predecessor tasks need to start before task 44 can start.

• FF dependency for task 44 means that the predecessor tasks need to finish before task 44 can finish.

Determine the sequence of the tasks. Ensure that all preceding tasks have been identified for each task. A Program Evaluation and Review Technique (PERT) chart or a network diagram could be used to identify dependencies.

7.Identify resources required for the project. 8.Allocate tasks to resources. Once you know exactly who will be assigned to the project,

ensure that personnel calendars containing scheduled vacations and time off are taken into account. Ensure that you have taken into account any vacation time that the customer has planned. In some cases a task might be a resource-constrained. e.g. a review can begin only after the customer is back from his/her vacation.

9.The Schedule needs to be in sufficient detail to enable one to manage the project. 10.The Project Manager should spend an appropriate amount of time on planning activities. e.g. as a rule of thumb the following table could be used for experienced Project Managers with subject matter expertise.

Class Minimal Time spent on Planning activities Class 1 4 hours Class 2 8-10 hours Class 3 40 hours Class 4 60 hours Class 5 80-100 hours

Project management effort (including defining, planning, launching, managing, and closing activities), as a thumbrule, is estimated to be about 20% of the production effort. 11. Identify the critical path. The critical path is the path where any slippage in any task will cause a delay in the end date of the project. 12. After developing the Work Plan, check if any resources have been over-allocated. If they are, figure out ways to level resources so that they are allocated with the right amount of work. If a task is not meeting planned limits, you can add more resources to



the task so that the task can be performed faster. This is called crashing the task.



Risk Management Strategy Plan—Activity Definition Purpose: The objective of this activity is to define how risks will be identified, determine who owns the responsibility of identifying risks, decide at what frequency the risks need to be revisited, identify the risk monitoring tool, determine to whom risks will be escalated, define how to manage risks, and how to handle issues that are likely to become risks. Participants: The Project Manager prepares this document. Inputs: Project Overview Statement [1], Work Plan [1], Project Approach [2], Business Case [4], Governance Document [4] Process: 1. Determine a process by which risks to the project can be identified. 2. Determine the risk-monitoring tool the project will use. 3. Determine who owns the responsibility for identifying risks. 4. Define the roles and responsibilities for all resources (both within and external to the

project) involved with the identification, review and mitigation of risks, and updating the risk matrix.

5. Decide the frequency for revisiting the risks and allowing newly identified ones to be defined and planned for.

6. Identify the stakeholders who will be informed of risks that might be severe and that have a high probability to occur.

7. Determine the type of strategies that will be used to manage risks. 8. Discern between issues and risks and determine how to preempt and identify issues

that are likely to become risks. Outputs: Risk Management Plan Top



Risk Management Strategy Plan Template Project Name Date: Created By: 1. Risk Identification Process: 2. Risk Monitoring Tool to be used

3.Ownership of risk identification: a. Primary responsibility b. Contributors to risk

identification

3. Roles and responsibilities Responsible for identification of risk

Responsible for review and mitigation of risks

Responsible for updating the risk matrix

4. Frequency of revisiting the matrix

5. Stakeholders who will be informed of risks with high probability and severe impact

Weekly/bi-weekly and on the occurrence of a risk-triggering event.

6. Likely strategies to handle risks

7. Issues that are likely to become risks.



Risk Management Strategy Planning—Guidelines 1. Define the process for identification of risks. This process should identify the person

who has the primary responsibility for identifying risks. It should also identify other stakeholders responsible for contributing to risk identification.

2. Determine the risk-monitoring tool the project will use. You can consider tools used in your area of work. A simple Excel sheet may serve the purpose.

3. Define roles and responsibilities for resources involved with the identification, review and mitigation of risks, and updating the risk matrix. Generally, the Project Manager is primarily responsible for driving the risk management process. But the Project Manager may identify a team member for this purpose.

4. Decide the frequency of revisiting the matrix. The frequency depends upon the length of the project. The risk matrix should not only be updated at the prescribed frequency but also on the occurrence of any event that might change the risk for the project.

5. Identify stakeholders who will be informed of risks that might be severe and that have a high probability to occur.

6. Determine the type of strategies that will be used to manage risks. Start considering various options you may have.



Communication Management Plan—Activity Definition Purpose: The objective of this activity is to make sure that team members, customers and stakeholders have the information they need to do their jobs. Proactive communication is important on all projects. Communication is also a vital way to manage stakeholders expectations about how the project is progressing and who needs to be doing what. A Communication Plan allows you to think through how to communicate most efficiently and effectively to the various constituents. Communication needs to be in the right format, to the right target audience with sufficient amount of information and at the right time. Participants: Communicator: The person who is the source of the information Audience: The people who receive the information In general, the Project Manager, project team members, stakeholders, and the customer are participants and could play the role of the communicator or the audience at any point in time. Inputs: Project Overview Statement [1], Work Plan[1], Project Approach [2], Governance document [4] Process: 1. Determine what are the target groups (internal and external) and the composition of

each group. 2. Determine, for each target group, what information needs to be communicated. i.e.

the purpose of the communication 3. Determine the frequency of the communications. 4. Decide on the format/vehicle of communication. 5. Determine who will be responsible for the communications. 6. Identify expected results of the communication. 7. Remember to include the Project Manager as an audience for communications e.g.

status reports, issues, risks, 2-way communication. Outputs: Communication Management Plan Top



Communication Plan Template Project Name: Date: Created By: Audience Communicator Communication

Type Frequency Medium of

Communication Purpose



Communication Planning—Guidelines These guidelines help in determining stakeholder communication requirements and ensuring that these requirements are met appropriately. Communication could be categorized in the following ways:

1. Internal/external 2. Driven top-down or bottom-up or at the same level

1. Determine the stakeholder i.e. the target groups (internal and external) and the composition for each group. They could be the sponsor, the operating unit Head, the project team, the Project Manager, the Project Management Office, the functional manager, other departments within OSU like the Help Desk, the customer, or external vendors. The stakeholders should include anyone who needs or will need that information. 2. Determine what information needs to be communicated to the audience. Some examples could be:

• Status Information • Weekly Deliverables & Issues • Project Issues • Completion of tasks/Schedule delay • Change in scope • Meetings • Notification of Service Implementation • Notes taken during meetings (Identify meetings in which notes need to be taken) • Communication of change • Communication with regulatory agencies • Request for Input • Change Request forms

3. Determine the audience for each communication type. 4. Determine the frequency of communication. The frequency could be daily/weekly/bi-weekly/monthly/after a certain milestone. 5. Determine the medium of communication. It could be E-mail, verbal, conference calls, meetings, written memos, newspapers, OSU website, OIT/ TELR website, formal presentations, or status reports. 6. Determine who will be sending out this communication. The communicator could be the Project Manager, the project team, the customer, the sponsor, or the functional manager. 7. Identify the purpose of the communication. The information could be mandatory, or to provide information, to build buy-in, etc. 8. Be sensitive to the needs of your audience. 9.You may tailor the same communication for different target groups. 10. Designate a person to record notes during meetings.



Issue Management—Activity Definition Purpose: The objective of this activity is to ensure that:

• Issues are identified, evaluated and assigned for resolution. • Issue resolutions that are sure to impact the scope, schedule, or quality of the

project will go through the change management process. • Issue resolutions or decisions are documented and communicated to all affected

parties. • Issues that are likely to become risks are reflected in the risk matrix.

The Issue Management process will bring visibility to issues, accountability as to how they are acted upon, and their timely resolution. Participants: Project Manager, project team, relevant stakeholders Inputs: Project Overview Statement [1], Project Plan [3], Business Case [4] Process: 1. Define the process for managing project issues. 2. Define who can raise an Issue, who is responsible for logging and tracking issues,

who can assign issues for evaluation and planning resolution actions, and other roles and responsibilities in the Issue Management Process.

3. The Issue Management process should be communicated to all project team members and stakeholders.

4. Issue descriptions, resolutions and action plans should be documented well and tracked on an issues log.

5. Define who will maintain the issues log. 6. For each issue,

a. Determine the action plan. b. Estimate the effort needed to resolve the issue c. Determine who owns the issue. d. Track the status e. Verify that the issue is closed if the status shows it as closed

Outputs: Issue Management Plan, Issues log Top



Issue Management Plan Template Activity Comments Responsibility to

resolve Frequency of Tracking

1.Raising an issue Anyone can raise an issue

Project Manager Weekly

2. Logging and tracking

Project Manager Weekly

e.g. Inter-team conflict issues

The team members should try to resolve it between themselves first. If a resolution is not possible, then raise the issue to the Project Manager

Project Manager

Scope/functionality issues

This may impact cost or schedule, hence raise to Project Manager immediately.

Project Manager

3. Assigning an issue for evaluation and resolution

Project Technical Lead

Above are only a few examples of the kinds of issues that one might want to plan for. The list for your project may be longer.



Issues Log Template An example is provided below: Issue Action

Plan Effort Responsibility

(Issue owner) Date Status

(Open/Action being implemented/ Resolved)

Comments by issue owner

Closed (to be filled by the Project Manager)

Issue 1

Action 1

8 hours


Jan 24th, 2004

Open Still open as we are awaiting customer information

Action1 8 hours


Jan 28th, 2004

Action being implemented

Action 1

6 hours


Feb 1st, 2004

Resolved Action completed. Issue resolved

Closed.

Issue 1

Action 2

40 hours

Graphic designer and content developer

Jan 26th, 2004

Open Can be implemented only after new software arrives

Change Request filed for approval

Issue 2

Action 1

12 hours

Technical lead Jan 30th, 2004

Open To be implemented after completion of task 147 in schedule



Issue Management—Guidelines 1. An issue is an immediate problem requiring resolution. 2. Anyone can raise issues. Issues can be raised in team meetings or during one-on-one

conversations with the Project Manager. 3. Resolve issues as soon as possible. Try to solve the root cause; not the symptom. This

will ensure that the problem will not resurface. The methods that can be used for solving an issue are: a. Fishbone diagram: Describe the problem or symptoms. Identify potential causes and categorize them. Look at detailed explanations for each cause. Again look at reasons behind the explanation. This will help in arriving at the root cause of the problem. Create an action plan to resolve this. b. Pareto diagram: This will help in categorizing problems according to the frequency with which they occur. You need to focus on the problems with high frequency at first.

4. It may be difficult in some cases to determine any good options for resolution. A less-than-perfect solution may be preferable to deadlock. 5. As a Project Manager, you need to encourage people to accept responsibility and make decisions when appropriate. 6. If there is an impact to effort, scope, cost or schedule, the Project Manager should be involved. If there is an impact to effort, scope, cost or schedule, a Change Request might need to be filed, and the issue becomes a change. 7. If there is an impact to risk, the risk matrix might need to be updated. 8.The formality of the issue management process varies with project size e.g. a Project Manager may resolve an issue concerning a small project but a governance committee might need to step in for larger projects.



Quality Assurance Plan—Activity Definition Purpose: The objective of this activity is to validate that the major deliverables are completed and that the processes are being implemented with an acceptable level of quality. Participants: The Project Manager prepares this document in consultation with the customer representative. This document should be reviewed and approved by the relevant governance structure. Inputs: Project Overview Statement [1] Process: Product-related QA 1. Ensure that all required Quality Assurance activities for the project are defined.

Ensure that in-process control plans, which address quality control areas, are defined. Revise the Quality Strategy as required.

2. Identify quality standards of the University, the customer, or any external organization that need to be followed for the project.

3. Identify guidelines for each function to follow. Make a checklist including all these guidelines.

4. The project team and major stakeholders should have agreed on the completeness and correctness criteria up-front.

5. Try to identify problems that the project may face. 6. Determine if external QA is recommended. Project-related QA 1. Determine the frequency of reviews of the project plans to check for task slippage and

any dependencies that might be affected. 2. Determine the frequency of receiving (status reports, etc) and responding to

communications. 3. Determine the frequency at which you would want to interview stakeholders and the

project team to provide them with feedback, to discuss issues and to get feedback from the project team.

4. Determine the frequency at which you will check for any improvements or changes that could be done to a process. Determine who in the project team will share this responsibility.

Outputs: Quality Plan, Checklists Top



Quality Assurance Planning Template Project Name Date Created By: 1. Acceptance criteria Quality standards of organization, customer or external organization

Checklists to be referred to 2. Potential problems the project could face

3. External QA recommended? Yes/No Project-related QA 3. Frequency of project plan reviews

4. Frequency of responding to communications

5. Frequency at which you would want to interview stakeholders

6. Frequency at which to check for process improvements



Quality Assurance Planning—Guidelines Product-related QA 1. Ensure that Quality Assurance activities for the project that will be carried out by

various human resources are described in adequate detail. Define in-process control plans, which address quality control areas, what audits and reviews are required, when these audits and reviews will be conducted and how variance to acceptance criteria will be reported and resolved.

2. Identify quality standards the project should follow. 3. Identify guidelines to be followed. Making a checklist of these guidelines may be

useful. The team can use the checklist while executing the project. 4. Describe acceptance criteria for deliverables, as they will be used in product

acceptance testing. The purpose of the completeness and correctness criteria is to work with the customer up-front to define what it means for a deliverable to be considered complete and correct.

5. Try to identify problems that the project may face. e.g. the Project Manager may think that stress testing is essential for the project’s success.

6. Determine if an external QA resource is required. The QA resource should audit work products throughout the software lifecycle to verify that they comply with the applicable project plans, procedures, and standards. The results of the audits and reviews are shared with the appropriate Project Managers and teams to facilitate continuous improvement in processes and products and to promote a reduction in practices that produce defects. The Project Manager should develop a schedule of audits and reviews of the testing program based on the testing activities documented in the project's test plan.

Project-related QA 7. Determine the frequency of project plan reviews to check for task slippage and any

dependencies that might be affected. The Project Manager may decide to update the project plan daily/weekly but may decide that another person (or the Project Manager) will review the project plan to check for task slippage.

8. Determine the frequency of responding to communications. In the ideal scenario, all

communication should be responded to immediately. 9. Determine the frequency at which you would want to interview stakeholders and the

project team to provide them with feedback, to discuss issues and to get feedback from them.

10. Determine the frequency at which you will check for any improvements or changes

that could be done to a process. Determine who in the project team will share this responsibility. e.g. a fishbone diagram analysis could be used to determine the root cause of a problem. This could point to a defect in a process, in which case a process change/improvement could solve the problem.



Resource Plan—Activity Definition Purpose: The objective of this activity is to document how many resources and what skills are required during the various phases of the project, how the resources will be acquired, to examine if any of the human resources need training and if so to ensure that they receive the required training. Participants: The Project Manager prepares the resource plan in conjunction with the core Project team. Inputs: Project Overview Statement [1], Approved Project Request form [1] Process: 1. Determine the type and amount of resources that will be needed in order to complete

the project. e.g. human resources and other resources like hardware, software, etc. 2. After establishing the number of human resources required for the project, develop a

staffing plan that shows the number of personnel, by role, by skills required, and by skill level that will be required on the project on a monthly basis.

3. Determine the estimated quality and output of the physical resources. 4. Determine the availability of the required resources. 5. Determine the cost of the resources. 6. Determine the percentage of time that the resource will be spending on your project

and provide for contingencies. Outputs: Resource Plan Top



Resource Plan Template Project Name: Date: Created By: 1. Resource Requirements:

a. People: b. Software: c. Hardware: d. Money: e. Materials: f. Supplies: g. Equipment: h. Facilities:

2. Staffing Plan e.g. Month Resource role Skill Skill Level Number Jan. 2005 Technical SQL Advanced 2 Graphics Photoshop Intermediate 1 Graphics Photoshop Advanced 1 Graphics Flash Advanced 2 Feb 2005

3. Estimated quality and output: e.g. Batch processing for Machine A 4. Availability of the required resources: XYZ on vacation from Jan 17th 2005 to Jan 25th 2005 5. Cost of resources: e.g. Resource Cost per unit No. of units Total cost Consultant 200 USD per hour 40 hours 8000 USD Machine B rented 250 USD per day 8 days 2000 USD 6. Sharing of resources: A 75% time on project 7. Contingencies: 1 extra day for Resource B’s work 8. Training Needs: e.g. Resource Training/Skill Current skill level Desired skill level XYZ .Net Beginner Intermediate



Resources Planning—Guidelines

1. Determine what are the resources you will need in order to execute the project. This listing may include people, software, hardware, money, materials, supplies, equipment, facilities, etc.

2. Develop a staffing plan. A matrix could be used to display the number of personnel required for the project by role, by skills required, by skill level on a monthly basis. This will give the Project Manager clarity on the number of requests s/he will have to send to the Resource Manager.

3. Determine the estimated quality and output of the physical resources. This is necessary so that a check is done to find out if the physical resources are sufficient or not. If the output is going to be lesser than required, extra physical resources might be needed.

4. Determine the availability of the required resources. This is required at this stage as more than one project might have requested for the same resource. Also, check if an assigned human resource is going on vacation during the project duration.

5. Determine the cost of resources. In cases where the billing is done on a time-and material basis, this is important.

6. Determine if any of the resources are to be shared across projects. If a resource is going to be spending lesser than 100% time on your project, the schedule will be affected.

7. Provide for contingencies. Buffers or reserves or contingencies can be a percentage of the total human resource effort or it could be a certain number of days.

8. Identify and plan for training needs. Determine what skill levels are required for your project and compare these to the actual skill levels of the human resources assigned to your project. In order to bridge the gap, you might need a training intervention. The training should be accounted for in the Work Plan.



Procurement Planning—Activity Definition The University procurement process supersedes this document. Purpose: The objective of this activity is to identify how project needs can best be met by procuring products and/or services outside the organization. It identifies the procurement strategies that will be used, outlines the scope of products and/or services to be procured, and identifies responsibilities for the full procurement lifecycle. Participants: The Project Manager prepares the Procurement Plan. Inputs: Work Plan [1], Resource Plan [4] Process: 1. Identify the items that will be procured and under what conditions. 2. Define who within the team will be allowed to enter into contract agreements. 3. If applicable, describe the ability (or inability) of products available in the organization

to meet the project’s requirements. Quantitative supporting information should be presented.

4. List the evaluation criteria for vendors. 5. Identify any constraints that may affect the procurement process. 6. Identify the method(s) by which new products may be obtained. i.e. Lease/Purchase,

Bid process, etc. 7. Identify the officials who must approve any purchases. 8. Provide schedule information for all the relevant procurement activities. 9. Identify any hardware/software compatibility issues that may impact the procurement

process. 10. List the required capabilities of the software. The capabilities should be determined

before evaluating the vendors. 11. Estimate the volumes of data that will be handled after the system is running for

several years. 12. Identify the manuals that will be necessary for proper installation and operation of the

software. 13. Describe the potential vendor’s method (support) of handling errors or bugs in the

software, as well as the Department’s method (if applicable). Revisions or updates to the software, and access to backup copies, should be considered. Determine who will retain ownership of the code and product.

Outputs: Procurement Plan



Procurement Plan Template Project Name: Date: Created By: 1. a. Items to be procured:

b. Under what conditions: 2. Are items currently present in the organization similar to the item being procured?

Yes/No a. If yes, please explain why they won’t satisfy the project need.

3. Responsibility for interfacing with vendors: 4. Responsibility for signing the contract: 5. Evaluation criteria: 6. Constraints: 7. Procurement Method: 8. Responsibility to approve purchase: 9. Schedule/Date of delivery for the vendor: 10. Hardware/software compatibility issues: 11. Required capabilities of the software: 12. Capability required after __ years: 13. Manuals required to be supplied: 14. Method to handle errors: 15. Are updates to the software required? If so, please provide details: 16. Is access to backup copies required? 17. Who will have ownership rights of the source code? 18. Who will have ownership rights of the product?



Procurement Planning—Guidelines 1. Decide which items will be procured and under what conditions. Determine if the

same product is present in the organization. If so, explain with supporting documentation why the current product will not be able to support project needs.

2. Decide who from the project team and organization unit can interface with the

vendors and who can sign the contract. Also, note that there might be organization-level rules regarding procurement that might need to be adhered to. In contracts over a certain value it might be necessary to involve the Legal department and the Purchase department.

3. List the evaluation criteria. This is a very important step as it ensures that the vendor

is selected on the basis of pre-set criteria and that a single person or group does not influence the decision. The criteria could include the following:

a. Technical capability, b. Quality of work, c. Previous experience in similar projects, etc.

4. Identify constraints, if any. e.g. it might be an organizational policy to work with vendors who offer 60 days credit. This will limit the number of vendors one can choose from.

5. Identify the method(s) by which new products will be obtained. i.e. Lease/Purchase,

Bid process, etc. Factors like time available might be important in determining the method to be used.

6. Identify the officials who must approve any purchases. This might include someone

from the Purchase department of the organization. 7. Provide schedule information for all the relevant procurement activities right at the

beginning. This is important, as the vendor should have resources available in order to meet the timeline set.

8. Identify any hardware/software compatibility issues. It is necessary to ensure that the

development platform that the vendor is using is compatible with what is being used for the rest of the project.

9. List the required capabilities of the software. This can be part of the evaluation

criteria. A detailed statement of requirements should be part of the contract. e.g. the system should be able to support 1000 simultaneous users.

10. Estimate the volumes of data that will be handled after the system is running for

several years. e.g. after 5 years the system should support 2.7 million records. 11. Identify the manuals that will be necessary for proper installation and operation of the

software. An installation manual may need to be supplied by the vendor at the time of delivery.



12. Describe the potential vendor’s method (support) of handling errors or bugs in the

software, as well as the Department’s method, if applicable. If a bug is reported after the product has gone live, describe how the vendor will manage the problem. Revisions or updates to the software, and access to backup copies, should be considered. These points should be considered when signing the contract and should be included in the contract if possible. Determine who retains ownership of the code and the product.



Operational Transfer Plan—Activity Definition Purpose: The objective of this activity is to lay down the pre-requisites of rolling out an application. This is to ensure the smooth transition from the ‘project’ to the ‘going live’ stage. Participants: The Project Manager, the Project team, and the customer Inputs: Work Plan [1], Change management plan [3], Resources Plan [4] Process: 1. Identify the person(s) responsible for, and involved in, all aspects of the installation

process, and define their roles. 2. Document what must be completed before installation can begin. 3. Identify what must be achieved for the installation to be deemed complete. 4. Develop a schedule of all activities involved in the installation. 5. Identify all manpower and resources required for each activity. 6. Prepare a list of the backups, if any, which must be taken prior to, and on completion

of the installation. 7. Verify that the software product meets requirements and is fully operational. 8. Verify that the product has been tested in the target environment using test cases

established in the Test Plan. Document problems and corrective actions. Retest all equipment and software after a repair, replacement, or modification. At the completion of acceptance testing, conduct an Operational Readiness Review, which includes a physical configuration audit.

9. Conduct stress and other operational tests. 10. Obtain the customer’s acceptance and approval of the product. 11. Ensure that user training has been conducted. 12. If a current system exists, prepare a checklist to ensure that the system and data

conversion is done after backups and other safety measures are taken. 13. The installation needs to be coordinated with the system owner, operations staff,

support staff, and other affected organizations. 14. Transfer responsibility of the system from the project team to the system owner and

support staff. 15. Ensure that maintenance support begins as planned. 16. For major software systems involving multiple organizations and interfaces with

other systems, ensure that a formal announcement of the transition to production has been done.

17. Turn over all project file materials, operating documents, and other pertinent records to the maintenance staff.

Outputs: Operational Transfer Plan, Checklists Top



Operational Transfer Plan Template Project Name: Date: Created By: 1. Roles and responsibilities for installation Name Roles Responsibilities XYZ Installation team leader 2. Activities that must be achieved before installation can start 3.Activities that must be achieved for installation to be deemed complete 4. Schedule for installation activities Task Duration Start date End date Predecessor Resource 5. Backups to be taken prior to installation 6. Does the product meet requirements? Is it fully operational? 7. Has the product been tested in the target environment? 8. Has the customer approved the product? 9. Has required training been conducted? 10. When does system and data conversion begin? 11. Installation to be coordinated with the following people: 12. Responsibility of the system transferred to 13. When does maintenance support have to be ready? 14. When will the announcement of the transition to production be done? 15. To whom do we hand over project file materials and other records? 16. Who is responsible for access to installation site? 17. Who will establish the availability of the environment for the system to be installed in?



Operational Transfer—Guidelines 1. Check if the product meets requirements. 2. Check if the product is fully operational. 3. Ensure that the customer accepted and approved the product. 4. Has the future system owner and support staff been identified? 5. Ensure that user training has been conducted. 6. If a current system exists, check to see if the system and data conversion has been

performed. 7. At each installation site, has the facility been inspected to assure that the site

preparation is complete and in accordance with the Installation Plan? 8. Check to see if people with whom the installation should be coordinated have been

identified. Have they been informed of the installation schedule? 9. Ensure that all necessary modifications to the physical installation environment have

been completed. 10. Has the hardware been tested? 11. Has the product been installed on the target environment and tested? 12. Ensure that all problems and corrective action have been documented. 13. Has all equipment and software been retested after a repair, replacement, or

modification? 14. Has Acceptance Testing been conducted in the production environment using

acceptance test data and test procedures established in the Acceptance Test Plan? 15. At the completion of acceptance testing, has an Operational Readiness Review, which

includes a physical configuration audit, been conducted? 16. Ensure that stress and other operational tests have been conducted. 17. Will maintenance support begin as planned? 18. At end of transition period, will a formal transfer of all responsibilities to the support

staff be conducted? 19. For systems involving multiple organizations and interfaces with other systems, has a

formal announcement of the transition to production been done? 20. Ensure that all project file materials, operating documents, and other pertinent records

have been turned over to the maintenance staff. 21. Ensure that all the person(s) responsible for, and involved in, all aspects of the

installation process, have been identified. 22. Have arrangements for access to installation site (e.g. badges, etc.) been identified? 23. Has the required availability of the environment for the system to be installed in been

established? 24. Has the data to be recorded at the installation site and collected after installation been

identified? e.g., hardware and software configurations.



Integrated Project Plan—Activity Definition Purpose: The objective of this activity is to ensure that the various elements of the project are properly coordinated. The Project Planning Process provides a framework to develop project plans. Using the activities detailed in this process description and in supporting documents, project teams describe the work they will do, develop estimates of effort, develop a schedule, plan their management and technical approaches, identify measures to gather, and develop a risk management approach. Participants: The Project Manager prepares this document. Inputs: Quality Strategy [1], Project Overview Statement [1], Work Breakdown Structure[1], Time and Cost Estimates[1], Work Plan[1], Project Approach[2], Communications Plan[3], Risk plan[3], Business Case[4], Operational Transfer Plan[4], Resource Plan[4], Procurement Plan[5]. Process: 1. Collate all the planning elements. 2. Based on the class of the project, the integrated project plan will have a different

number of planning activities. Check against the framework requirements matrix to see if all the required plans are present.

3. Review the assumptions being used.

Outputs: Integrated Project Plan Top



Integrated Project Planning—Guidelines It is important that people working on a project discover early in its lifecycle what its dependencies are, what services and resources are available, and how to use them appropriately. Addressing integration requirements will help ensure that a project makes the best use of complex infrastructure, and avoids reinventing the wheel. 1. Customer expectations: - There should be a reasonable amount of clarity in terms of

customer expectations with regard to project deliverables, product requirements, overall timelines, etc.

2. Effort: - Estimate effort once more taking into account activities listed in the work breakdown structure and the project schedule.

3. Roles and Responsibilities: - Check to ensure that the governance structure is clear. Also ensure that the roles and responsibilities of the project team members in terms of quality audits/reviews, risk identification, project execution, etc. are clear.

4. Risk: - Ensure that all risks are identified and analyzed in the Risk Management Plan. Ensure that mitigation strategies are identified for all risks with high probability and severe impact.

5. Quality Plan: Ensure that all aspects of quality are taken care of. The quality plan should list out acceptance criteria, in-process control plans and the schedule of quality audits and reviews.

6. Schedule: - The schedule should have reviews built in. 7. Ensure that all relevant factors have been considered in the various plans. 8. Ensure that documents like the Project Overview Statement, Business Case, the

Project Approach document are available and correctly represent the project situation. 9. Ensure that the communication plan has identified all stakeholders who need to be

informed of various pieces of information. 10. Ensure that training needs of the project team are identified and met.



Team Assignment—Activity Definition Purpose: The objective of this activity is to ensure that individuals with the required skills are assigned to a project, and to level resources in the Work Plan. This activity may start as early as the WBS development activity. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Work Breakdown Structure [1], Time and Cost Estimates [1], Work Plan [1]. Resource Plan [4] Process: 1. Assign the team to the project. 2. If team members have already been granted vacation time, then schedule work

accordingly. 3. Check for availability of the team member through project execution. 4. Check for resource sharing. 5. Ensure that no resource is over-allocated. 6. Resolve conflict between resource availability and project Work Plan 7. Define and assign work packages to team members. 8. Discuss any issues regarding work packages that the team member might have. 9. Adjust the work plan as needed.

Outputs: Team Assignments Fine-tuned Work Plan Top



Team Assignment—Guidelines 1. Assign the team: You will need to negotiate with the Functional manager to ensure

that the resources with the right skill levels are assigned to the project. Take expert opinions to find out who’s best for the job and when that person will be available for the project.

2. Resource availability and Schedule: - It might be that a team member has already got some vacation time scheduled and approved or its possible that a resource has been assigned to two projects and hence only 40% of the resource’s time will be spent on your project. In all these cases, it becomes necessary to schedule work taking into account the actual time the resource will spend on your project.

3. Resource leveling: -Ensure that no resources are over-allocated. Its necessary to ensure that conflicts between resource availability and the project schedule is resolved.

4. Work packages: Work packages should be defined at the lowest possible level. They should be assigned to team members appropriately. Describe the work packages in a way that the team members can comprehend what is expected of them.

5. Issues regarding the work packages: Team members may want to discuss questions/doubts regarding work packages.



Launch Kick-off meeting—Activity Definition Purpose: The objective of this activity is to ensure that all the project team members are aware of the ground rules of the project. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Project Overview Statement [1], Work Breakdown Structure [1], Time and cost estimates [1], Work Plan [1], Project Schedule [1], and Integrated Project Plan [3], Process: 1. The Project Manager should walk the team through the Project Overview statement. 2. The Project Manager can present a high-level level Gantt chart of the schedule. 3. The Project Manager can inform the team members of the communication plan. 4. The team members should also be informed of the frequency of the status reports. 5. The Project Manager should discuss the process for resolving conflicts, and if

necessary define an escalation process. 6. The Project Manager should inform the team of the ground rules set for the project.

The Project Manager should inform the team of the working style, and the overall process the team should follow for project execution, reviews, etc.

7. Notes from the meeting need to be recorded and circulated.

Outputs: Notes from the meeting Top



Launch Kick-off Meeting Agenda Template Project Name

Start Date

End Date

Project Manager

Project team

Stakeholders

Discussion of the Project Overview Statement

Discussion of Communication Plan (if class 3,4, or 5)

Ground rules of Communication (if Class 1, 2)

Conflict resolution process: viz. roles and responsibilities,

Operating Rules and expectations (Working style, etc.)

Clarification of success criteria, objective, etc.

Discussion of overall milestones and high-level Gantt

Questions

Recap / summary



Launch Kick-off Meeting—Guidelines

1. Send out a meeting announcement with a meeting agenda to attendees with project objective, meeting objective and time frames. If team members can or cannot attend they are required to ‘RSVP’ to you. That requirement needs to be stated in the meeting announcement. 2. Prepare the meeting agenda in advance and take copies of the agenda to the meeting for the participants. 3. Prepare handouts for the meeting, if necessary. 4. If the project belongs to Class 3,4, or 5, the communication matrix in the communication plan can be discussed in this meeting. If the project belongs to Class 1 or 2, the ground rules of communication can be discussed. 5. A conflict resolution process should be agreed upon. The escalation procedure detailed in the governance document should be discussed. 6. The ground rules for the project should be set and communicated to the team. The Project Manager should inform the project team what the Project Manager’s expectations are of the team. e.g. The Project Manager may decide that email is the primary form of communication even if a team is co-located. The Project Manager may expect that the team members check their office email every hour. Or, Problems regarding overload due to project work conflicting with work on other projects should be escalated to the Project Manager. Or, time sheets need to be filled out on a daily basis. The working style, and the overall processes should be discussed. e.g. Setting times of availability during the workday- in case the Project Manager is handling multiple projects, s/he can set aside a block of time everyday when a team member can walk in and discuss issues. For urgent issues, the Project Manager should always be available to the team. Or, status meetings will be held every Friday at 8.00 a.m. 7. Copies of the notes need to be sent to all project participants and the attendees of the meeting.



Initial Risk Identification—Activity Definition Purpose: The objective of this activity is to ensure that the entire team identifies risks for the project. This ensures that all perspectives are taken into account while planning for risks. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Risk Management Plan [3] Process: 1. Define category areas to consider for identifying risks. 2. Use the specified categories to identify risks that might occur and hamper the

progress of the project. 3. Categorize the identified risks and determine how threatening they are to the project.

Rate their potential for indicating risk to the project (high, medium, low). 4. For each risk identified, assess the risk event in terms of likelihood of occurrence and

its effect on project objectives if the risk event occurs. 5. Calculate the risk exposure for each risk item. Assess the risk impact. This

information will be used to prioritize the risk. 6. Initial mitigation strategies can be discussed and identified. Outputs: Risk matrix Top



Risk Management Matrix Template Category Risk Probability

(Hi-medium-low)

Impact (High-medium-low)

Exposure (A,B,C)

Mitigation Strategy



Initial Risk Identification—Guidelines 1. A risk is the probability of an undesirable outcome. An issue is something in dispute

or to be decided or an immediate problem requiring resolution. 2. Identify the categories in which risks might fall. This process will make it easier to

identify risks and will ensure that all risks are identified and documented. Risk matrices from previous similar projects could be referred to when determining categories. The categories could include:

a. Technical e.g. A gap exists in technical expertise. Our expertise in Technology A is not as high as the project demands.

b. Commercial e.g. The customer’s company has run into financial problems and it might be that they do not have the funds to cover the cost of our project.

c. Human Resources-related risks e.g. Resources with Skill A are not experts in the technology and will need to be trained.

d. Program constraints e.g. the project has to go live on May 9th. This means we have less than 8 weeks for production. This is not sufficient.

e. Customer -related risks e.g. The customer has a 9-member approval committee. This may slow down the approval process and delay the schedule.

f. Scope-related risks e.g. Scope-creep—The customer is not sure that the scope of the project will stay the same or increase. New requirements may be added.

g. Implementation-related risks e.g. The development server is not the same as the live server. This can create problems while implementing.

h. Project Management-related risks e.g. There is no single-point contact (Project Manager/coordinator) from the customer’s company.

3. Identify risks in each category. 4. Assess the risk event in terms of likelihood of occurrence (High=3, medium=2 or

low=1). 5. Determine the severity of the impact the risk has if the risk event occurs on a scale

of 1 to 3 (High=3, medium=2 or low=1). 6. The risk exposure is the product of the probability and impact. Senior management

may choose to monitor projects over a certain risk exposure.



Team Readiness—Activity Definition Purpose: The objective of this activity is to ensure that individuals assigned to a project are provided the requisite training in order to perform the job and that key goals are identified for the team members at the start of the project. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Resource Plan [4] Process: 1. Identify and plan for any training needs. 2. Training needs identified in the Resource Plan and the Integrated Project Plan need to

be met. This ensures that people achieve the appropriate skill levels required for the project.

3. Since all training necessary for each Team Member on the project is identified at the start of the project, the Project Manager can provide the team with timely training at different points in the project. The Project Manager budgets for training hours in the Project Schedule.

4. To ensure that performance management is fair, the team members in consultation with the Project Manager identify key goals at the start of the evaluation period.

5. The Project Manager communicates to the functional managers the impact to each team member’s performance management plan.

6. The Project Manager needs to communicate the performance feedback to the team member.

7. Team members need to be recognized for good work. 8. Interaction with other team members should be encouraged so as to increase team

cohesion. 9. Team members should be empowered appropriately. 10. The Project Manager needs to ensure that the appropriate tools/software are available

to the team members for performing their jobs. 11. The Project Manager should be accessible to the team members. 12. Various aspects of Team Development need to be planned for, viz. training needs,

morale boosting, performance management, recognition, access to tools, interaction, empowerment, accessibility, and team cohesion

Outputs: Key goals for each team member, Training Needs Analysis Top



Team Readiness—Guidelines

1. Training Needs: - Compare skills and skill levels of resources assigned with the required skill levels of personnel on the project. Identify skill gaps. Plan for training to bridge these skill gaps.

2. Training needs identified in the Resource Plan and the Integrated Project Plan need to be met. This ensures that people achieve the appropriate skill levels required for the project.

3. Since all training necessary for each Team Member on the project is identified at the start of the project, the Project Manager can provide the team with timely training at different points in the project. The Project Manager budgets for training hours in the Project Schedule.

4. To ensure that performance management is fair, the team members in consultation with the Project Manager identify key goals at the start of the evaluation period. These guidelines will be superseded by any policies laid down by the University. Key goals could be related to output, number of defects in product, breakthrough work done, etc. Goals should be quantitative and measurable.

5. Key goals or performance indicators need to be set for each person at the start of the year. Feedback on performance should be given to the team member at the end of the project. If the team member is not performing well, it might help if constructive feedback is provided to the person during the project so that s/he gets a chance to improve their performance.

6. Team members need to be rated on the basis of project performance. 7. The Project Manager should encourage interaction between the team members so

as to create a sense of belonging to the project group. 8. Team-building activities can be considered. It enables team participants to

increase their understanding of each other’s personal style. There will be an increased understanding of how to bring out and use the team’s strengths.

9. Teams work better and faster if they know their goal and have the freedom to act. They should be able to do whatever is necessary, within reason, to achieve their goals.

10. It is the responsibility of the Project Manager to ensure that team members have the requisite software to perform their job.

11. It is the responsibility of the Project Manager to ensure that the team member is provided the training they require in order to perform well on the job. Training interventions and mentoring should be provided to employees on the request of the Project Manager.

12. The Project Manager should build the morale and motivation of the team members. Role rotation (if possible), encouraging creativity, increasing responsibilities, etc. can be effective strategies in increasing morale.



Performance Tracking & Reporting—Activity Definition Purpose: The objective of this activity is to ensure that the team is making satisfactory progress to the project goals. The purpose is to: 1. Track all major project variables – cost, time, scope, and quality 2. Track actual project accomplishments and results 3. Provide visibility of progress as the project proceeds, so that the team and

management can take corrective action early Participants: The Project Manager is responsible for this process. The relevant stakeholders are responsible for reviewing the status reports that the Project Manager provides. Inputs: Project Schedule [1], Work Breakdown Structure [1], Project Overview Statement [1], Integrated Project Plan [3], Communication Plan[3], Time sheets[3] Process: 1. Project team members should communicate regularly with their Project Managers,

informing them of the current status of the project and managing future expectations. 2. It is the Project Manager’s responsibility to get the relevant information from each

team member. 3. The Project Manager should monitor, at an appropriate interval, progress to plan on

the key elements: a. Tasks starting and ending when expected b. Tasks open for work c. Deliverables with content and quality level required c. Level of effort as planned d. Milestones being met when planned e. Costs as budgeted f. Critical resources as planned g. Risk management progress h. Issues and action item resolution i. Review and process requests for changes to the plan j. Adherence to agreed Quality Strategy k. Status of critical path tasks

4. Project Managers should report the status of a project to the relevant stakeholders established in the governance structure regularly. The template for the status report allows for a formal, documented communication of progress to occur.

Outputs: Status Reports, Tracked Project Schedule Top



Project Status Report Template Date: Project Name: Project Manager: Project Sponsor: Period Covered: Overall Status: Has the customer given negative feedback on any of the product components delivered for review? If so, what are the comments? Are Project Risks Being Successfully Mitigated? If there are risks that still exist, please list them with the probability that they will occur. Accomplishments: Key Dates: List milestones that have been completed to date and projected milestones.

Milestone Date Completed

Due Date Comments

Reason for Deviation (if any): Identification of critical path items: Overall Schedule Status: Reason for Deviation (if any): Budget Status

Budget Actual Estimate at Completion $ Hrs. $ Hrs. $ Hrs.

Reason for Deviation (if any):



Unresolved Issues: The following issues are unresolved and require management

attention. Issue Assigned To Due Date

Change Request: The following important change requests to the project scope are being tracked. Additional detail is contained in the Project Change Control Log.

Change Request Assigned To Due Date New Risks observed: Trend Information: Is the project getting healthier or sicker?



Performance Tracking and Reporting—Guidelines

1. The Project Manager uses the project plan as a basis for monitoring. 2. The Schedule, budget, defect counts can all be used as project measures. e.g.

initial effort estimates compared to the actual effort incurred, track rate of spending compared to the planned spending, monitor schedule by tracking planned milestone dates compared to actual end dates of milestones,

3. Based on the guidelines set during the launch phase, teams might gather for regular meetings, or they might exchange information electronically.

4. Identify critical path items that might have issues. A high-level Gantt may be provided as part of the status report.

5. Formal progress reviews are conducted for all projects, to ensure that all stakeholders are kept informed of project status and progress. These reviews may be at key milestones for a project, or they may be event-driven or date-driven. Projects often hold monthly or quarterly reviews, in addition to (or instead of) project phase-based milestone reviews.



Schedule Control—Activity Definition Purpose: The objective of this activity is to ensure that tasks are executed as per schedule so that the deadline for the project can be met. If the schedule cannot be met, the relevant stakeholders need to be informed. Participants: The Project Manager controls the schedule. Inputs: Work Breakdown Structure[1], Work Plan[1], Integrated Project Plan[3], Change Request form [3] Process: 1. The Project Manager is responsible for tracking the various tasks in a project.

Tracking is done by exchanging task status information with team members and then incorporating the most up-to-date status information into your project schedule.

2. The Project team is responsible for completing the assigned activity within the given time frame with the requisite quality.

3. The project is executed as per guidelines and standards set. 4. Testing and reviews are conducted as per guidelines and standards set. 5. The Project Manager needs to review the Work Plan to identify problems or potential

problems. 6. The Project Manager reviews change control forms to see if there is an impact to the

schedule. 7. If any task, schedule or resource information has been changed, the Project Manager

needs to distribute copies of the most current project information to the project team. 8. The Project Manager needs to communicate any change in committed timelines to the

relevant stakeholders (supervisor, customer, any other Project Manager whose project is dependant on the completion of this project, etc.).

Outputs: Tracked work plan Milestone trend charts Top



Schedule Control—Guidelines

1. Determine a strategy to monitor and control progress. Ask your team members to report to you at an appropriate frequency the status of their work.

2. How will the schedule be controlled (milestones, progress to plan on activities, corrective action upon serious deviation from the plan)? Identify people in the organization that might be able to help get the project on track if tasks are not being completed on time due to lack of skill.

3. A suitable tool can be used for tracking project progress. e.g. MS Project, MS Excel, Project Load, or any other tool used in the Office of the CIO



Change Control—Activity Definition Purpose: The objective of this activity is to ensure that all changes to scope are documented and authorized by the relevant stakeholders. Participants: The responsibility lies with the Project Manager and the relevant stakeholders. Inputs: Project Overview Statement [1], Integrated Project Plan [3], Governance Document [4], Approved deliverables to date Process: 1. Any change to scope has to be communicated to the Project Manager. Look at

existing documents (e.g. customer approved design documents) to determine whether changes to scope have occurred or not.

2. The Project Manager ensures that the Change Request Form has been filled out. 3. The Project Manager and the core team analyze the Change Request and estimate the

effort, time, and cost required to implement the change request. 4. Any change needs to be communicated to the governance structure. 5. A Cost-Budget analysis needs to be done. 6. The Project Manager and established governance may approve or deny a change

request. 7. They may decide if the customer needs to pay for implementing the change. 8. The Change Request Form needs to be filed in the Project File by the Project

Manager.

Outputs: Approved or denied Change Request Form Top



Change Request Form Template

Change Request Form Change # Customer Project: Change Requestor Date submitted Date by which change request needs to be approved

Date by which change needs to take place

System Affected Change Type Scope change/ Technology change/ Other Impact Project Activities:

Cost (USD)/Effort (Hours)

Short Description

Justification Impact of not implementing proposed change

Alternatives to the proposed change

Detailed Description

or Reference Supporting Documents

Assessed By Date: Assessment Notes


Initial impact Analysis Additional Work days: Additional Cost: (of which Rework cost is______)

Resolution Notes


Final recommendation Assessment & Resolution Accepted/Change Not Accepted/Change Deferred

Customer Closeout signature

Date:



Project Manager Closeout signature

Date:

Senior Manager signature Date



Change Control—Guidelines 1. A request (requirement, change, problem, defect, or other change) can be

completed by a member of the project team or by stakeholders. 2. The Change Request needs to be prioritized. 3. An approach to handle the change needs to be identified including prioritization

against other change requests. 4. Alternatives should be identified in the event that the Change Request is not

approved. 5. The defined project governance structure (not the change requestor) needs to

review the Change Request to determine whether or not it should be evaluated for action.

6. An estimate of additional project effort, cost, schedule, and resources needs to be determined.

7. The estimates need to be evaluated and authorized by a Change Control Board identified in the Governance Document. If there is no Governance document prepared (due to the class of the project not requiring one), the relevant stakeholders should be involved in this step of the process.

8. The request can be accepted, rejected, or deferred. 9. The results of the request need to be communicated to the originator. 10. If the change is approved, the change needs to be incorporated into the project

Work Plan. 11. The changes in the plan need to be communicated and commitments established. 12. All parties affected by the change need to be informed.



Cost Control—Activity Definition Purpose: The objective of this activity is to manage project cost such that it is aligned with budgeted cost. Participants: Project Manager, Stakeholders, Sponsor Inputs: Project Overview Statement [1], Integrated Project Plan [3], Resource Plan [4], Procurement Plan [5] Process: 1. Costs are agreed upon with the sponsor at the start of the project and reviewed on

completion of the project. 2. The Project Manager is responsible for constantly monitoring the budget. 3. The variance between Budgeted cost and Project cost needs to be communicated to

and approved by the sponsor/customer. Alternately, for various reasons, the relevant stakeholders might decide to absorb the additional cost.

4. The variance between planned schedule and actual schedule needs to be communicated to and approved by the sponsor/customer.

5. The variance (positive or negative) if any should be reported in the Status Report.

Outputs: Status reports Top



Cost Control—Guidelines

1. Determine how to monitor and control performance vis-à-vis budget. 2. Address how the actual cost will be tracked against the budgeted cost. 3. Monitoring the schedule is also important as any idle resources add to the project

cost. 4. Determine if you want to use Earned Value as a measurement technique. 5. Decide how corrective actions will be implemented, and at what intervals cost

reporting will be done for both the project team and management. 6. Determine the tools and techniques to be used. 7. Include all costs of the project, including contract labor and support functions.

Costs could include hardware, software, etc.



Quality Assurance & Control—Activity Definition Purpose: The objective of this activity is to ensure that the project team meets the project requirements and that all requisite quality criteria are met. Participants: Project Manager, Project team Inputs: Quality Strategy[1], Work Breakdown Structure[1], Project Schedule[1], Test Plan[1], Test Cases[1], Project Approach[2], Guidelines established in the Project Approach[2], Integrated Project Plan[3],Organizational guidelines and standards Process: 1. This process comprises project reviews, product reviews, code reviews, testing, and

any other process that the Project Manager might think necessary. 2. All these activities need to be scheduled in the project plan by the Project Manager. 3. The Project Manager may modify the processes used to develop the product in order

to achieve the appropriate product quality. 4. It is the Project Manager’s responsibility to ensure that all scheduled reviews are

conducted. 5. The product must meet performance levels set by the customer and the project team.

The product should also comply with applicable standards. 6. Defects should be identified and categorized. Root causes should be analyzed. 7. The Project Manager needs to ensure that the testing team is provided with detailed

test cases and a test plan. The reviewers need to be provided with the Project Overview Statement and the guidelines.

Outputs: Review reports, Bug reports Top



Quality Assurance & Control—Guidelines

1. One of the purposes of quality management is to find errors and defects as early in the project as possible. The Cost of Quality includes the costs incurred to ensure quality in the product and process. This comprises external failure costs, internal failure costs, inspection costs, and prevention costs. The cost of quality may be high but it will always offset the cost spent on rework and correction if the quality assurance and control processes weren’t being implemented. This is because typically, the cost to eliminate a failure in the testing phase is five times greater than it is at the development or manufacturing phase. Effective quality management decreases production costs because the sooner an error is found and corrected, the less costly it will be.

2. Evaluate the Quality Plan on a monthly basis or at the completion of major milestones. The review should focus on whether the Quality Plan is still adequate to ensure that the project deliverables are completed within the quality expectations of the customer.

3. Document the metrics. Examples of metrics could include customer satisfaction, amount of rework, errors found during testing, etc. At the end of your project, provide feedback to the organization on the results of your quality process and report the final metrics captured.

4. Analyze the metrics to determine how your project work processes can be improved. e.g. in a training program, if the amount of rework after content is integrated into the training program is high, you might decide to introduce a review after the content is developed. This might reduce the rework.

5. When quality problems are found, implement a process to determine the cause and to make improvements in the process. Implement the improvements that were identified.

6. Testing is the last Quality control activity to ensure that the product meets the customer’s needs.

7. You can track rework to determine how much of your project time is spent working on the same problems twice.

8. Ideally, the persons conducting the reviews and the acceptance testing should not be part of the project team.



Procurement Management—Activity Definition Any guidelines set by the University in this regard supersedes this document. Purpose: The objective of this activity is to ensure that appropriate resources are employed, that the process of selection is fair and that the quality of work is acceptable. Participants: Project Manager, OSU Purchasing department, and OSU Legal department Inputs: Project Schedule[1], Work Breakdown Structure[1], Integrated Project Plan[3], Procurement Plan[5], OSU Procurement Process Process: 1. A vendor is chosen according to the method identified in the Procurement Plan and

according to pre-set criteria. 2. The contract with the vendor should list complete information of the arrangement

between the two parties. 3. Costs and timelines need to be agreed to. 4. Include appropriate non-disclosure clauses in the contract(s) or statement(s) of work

or the purchase order(s). 5. The contract needs to be signed by authorized signatories. Outputs: Signed Contract(s)/Purchase Order(s)/Statement(s) of Work Top



Procurement Management—Guidelines 1. The vendor evaluation criteria need to be listed clearly. 2. The process of selection should be fair and based solely on the criteria. 3. If you want periodic reporting, you need to make sure it is included in the contract. 4. If you want to validate that interim deliverables are acceptable to your company, you

need to agree on completeness and correctness criteria ahead of time. 5. The scope of work needs to be clearly defined in the statement of work/contract. 6. Ensure that you document who retains ownership of the source code and the product. 7. Agree upon and document the credit terms.



Risk Management—Activity Definition Purpose: The objective of this activity is to reduce the probability of the identified risks, identify mitigation strategies, identify contingency plans for the more critical risks, and if realized, reduce the impact of these risks. Participants: The Project Manager monitors risk. Relevant stakeholders should be aware of the risks. Inputs: Risk Management Plan[3] Process: 1. Project with a high-risk exposure maybe subject to monitoring by senior

management. 2. Plan Risk Mitigation strategies. These strategies need to be implemented. The Project

Manager needs to prioritize the risks and implement the mitigation strategies that pertain to risks with a high Risk Exposure. Determine the options and actions to reduce the likelihood of occurrence or consequences of impact to the project’s objectives.

3. Develop Contingency plans. The most serious risks (high probability/high severity) may require a more detailed outline so that the contingency plan can be quickly implemented under the worst-case scenario.

4. Monitor and update the Risk Matrix at an appropriate frequency. Outputs: Revised Risk Matrix, Contingency plans Top



Risk Management—Guidelines

1. A mitigation strategy involves working to lessen risk by lowering its chances of occurring or by reducing its effect if it does occur. A contingency plan is an alternative for action if things don't go as planned or if an expected result fails to materialize.

2. Create a response plan for each identified risk to ensure the risk is managed successfully. This plan should include activities to manage the risk, as well as the people assigned, completion dates and periodic dates to monitor progress. There are four major responses to a risk

a. Leave it: This is when the project team decides not to deal with the risk or is unable to identify a suitable response strategy. A contingency plan may be developed.

b. Avoid it: The project team may consider changing the project plan to eliminate the risk or to protect the project objectives from the impact of the risk.

c. Move it to a third party: The project team may consider transferring the consequence of the risk together with the ownership of the risk response to a third party.

d. Mitigate it: Where it is possible, the project team may decide to reduce the probability of the risk occurring or reduce the consequences of an adverse risk event.

3. Evaluate the medium-level risks next to determine the risk response plan. 4. Add the activities associated with the risk plans to the project Work Plan to ensure

that the work is completed. This keeps the Work Plan the primary focus of all work planning and monitoring.

5. The Project Manager needs to monitor the risk plans to ensure they are being executed successfully. New risk plan activities should be added to the plan if necessary.

6. The Project Manager also needs to periodically evaluate based on current circumstances. New risks may arise as the project is unfolding. This ongoing risk evaluation should be performed.



Information Distribution—Activity Definition Purpose: The objective of this activity is to ensure that all appropriate parties are kept informed. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Integrated Project Plan [3] Process:

1. Execute Communication Management Plan. 2. Monitor and revise communication management plan as necessary.

Outputs: Instrument decided in Communication Plan Top



Information Distribution—Guidelines 1.All relevant information needs to be communicated to the appropriate parties at the right time and in the appropriate format. 2.The frequency of team meetings depends on the timetable for the project and the need to get information in a timely manner. For instance, if the project is three weeks, the team might want to meet twice a week. If the project is eight weeks, weekly is probably appropriate 3. Managing communication on a project is very much a matter of managing expectations. Status Reports, for instance, are a way of communicating to stakeholders how the project is progressing against its schedule and budget. You include information on issues, scope change, risks, etc., as a part of providing information to manage expectations.



Time Tracking & Management—Activity Definition Purpose: The objective of this activity is to ensure that all time spent on a project is tracked. At an organizational level, this information can be analyzed and used to estimate likely effort and cost for similar projects. Participants: The Project Manager, Team members Inputs: Integrated Project Plan [3] Process: 1. All team members in addition to the Project Manager need to track the amount of

time they spend on a project. 2. The Project Manager needs to ensure that time tracking is done. 3. The Project manager can create variance reports and reflect the variances in the

project work plan. Outputs: Time Sheets, Variance Reports, and Estimates for future projects

Top



Time Tracking and Management—Guidelines

1. If team members do not enter the amount of time spent on a project activity, new projects may be estimated incorrectly. This information can be used in estimating time for activities in the later phases of production of the same project as well. Likely slippages in meeting deadlines can be detected if team members track time regularly.

2. Once enough data is collected, someone at an organizational level should categorize projects by type and determine productivity numbers for each type of project.

3. Deviations from the average productivity numbers should be examined closely. 4. The Project manager should secure management support to track time. 5. It is recommended that time tracking and management be done weekly.



Transition to Production—Activity Definition Purpose: The objective of this activity is to ensure that the transition of the project to production is smooth. Participants: The customer, Project Manager, the Project team, and the relevant stakeholders Inputs: Project Schedule [1], Approved Acceptance Test Plan [1], Communication Plan[3], Integrated Project Plan[3], Governance Document [4], Operational Transfer Plan[4] Process: 1. Ensure that all planned testing such as User testing, system testing, and load testing

has been completed prior to transition. 2. Ensure that all customer requirements are met and that the product is fully

operational. 3. Ensure that every step in the Operational Transfer Plan is carried out. 4. The Project Manager ensures that the customer has accepted the product before the

Transition to Production. 5. Follow the standard operating procedure pertaining to backups for your work-unit. A

Summary Report on the project is prepared and added to the project file. Outputs: Customer Sign-off, support sign-off, Summary Report, System gone live

Top



Summary Report Project Name: Project Manager: Project Description:

Initial Estimated Effort:

Revised estimated effort:

Actual Effort: Initial Estimated Cost: Revised estimated cost:

Actual Cost: Deliverables: Initial End date: Actual End date: Lessons Learned:

Recommendations for future projects:



Transition to Production—Guidelines 1. The Project Manager ensures that all the necessary testing is carried out. 2.The Project Manager ensures that the completeness and correctness criteria of the project are met. 3. If there is no Operational Transfer Plan, the Project Manager needs to ensure the following:

a. Identify the various roles and persons responsible for those roles in the installation process.

b. Identify what must be achieved to assume that installation is complete. c. Prepare a list of backups. d. Ensure that user training is conducted. e. If a legacy system exists, ensure that system and data conversion is performed. f. Installation needs to be coordinated with the system owner. g. Transfer responsibility to the system owner. h. Ensure that maintenance support begins as planned. i. Turn over all pertinent documents to the maintenance staff and to the system

owner. 4. The summary report for the project needs to be completed and filed.



Wrap-up Meeting—Activity Definition Purpose: The objective of this activity is to ensure that the project team discusses the project after the project has been executed so that Lessons Learned are captured and issues are analyzed. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Project Schedule[1], Bug Reports[1], Review Reports[1], Integrated Project Plan[3], Operational Transfer Plan[4] Process: 1. The Project Manager calls this meeting and sends the agenda of the meeting to all the

participants. All stakeholders and the entire Project team attend this meeting. 2. The Project Manager, stakeholders, and the team members discuss the project

experience including problems faced during project execution. 3. Solutions to such problems are suggested and discussed. 4. Lessons Learned are discussed. 5. The minutes of this meeting are recorded and distributed. Outputs: Minutes Top



Wrap-up meeting—Guidelines 1. Prepare an agenda ahead of time. 2. Make sure everyone knows why you are meeting, what you hope to accomplish, and

what information they are expected to bring to the meeting. 3. Organize the meeting in stages. Present information first, followed by

interpretation/discussion, then decisions and action items. 4. The focus should be on discussing project experience, problems, and best practices.



Lessons Learned—Activity Definition Purpose: The objective of this activity is to ensure that the Lessons Learned during the project are documented and incorporated in the knowledge base for future use. Participants: Project Manager, Project team, and relevant stakeholders Inputs: Minutes of the various meetings[1], Project Schedule[1], Minutes of the wrap up meeting[4] Process: 1. The Project Manager develops this ‘Lessons Learned’ document with the help of the

project team. 2. All stakeholders are welcomed to give their inputs too. 3. This document needs to be deposited in the knowledge base.

Outputs: Lessons Learned Document Top



Lessons Learned—Guidelines 1. At this point in the project management lifecycle, the Project Manager documents and

highlights what worked well in the project, documents mistakes made during the project, and documents patterns and trends identified.

2. For each lesson learned, identify a contact person to get more information so that this information can be shared with other Project Managers.

3. During the course of the project, the Project Manager, Customer, and Project Team members most likely recognized certain procedures that, when exercised, improved the production of a deliverable, streamlined a process, or suggested ways to improve standardized templates. In some cases, the outstanding “successes” might be translated into new processes to be followed by future projects.



Administrative Closure—Activity Definition Purpose: The objective of this activity is to ensure that the Project is approved, accepted and closed. Participants: Project Manager, Project team, relevant stakeholders, and the Customer Inputs: Project Schedule[1], Integrated Project Plan[4], Operational Transfer Plan[4], Required sign-offs Process: 1. The Project Manager ensures that the project is approved and accepted by the relevant

stakeholders. 2. Assess the success criteria that were identified during the Overview statement and

planning stages. Determine if criteria were met. 3. All documentation and records, physical or electronic, need to be systematically

reviewed, organized and archived. 4. The Project Manager gives performance feedback to team members. 5. The Project Manager releases resources. Outputs: Metrics Top



Administrative Closure—Guidelines

1. In the absence of a formalized project close out procedure, some projects (or project phases) risk "never ending" and the differences between project work and ongoing operations and maintenance get blurred.

2. Evaluate the product/service's conformance and satisfaction of the requirements. This will help in obtaining project and product acceptance from the customer.

3. Identify and highlight any Lessons Learned and best practices that could be useful to other project teams. Document and communicate Lessons Learned and best practices.

4. Gather data required for updating or adding to your organization's metrics. Metrics can include such information as:

a. Number of objects, classes, programs, modules and level of complexity b. Skill-set required to complete different task types c. Level of effort required for different task types by resource type

5. All the metrics and documentation needs to be reviewed by someone external to the project. This needs to be archived in the central repository.



GLOSSARY Approach: A way of doing things. For example, different approaches may be considered for implementing a project but only one will be chosen. Business Case: A document developed towards the end of the project definition phase to establish the merits and desirability of the project and justification for further project definition. This is used to justify the commitment of resources to a project. This is the information necessary to enable approval, authorization and policy-making bodies to assess a project proposal and reach a reasoned decision. Central Repository A central repository, is owned and maintained by someone within your Performing Organization, and provides a place where lessons learned and best practices can be archived for use by all Project Managers in the organization. Over time, as more and more information is added, it will become part of an invaluable knowledge base that, when leveraged, will translate into tremendous improvements on all projects. Change Control: The review, approval/disapproval, implementation, tracking, closure, and status reporting of proposed changes to an item. Overview statement: A document consisting of a mission statement, including background, purpose, and benefits, a goal, objectives, scope, assumptions and constraints. A Project Overview statement clearly documents project definition in order to bring a project team into necessary agreement. Configuration audit: A check to ensure that all deliverable items on a project conform with one another and to the current specification. It ensures that relevant quality assurance procedures have been implemented and that there is consistency throughout project documentation. Contingency Plan: An alternative for action if things don't go as planned or if an expected result fails to materialize. Cost of Quality: The cost of quality planning, control, assurance and rework. Dependencies: A relation between activities, such that one requires input from the other. Governance: The planning, influencing and conducting of the policy and affairs of an organization (in our case – the organization refers to a project).



Initiation: The process of preparing for, assembling resources and getting work started. May apply to any level, e.g. program, project, phase, activity, task. It is the process of committing an organization to begin a project. Issue: An issue is an immediate problem requiring resolution. Key goals: Performance Indicators that are determined at the beginning of the project for each team member, that reflect directly on the key objectives of the project, and that provide the basis for ratings during performance appraisals. Mitigation: Working to lessen risk by lowering its chances of occurring or by reducing its effect if it does occur. Opportunity Costs: The value of an opportunity that is lost or sacrificed when the choice of one course of action requires that another course of action must be given up. A non-accounting value that can be significant in certain circumstances, usually as a consequence of limited resources. It is measured by the profit that could have been generated had the resources been available. Product/Service Life Cycle: The complete history of a product through its concept, definition, production, operation, and obsolescence or disposal phases. Project Life Cycle: The events, from beginning to end, necessary to complete a project. Program Evaluation and Review Technique (PERT): A project management technique for determining how much time a project needs before it is completed. Each activity is assigned a best, worst, and most probable completion time estimate. These estimates are used to determine the average completion time. The average times are used to figure the critical path and the standard deviation of completion times for the entire project. Phase gate: The point at the end of a project phase where project performance is measured and a decision is made whether the project can move to the next phase or whether the project should be killed. Project: A unique venture with a beginning and an end, undertaken by people to meet established goals within defined constraints of time, resources, and quality.



Project management: The application of modern management techniques and systems to the execution of a project from start to finish, to achieve predetermined objectives of scope, quality, time and cost, to the equal satisfaction of those involved. Quality assurance: A planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements. Relevant stakeholders: A stakeholder is one who has a stake or interest in the outcome of the project or one who is affected by the project. A relevant stakeholder in the case of a Project Overview statement review could be the sponsor or the Operating Unit Head. In case of a weekly status report, the relevant stakeholder could be the Operating Unit Head. In case of Team Development, the relevant stakeholders could be the people responsible for training. Risk: Risk is the cumulative effect of the chances of uncertain occurrences, which will adversely affect project objectives. It is the degree of exposure to negative events and their probable consequences. Project risk is characterized by three risk factors namely: risk event, risk probability and the amount at stake. Risk is the opposite of opportunity. Risk Matrix: A matrix with risks located in rows, and with impact and likelihood in columns. Scope: The bounded set of verifiable end products, or outputs, which the project team undertakes to provide to the project sponsor. The required set of end results or products with specified physical or functional characteristics. Scope creep: On-going requirements increase without corresponding adjustment of approved cost and schedule allowances. As some projects progress, especially through the definition and development phases, requirements tend to change incrementally, causing the Project Manager to add to the project's mission or objectives without getting a corresponding increase in the time and budget allowances. Sponsor: Individual or body for whom the project is undertaken and who is the primary risk taker. Stakeholders: One who has a stake or interest in the outcome of the project. Also one who is affected by the project. Versions: A variant of some element (typically a document, or a product); later versions of this element typically expand on earlier versions.



Work Breakdown Structure: A task oriented detailed hierarchical breakdown, which defines the work packages and tasks at a very low level. Workgroup: This could be a project team. In the Project Classification matrix, it refers to the people from an area or department involved in a project. Work Package: This is a generic term for a unit within a work breakdown structure (WBS) at the lowest level of its branch, not necessarily at the lowest level of the whole WBS. [1] denotes that this input is relevant if the project belongs to class 1,2,3,4,or 5. [2] denotes that this input is relevant if the project belongs to class 2,3,4,or 5. [3] denotes that this input is relevant if the project belongs to class 3,4,or 5. [4] denotes that this input is relevant if the project belongs to class 4,or 5. [5] denotes that this input is relevant if the project belongs to class 5.



Project Classification - Activity Definition Purpose: The objective of this activity is to identify which class the project in question falls into. Once you arrive at the project class, you know which of the project management activities need to be carried out for the project. Each class corresponds to a set of project management activities recommended for that class. Participants: Inputs: Approximate Number of work hours, staff budget (including team members-internal and external to the organization) Process:

1. Determine what the approximate work effort is going to be for the project. 2. Using the Project Classification- Sizing Matrix, determine the project class that

corresponds to the work effort. 3. Determine what the staff budget is for the project. 4. Using the Project Classification- Sizing Matrix, determine the project class that

corresponds to the staff budget. 5. Use the higher of the two classes as the project class. 6. In order to arrive at the final class, one needs to now use the Project

Classification-Risk Matrix. 7. For each of the risk factors, determine whether this project falls into the low,

medium, high, or very high column. 8. For each risk factor, enter the risk score in the last column. 9. Arrive at the total for the risk score column. 10. If the risk score is between 0 and 10, do not change the classification. If the risk

score is between 11 and 13, increase the class by 1 level. If the risk score is between 14 and 15, increase the class by 2 levels.

11. For each project class, there is a set of recommended project management activities, which need to be performed for the project.

Outputs: Project Class



Project Classification Guidelines

1. Work Effort refers to the amount of labor that will be required for the project. There is a difference between duration and labor. Duration refers to the number of days in which a task or an activity was completed. Effort or labor refers to the number of hours or days it took to actually perform the task or activity. e.g. if a person works for 4 hours on Day 1 and for 4 hours on the Day 2, the effort is 8 hours or 1 day (a day is equivalent to 8 hours of effort) while the duration is 2 days.

2. The staff budget should include all costs that will be incurred for the project. This

includes the cost of employees internal to the University and external vendors/consultants. This excludes any software licensing fees, cost of any capital asset that will be purchased for the project, etc.

3. Team Size, a risk factor in the risk matrix, refers to the number of people (full-

time and part-time) who are part of the project team and are directly involved with the definition, planning, launch, development, management, and closure of the project.

4. Workgroups involved, the second risk factor in the risk matrix, refers to the

number of areas involved in the project. For the purpose of the Project Classification Risk Matrix, a workgroup could be defined as the team of people who are under the same Director.

5. Technology/Technique/Process, the third risk factor in the risk matrix, refers to

the technique being used in the project. Questions to ask are • Do we have experience using this technology that’s being proposed for

this project? • Is the technique a new technique or are we familiar with it?

6. Complexity, the fourth factor in the risk matrix, refers to the complexity of the

solution 7. Political profile/Impact refers to the people involved in the project and the people

affected by the success or failure of the project.

8. The activities recommended for a particular class of projects are the minimum activities that definitely have to be performed. The Project Manager may decide to perform other activities that may be recommended for a higher class of projects in addition to those recommended for the class of the current project.
