Project management Framework
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Project management Framework

on

  • 3,203 views

 

Statistics

Views

Total Views
3,203
Views on SlideShare
3,203
Embed Views
0

Actions

Likes
1
Downloads
189
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Project management Framework Document Transcript

  • 1. 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
  • 2. Ohio State University—Office of the CIOIntroductionThe project work environment within the Offices of the CIO and the Ohio StateUniversity customers we support is dynamic and fast-paced. Our projects must deal withdynamic business scenarios and sometimes unclear customer requirements. It is theProject Manager’s job to manage uncertainty and change in a manner that does notnegatively affect the outcome of their projects. The OSU CIO Project ManagementFramework was built to make the Project Manager’s job a little easier. This frameworkcontains definitions, guidelines and templates for the various project managementactivities undertaken to deliver successful projects.We live in very tight fiscal times, short-staffed organizations, burgeoning requests for ourservices, and often times unrealistic schedule deadlines. Given this environment, wesimply cannot afford to perform activities that do not add value to the final deliverablesof our projects. As such, our project management approach was designed to support ourability to complete quality work at the lowest cost, in the shortest period of time, with therequisite 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 acustomized project management methodology, in order to enable project leaders to focuson 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 projectrisks.The framework establishes common ground for all projects within the Offices of the CIOat the Ohio State University. With the glossary of Project management terms, it will alsoensure common terminology between different areas within the university.The long-term intent is to build a project management repository to document bestpractices, lessons learned, and examples of various documents that may be developedduring a project.Project Management Framework Draft V.1.00 Page 2 of 136
  • 3. Ohio State University—Office of the CIOA great number of people within the university have been planning, managing andexecuting projects for a long time. The framework exists to help build on our successesand learn from our failures. It is meant to grow our project management capabilities overtime. It is important to note that the framework is meant as a guide; it is not rigid and canbe tailored to suit your project’s requirements.In order to follow the framework, one must first understand the project classificationprocess.Project ClassificationAll 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 projectHow 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 RiskAlthough work effort and staff budget are good indicators for the amount of projectmanagement that should be expended, certain factors can also bring about the need forthe application of more robust project management practices. The Risk Matrix identifiesfive risk factors to be evaluated once the initial classification level is determined. In theevent that the total risk score is greater than 10, the classification level could beincreased.5 Phase Project Life CycleThe Project Life Cycle has been divided into 5 phases: • Define • Plan • Launch • Execute • CloseEach phase has activities associated with it. Each activity has an activity definition,guidelines and may have a template. These components facilitate the activities performedby the Project Manager.Project Management Framework Draft V.1.00 Page 3 of 136
  • 4. Ohio State University—Office of the CIOProject Classification—Framework Requirements MatrixThe number of activities recommended depends upon the class into which the project iscategorized. A class 1 project will involve only a few of these activities. A class 5 willinvolve all the activities in the framework. Also the activities recommended for eachclass are the bare minimum and it depends upon the discretion of the Project Manager toperform other activities (even if they are not recommended) if s/he feels that the activityis required for the project. The Framework Requirements matrix shows how theactivities are currently mapped to the project classes.Project Management Framework Draft V.1.00 Page 4 of 136
  • 5. Ohio State University—Office of the CIOTABLE OF CONTENTSIntroduction ...........................................................................................................2OSU CIO Project Management Framework..........................................................8Project Classification—Sizing Matrix.....................................................................9Project Classification—Risk Matrix .......................................................................9Project Classification—Framework Requirements Matrix ...................................10DEFINE Phase—Activity Overview.....................................................................11PLAN Phase—Activity Overview.........................................................................13LAUNCH Phase—Activity Overview ...................................................................17MANAGE Phase—Activity Overview ..................................................................18CLOSE Phase—Activity Overview......................................................................21Project Request Approval—Activity Definition ....................................................22Project Request Form Template .........................................................................24Project Request Approval—Guidelines...............................................................26Project Overview Statement—Activity Definition.................................................27Project Overview Statement Template................................................................28Project Overview Statement—Guidelines ...........................................................29Business Case—Activity Definition .....................................................................31Business Case Template ....................................................................................32Business Case—Guidelines ...............................................................................34Project Governance—Activity Definition .............................................................37Project Governance Document Template ...........................................................38Project Governance—Guidelines........................................................................39Phase Gate—Activity Definition ..........................................................................41Phase Gate Form Template................................................................................42Phase Gate—Guidelines ....................................................................................43Planning Kick-off Meeting—Activity Definition ....................................................44Planning Kick-off Meeting Agenda Template ......................................................45Planning Kick-off meeting—Guidelines...............................................................46Project Approach—Activity Definition..................................................................47Project Approach Document Template ...............................................................48Project Approach—Guidelines ............................................................................49Quality Strategy—Activity Definition....................................................................52Quality Strategy Template ..................................................................................53Quality Strategy—Guidelines ..............................................................................54Work Plan- Work Breakdown Structure—Activity Definition................................56Work Plan—Work Breakdown Structure—Guidelines.........................................58Work Plan—Estimating Time and Cost—Activity Definition ................................60Work Plan—Estimating Time and Cost—Guidelines ..........................................61Work Plan—Schedule Development—Activity Definition ....................................62Work Plan—Schedule Development—Guidelines ..............................................63Risk Management Strategy Plan—Activity Definition..........................................65Risk Management Strategy Plan Template.........................................................66Risk Management Strategy Planning—Guidelines .............................................67Communication Management Plan—Activity Definition ......................................68Communication Plan Template ...........................................................................69Communication Planning—Guidelines................................................................70Issue Management—Activity Definition...............................................................71Project Management Framework Draft V.1.00 Page 5 of 136
  • 6. Ohio State University—Office of the CIOIssue Management Plan Template .....................................................................72Issues Log Template...........................................................................................73Issue Management—Guidelines .........................................................................74Quality Assurance Plan—Activity Definition ........................................................75Quality Assurance Planning Template ................................................................76Quality Assurance Planning—Guidelines ...........................................................77Resource Plan—Activity Definition......................................................................78Resource Plan Template ....................................................................................79Resources Planning—Guidelines .......................................................................80Procurement Planning—Activity Definition..........................................................81Procurement Plan Template ...............................................................................82Procurement Planning—Guidelines ....................................................................83Operational Transfer Plan—Activity Definition ....................................................85Operational Transfer Plan Template ...................................................................86Operational Transfer—Guidelines.......................................................................87Integrated Project Plan—Activity Definition.........................................................88Integrated Project Planning—Guidelines ............................................................89Team Assignment—Activity Definition ................................................................90Team Assignment—Guidelines ..........................................................................91Launch Kick-off meeting—Activity Definition.......................................................92Launch Kick-off Meeting Agenda Template ........................................................93Launch Kick-off Meeting—Guidelines .................................................................94Initial Risk Identification—Activity Definition........................................................95Risk Management Matrix Template ....................................................................96Initial Risk Identification—Guidelines ..................................................................97Team Readiness—Activity Definition ..................................................................98Team Readiness—Guidelines ............................................................................99Performance Tracking & Reporting—Activity Definition ....................................100Project Status Report Template ........................................................................101Performance Tracking and Reporting—Guidelines...........................................103Schedule Control—Activity Definition................................................................104Schedule Control—Guidelines ..........................................................................105Change Control—Activity Definition ..................................................................106Change Request Form Template......................................................................107Change Control—Guidelines ............................................................................109Cost Control—Activity Definition .......................................................................110Cost Control—Guidelines .................................................................................111Quality Assurance & Control—Activity Definition ..............................................112Quality Assurance & Control—Guidelines ........................................................113Procurement Management—Activity Definition.................................................114Procurement Management—Guidelines ...........................................................115Risk Management—Activity Definition ..............................................................116Risk Management—Guidelines ........................................................................117Information Distribution—Activity Definition ......................................................118Information Distribution—Guidelines.................................................................119Time Tracking & Management—Activity Definition ...........................................120Time Tracking and Management—Guidelines..................................................121Transition to Production—Activity Definition .....................................................122Project Management Framework Draft V.1.00 Page 6 of 136
  • 7. Ohio State University—Office of the CIOTransition to Production—Guidelines................................................................124Wrap-up Meeting—Activity Definition................................................................125Wrap-up meeting—Guidelines ..........................................................................126Lessons Learned—Activity Definition................................................................127Lessons Learned—Guidelines ..........................................................................128Administrative Closure—Activity Definition .......................................................129Administrative Closure—Guidelines..................................................................130GLOSSARY ......................................................................................................131Project Management Framework Draft V.1.00 Page 7 of 136
  • 8. Ohio State University—Office of the CIO OSU CIO Project Management Framework DRAFT—July 27, 2004 (Version 0.89) Project Management Phases and Activities DEFINE PLAN LAUNCH MANAGE CLOSEProject Request Planning Kick-off Launch Kick-off Meeting Project Plan Execution Transition to ProductionApproval Meeting Performance TrackingAssign Project Manager Project Approach Initial Risk Identification Wrap-up Meeting & ReportingProject Overview Quality Strategy Initial Team Development Schedule Control Lessons LearnedStatement Work Plan—WorkBusiness Case Change Control Administrative Closure breakdown Structure Work Plan—EstimatingProject Governance Cost Control Celebrate! time and costPhase Gate—Gain Work Plan—Schedule Quality Assurance &approval to develop Development Controlproject planAssign Core project Procurement Risk Management Planteam Management Communications Risk Management Management Plan Information Issue Management Plan Distribution Time Tracking & Quality Assurance Plan Management Phase Gate—Gain Resource Plan approval to move to production Procurement Plan Operational Transfer Plan Integrated Project Plan Phase Gate—Gain approval for plan Team Assignment Project Management Framework Draft V.1.00 Page 8 of 136
  • 9. Ohio State University—Office of the CIO Project Classification—Sizing Matrix Project Work Effort Staff Budget (internal Class (Hours) & 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 Low Medium High Very High Risk Factor Score (0) (1) (2) (3)Team Size <5 5–9 10 – 14 >15(# of bodies)# Workgroups 1–2 3–4 5–6 >7InvolvedTechnology /Technique / Expert Familiar New to OSU Break-throughProcess The solution is The solution is There is more than The solution is well defined and known but some one approach to not known orComplexity no problems are problems are achieving the only vaguely expected expected project goal definedPolitical Profile / Org Unit Director Area VP/Dean Area Enterprise-wideImpact 0 – 10 No change to classification Scoring 11 – 13 Increase class 1 level TOTAL 14 – 15 Increase class 2 levelsProject Management Framework Draft V.1.00 Page 9 of 136
  • 10. Ohio State University—Office of the CIO 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 X Manage 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 XProject Management Framework Draft V.1.00 Page 10 of 136
  • 11. Ohio State University—Office of the CIODEFINE Phase—Activity Overview Activity Purpose Highlights Outputs The objective of this activity is to formalize and Anyone can make a Project Request. The Project Approved orProject Request institutionalize the initiation of projects. By doing this, we Request form needs to be signed by the Operating deniedApproval ensure that only those projects that warrant investment are Unit Head. The Project Approver needs to evaluate Project actually undertaken and executed. This will also help in the request on the basis of pre-set criteria. Request form managing the workload of individual departments.Assign ProjectManager The Project Overview Statement (POS) essentially is a The problem is identified. The project goal and Project short document that establishes the purpose of the project, objectives are determined. The success criteria are Overview and explains what business value it will provide to the identified. The required effort is estimated. Statement organization. The objective of this activity is to secure Assumptions, risks and obstacles are identified.Project Overview management approval and to provide the Project ManagerStatement with the authority to apply organizational resources to project activities. The POS becomes a source of reference for the project team. The objective of this activity is to help Initiators in The Business Need is established. Dependencies are Business justifying a business need. This activity is needed so as to identified. A Cost-Benefit analysis is done. Funding CaseBusiness Case ensure that the costs and benefits for all projects are requirements and risks are identified. weighed before investment is made. The objective of this activity is to define the roles and Escalation procedures are defined. Rules and ProjectProject Governance responsibilities of the various team members and responsibilities are defined. Governance stakeholders, and to define the decision-making structure document for the project. The objective of this activity is to ensure that management Senior management analyzes status reports and the Approved orPhase Gate—Gain approves the transition of a project across its various communication with the customer, and in rejectedapproval to develop phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes a Phase gateproject plan succeed are ‘killed’ early. decision if the project should move to the next form phase. Project Management Framework Draft V.1.00 Page 11 of 136
  • 12. Ohio State University—Office of the CIOAssign Core Projectteam Project Management Framework Draft V.1.00 Page 12 of 136
  • 13. Ohio State University—Office of the CIOPLAN Phase—Activity Overview Activity Purpose Highlights Outputs The objective of this activity is to review the approved The Project Manager calls for this meeting. S/he Minutes of Project Overview statement, set expectations, and sets the guidelines for project execution and the kick-offPlanning Kick-off articulate any risks that are likely to occur and dispel any articulates expectations from the project team. meetingMeeting doubts that the team may have. Project timelines, Project Approach, risks, assumptions, and constraints are discussed. The objective of this activity is to establish a high-level The Project life cycle and the various phases for the Project approach of how to implement the project goals by project are determined. Any reusable components Approach developing an implementation approach, and project from other projects are identified. The various DocumentProject Approach policies/standards. The purpose is also to define the methods in which the project objective can be solution for the project and the method of delivering that achieved are evaluated and the best method is solution. This activity will also validate which planning chosen. A rationale is provided for this decision. activities will be needed for the project. The objective of this activity is to decide on the Quality The Project Manager and team decide which List of QA Strategy that will be used for the project. Quality Assurance and which Quality control and QCQuality Strategy activities will be carried out for the project. activities The objective of this activity is to decompose the project The project work is decomposed into smaller WorkWork Plan—Work into activities, sub-tasks, and work packages. This allows components to give better management control. BreakdownBreakdown the Project Manager to estimate the duration of the structureStructure project, determine the required resources and schedule the work. The objective of this activity is to estimate the time and Time duration estimates are given for each task Time and costWork Plan— cost for each task. This will be an input to the depending upon resource availability and capability. estimatesEstimating time and development of the Work Plan.costWork Plan— The objective of this activity is to document the various Resources are assigned to tasks. Quality reviews and Work PlanSchedule tasks that need to be executed during the project duration, testing are planned for. Once the overall schedule isDevelopment to assign responsibility for each of the tasks, and to set, the Project Manager is responsible for closely Project Management Framework Draft V.1.00 Page 13 of 136
  • 14. Ohio State University—Office of the CIOPLAN Phase—Activity Overview Activity Purpose Highlights Outputs establish timelines for the tasks. It also establishes monitoring progress. 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. The objective of this activity is to define how risks will be The process of identifying risks is defined. Roles Risk identified, determine who owns the responsibility of and responsibilities for the risk management process Management identifying risks, decide at what frequency the risks need are defined. Frequency of updating the matrix is Strategy PlanRisk Management to be revisited, identify the risk monitoring tool, determine determined.Strategy Plan to whom risks will be escalated, define how to manage risks, and how to handle issues that are likely to become risks. The objective of this activity is make sure that team Target groups for different types of communication CommunicatiCommunications members, customers and stakeholders have the are defined. The frequency, format, and results of onManagement Plan information they need to do their jobs. the communication are defined. Management Plan The objective of this activity is to ensure that issues are An issue management process is defined. Roles and Issue identified, evaluated and assigned for resolution. This responsibilities are assigned. An issue log is ManagementIssue Management Plan, IssuesPlan process brings visibility to issues, accountability as to how documented and tracked. they are acted upon, and their timely resolution. log The objective of this activity is to validate that the major Acceptance criteria for deliverables, quality Quality Plan, deliverables are completed and that the processes are assurance activities, in-process control plans, and checklists being implemented with an acceptable level of quality. quality -related responsibilities are defined.Quality Assurance Frequency of project plan reviews, frequency ofPlan receiving and sending status reports, and frequency of checking for process improvements are determined. Project Management Framework Draft V.1.00 Page 14 of 136
  • 15. Ohio State University—Office of the CIOPLAN Phase—Activity Overview Activity Purpose Highlights Outputs The objective of this activity is to document how many The type and amount of resources needed are resources will be needed during the various phases of the determined. The estimated output, availability, and project and how they will be acquired, to examine if any cost of the resources are determined. Training needsResource Plan of the resources need training, and if so, to ensure that are identified and planned for. they receive the required training. The objective of this activity is to identify procurement Items that will be procured are identified. Inability Procurement strategies that will be used, outline the scope of products of currently used products to fulfill this need must PlanProcurement Plan and/or services to be procured, and identify be described. Evaluation criteria of vendors are set. responsibilities for the full procurement lifecycle. Officials who must approve the purchase are identified. The objective of this activity is to lay down the pre- Roles and responsibilities for the installation process OperationalOperational requisites of rolling out an application. This is to ensure are identified. Dependencies that exist are identified. Transfer PlanTransfer Plan the smooth transition from the ‘project’ to the ‘going live’ stage. The objective of this activity is to ensure that the various Assumptions used are reviewed. This activity Integrated elements of the project are properly coordinated. ensures the following: Roles and responsibilities are Project PlanIntegrated Project identified, a quality plan is written, reviews arePlan planned for, and most importantly that all the plans have considered all relevant factors. The objective of this activity is to ensure that individuals The Project Manager resolves conflict between Team with the required skills are assigned to a project, and to resource availability and Work Plan. Work AssignmentsTeam Assignment level resources in the Work Plan. packages are defined, assigned and any questions Fine tuned regarding work packages are discussed. Work PlanPhase Gate—Gain The objective of this activity is to ensure that management Senior management analyzes status reports and the Approval orapproval for plan approves the transition of a project across its various communication with the customer, and in rejection h hi ill h j h lik l j i ih h j k Project Management Framework Draft V.1.00 Page 15 of 136
  • 16. Ohio State University—Office of the CIOPLAN Phase—Activity Overview Activity Purpose Highlights Outputs phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes a succeed are ‘killed’ early. decision on whether the project should move to the next phase.Project Management Framework Draft V.1.00 Page 16 of 136
  • 17. Ohio State University—Office of the CIOLAUNCH Phase—Activity Overview Activity Purpose Highlights Outputs The objective of this activity is to ensure that all the The Project Manager should inform the team of the Minutes ofLaunch Kick-off project team members are aware of the ground rules of the ground rules for the project, the working style, the the meetingMeeting project. communication plan and the escalation process for conflict resolution. The objective of this activity is to ensure that the entire Risks are identified and categorized. For each risk Risk matrixInitial Risk team identifies risks for the project. This ensures that all identified, assess the risk event in terms ofIdentification perspectives are taken into account while planning for likelihood of occurrence and its effect on project risks. objectives if the risk event occurs. The objective of this activity is to ensure that individuals Training needs identified need to be met. Team Key goals for assigned to a project are provided the requisite training in members identify key goals at the start of the each teamTeam Readiness order to perform the job and that key goals and project. member responsibilities are identified for the team members at the start of the project. Project Management Framework Draft V.1.00 Page 17 of 136
  • 18. Ohio State University—Office of the CIOMANAGE Phase—Activity Overview Activity Purpose Highlights OutputsProject PlanExecution The objective of this process is to ensure that the team is Team meetings can be held so that information can WeeklyPerformance making satisfactory progress toward the project goals. The be exchanged. The Project Manager monitors—at StatusTracking & purpose is to: 1.Track cost, time, scope and quality, 2. least weekly—progress to plan on key elements. Reports,Reporting Track actual accomplishments and results, and 3. Provide The status of the project is reported to the relevant Tracked visibility into progress. stakeholders. Project Schedule The objective of this activity is to ensure that tasks are The Project Manager is responsible for tracking the Tracked executed as per Work Plan so that the deadline for the various tasks in a project. Tracking is done by Work Plan project can be met. If the schedule cannot be met, the exchanging task status information with team relevant stakeholders need to be informed. members and then incorporating the latest statusSchedule Control 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. The objective of this activity is to ensure that all changes Any change to scope has to be communicated to the Approved or to scope are documented and authorized by the relevant Project Manager. The Project Manager ensures that deniedChange Control stakeholders. the Change Request Form has been filled out. The Change Project Manager analyzes the change request. The Request Form Project Manager and established governance may approve or deny a change request. The objective of this activity is to manage project cost Costs are agreed upon with the sponsor at the start Status reportsCost Control such that it is aligned with budgeted cost. and upon completion of the project. The budget has to be constantly monitored by the Project Manager. Project Management Framework Draft V.1.00 Page 18 of 136
  • 19. Ohio State University—Office of the CIOMANAGE Phase—Activity Overview 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. The objective of this activity is to ensure that the project This process comprises project reviews, product ReviewQuality Assurance team meets the project requirements and that all requisite reviews, code reviews, testing, and any other reports, Bug& Control quality criteria are met. process that the Project Manager might think reports necessary. Defects are identified, and categorized. Root causes are analyzed. The objective of this activity is to ensure that appropriate Any guidelines set by the University in this regard Signed resources are employed, that the process of selection is supersedes this process. A vendor is chosen on pre- Contract(s) /Procurement fair and that the quality of work is acceptable. set criteria. The contract needs to be signed by PurchaseManagement authorized signatories. Order(s) /Statement(s) of Work The objective of this activity is to identify risks, to reduce Management monitors risks with a risk exposure Revised Risk the probability of the identified risks, to identify over the threshold limit. Risk mitigation strategies MatrixRisk Management mitigation strategies, to identify contingency plans for the are planned and contingency plans are developed. bigger risks, and if realized, to reduce the impact of these The Risk Matrix is revisited at and appropriate risks. frequency. The objective of this activity is to ensure that all All relevant information needs to be communicated StatusInformation appropriate parties are kept informed. to the appropriate parties at the right time and in the reports,Distribution appropriate format. Minutes of meetingsTime Tracking & The objective of this activity is to ensure that all time Time spent is tracked at a project level, and Time Sheets,Management spent on a project is logged in. analyzed at an organizational level. Variance Reports, Project Management Framework Draft V.1.00 Page 19 of 136
  • 20. Ohio State University—Office of the CIOMANAGE Phase—Activity Overview Activity Purpose Highlights Outputs Estimates for future projects The objective of this activity is to ensure that management Senior management analyzes status reports and the Approved or approves the transition of a project across its various communication with the customer, and in rejectedPhase Gate—Gain phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes aapproval to move to Phase gate succeed are ‘killed’ early. decision on whether the project should move to the formproduction next phase. Project Management Framework Draft V.1.00 Page 20 of 136
  • 21. Ohio State University—Office of the CIOCLOSE Phase—Activity Overview Activity Purpose Highlights Outputs The objective of this activity is to ensure that the Its ensured that all planned testing is carried out, all SummaryTransition to Operational Transfer Plan is carried out after the required customer requirements are met and that the product Report,Production checks are done. is fully operational. The Project Manager ensures Customer that the customer accepts the product before Sign-off Transition to Production. The objective of this activity is to ensure that the Project The Project Manager calls this meeting. The Project Minutes team discusses the project after the project has been Manager, and the team members discuss the projectWrap-up Meeting executed so that Lessons Learned are captured and issues experience including problems faced during project are analyzed. execution. Solutions to such problems are suggested and discussed. Lessons Learned are discussed. The objective of this activity is to ensure that the Lessons The Project Manager develops this ‘Lessons LessonsLessons Learned Learned during the project are documented and Learned’ document with the help of the project Learned incorporated in the knowledge base for future use. team. This document is deposited in the knowledge Document base. The objective of this activity is to ensure that the Project is The Project Manager ensures that the project isAdministrative approved, accepted and closed. approved and accepted by the relevant stakeholders.Closure All documentation and records are reviewed, organized and archived. Backups are taken. Resources are released and the project is closed.Celebrate! Project Management Framework Draft V.1.00 Page 21 of 136
  • 22. Ohio State University—Office of the CIOProject Request Approval—Activity DefinitionPurpose:The objective of this activity is to formalize the process by which new projects/servicerequests are initiated. By doing this, we can ensure that only those projects that warrantinvestment are actually undertaken and executed. This will also help in managing theworkload of individual departments.This process applies to all projects undertaken by the Office of the CIO of the Ohio StateUniversity.Participants:Initiator: Any customer or member of the Office of the CIO who submits a requestOperating Unit Manager: Resource OwnerApprover: The appropriate decision makerSponsor: The body or person who funds the projectInputs: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 unit2. 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/project5. 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.Project Management Framework Draft V.1.00 Page 22 of 136
  • 23. Ohio State University—Office of the CIOOutputs:Approved or denied Project Request formTopProject Management Framework Draft V.1.00 Page 23 of 136
  • 24. Ohio State University—Office of the CIOProject Request Form TemplateRequest Identifier (To be completed by OIT):InitiatorOperating Unit ManagerCustomer/Sponsor NameDepartmentDateEmail IDPhoneDescription of businessneed/problem/opportunityType of Request Internal mandate (University Policy, System Upgrade) External mandate (Legal requirement, Government) Correct an error (Malfunction/Fix) Value-add/Process improvement/Business opportunityGoalBusiness ImpactEstimated labor hours (optional)Date needed (Explain in Impact)(optional)Project Initiator:Date SignTo be completed by the Project ApproversProject request Approved / Denied Sign:Comments, if any: Date:Governance Sign: Date:Sponsor Sign: Date:Customer Sign: Date:Others Sign: Date:Project Management Framework Draft V.1.00 Page 24 of 136
  • 25. Ohio State University—Office of the CIOProject Management Framework Draft V.1.00 Page 25 of 136
  • 26. Ohio State University—Office of the CIOProject 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 Management Framework Draft V.1.00 Page 26 of 136
  • 27. Ohio State University—Office of the CIOProject Overview Statement—Activity DefinitionPurpose: The Project Overview Statement (POS) is a short document that establishes thepurpose of the project, and explains what business value it hopes to provide to theorganization. The objective of this activity is to secure management approval and toprovide the Project Manager with the authority to apply organizational resources toproject activities. The POS becomes a source of reference for the project team.Participants: The Project Manager prepares this document. The intended audience ismanagement, 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 StatementProject Management Framework Draft V.1.00 Page 27 of 136
  • 28. Ohio State University—Office of the CIOProject Overview Statement Template Project Overview StatementProject NameDateVersionProject Sponsor/CustomerProject Manager/LeadProblem/OpportunityGoalObjectivesSuccess CriteriaEffortTotal CostClass of ProjectAssumptions, Risks,ObstaclesSupporting DocumentsPrepared By:Date:Approved By:Date:Project Management Framework Draft V.1.00 Page 28 of 136
  • 29. Ohio State University—Office of the CIOProject 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,Project Management Framework Draft V.1.00 Page 29 of 136
  • 30. Ohio State University—Office of the CIO 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 project13. Approval: Use this section for approval signatures from project stakeholders.Project Management Framework Draft V.1.00 Page 30 of 136
  • 31. Ohio State University—Office of the CIOBusiness Case—Activity DefinitionPurpose:The objective of this activity is to help Initiators in justifying a business need to seniormanagement. This activity is needed to ensure that the costs and benefits for all projectsare weighed before a commitment of resources is made. This also ensures that theprojects invested in bring the greatest value to the organization.Participants:Initiator: Person from whom the project idea originatedSponsor: Person or body who will be funding the projectApprover: Established governanceInputs: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 analysisNotes:Clearly mention what is and is not included under costs.TopProject Management Framework Draft V.1.00 Page 31 of 136
  • 32. Ohio State University—Office of the CIOBusiness Case Template BUSINESS CASE1. Project Summarya. Project Initiatorb. Project Sponsorc. Project Descriptiond. Needs and scopee. Target customerf. Objectives, outcomes, andbenefitsg. Features to be included and theneed they satisfyh. Costsi. Risksj. Complexity assessmentk. Durationl. Leadership requirementsm. Team skill requirements2. Statement of Needa. Unmet Need or Opportunityb. Anticipated Benefitsc. Rationale for assigning priorityd. Specific Business needs(current and future)e. How was the need determinedf. Supporting datag. Names of stakeholdersconsultedh. Names of stakeholderssupporting this proposali. Consequences of notproceeding3. Consideration and selection of Preferred Optiona. Options consideredb. Strengths and weaknesses ofeach optionc. Reason preferred option waschosend. Investment alternativese. Assumptions madef. Alignment with Universitypolicies and strategiesProject Management Framework Draft V.1.00 Page 32 of 136
  • 33. Ohio State University—Office of the CIOg. Any Business Process changes?If so, outline them4. Financial Analysis – Outputs, Benefits, costs, and Risksa. 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 HRpolicies/requirementsb. Benefits i. Savings ii. Potential Revenue iii. Expected OutcomesSummaryc. Funding i. Net Impact (Cost –Benefitanalysis) ii. Funding Requirements iii. Other sources of fundingd. Unquantifiable impacte. ROIf. Risks5. Competitive Analysis6. Implementation Strategy7. Factors critical to projectsuccess8. Criteria for measuringsuccessProject Management Framework Draft V.1.00 Page 33 of 136
  • 34. Ohio State University—Office of the CIOBusiness Case—GuidelinesA 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 enablesound judgments to be made about the merit of what is being proposed, and whetherfunding 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, opportunitydescription 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.Project Management Framework Draft V.1.00 Page 34 of 136
  • 35. Ohio State University—Office of the CIO3. Consideration and Selection of Preferred OptionGenerate 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 Risksa. CostsIdentify the capital and operating cost of the preferred option for Year 1, Year 2 andbeyond.The proposed budget must include:-Capital and recurrent expenditure, including salaries, equipment, and consumables for • Software • Hardware • Maintenance • Training • Ongoing support • Operating cashIdentify total cost of ownershipIdentify impact upon other projects and initiativesIdentify impact upon Human Resources requirements and policies. Do we need to trainpeople or recruit people for this project?b. BenefitsIdentify any savings and how those savings will be usedIdentify any potential revenueDescribe the expected outcomes in terms that are as specific as possible, and relate to theneeds identified. e.g. • Compliance with statutory or other obligations • Improved decision making as a result of better information • Reduced costSummarize benefits and costs, and explain why the benefits outweigh the costs involved.c. FundingCalculate net impact of project by combining cost and benefits.Identify funding requirements. If funds have not been allocated or approved, state themeans by which funds will be acquired.Identify other sources of funding being considered or investigated.d. Unquantifiable Cost and Benefit AnalysisIdentify unquantifiable impact to• The University• The economy• Society• Distribution of benefitse. ROIProject Management Framework Draft V.1.00 Page 35 of 136
  • 36. Ohio State University—Office of the CIOROI benefits may either be earned once upon the implementation of the proposedsolution 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 andclassify them as such.4.6 RisksIdentify the expected risks to which the project will be exposed. Assess the likelihood ofeach 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 damagelimitation.5. Competitive AnalysisDescribe how the proposed solution is competitive in the marketplace. Assess it againstthe top three competitors’ offerings, including price and quality.6. Implementation StrategyDescribe 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 successList those factors that must be in place to ensure success of the proposed solution. Bespecific.e.g. Commitment and awareness from Executive SponsorsAccess to necessary source dataCooperation by affected business or IT areasFull-time staff assignments to projectArchitecture fit (Status of interfacing systems)8. Criteria for measuring successDescribe what measures will be applied to measure the success of the proposed solution.e.g. • Financial (Cost vs. Revenue) • Performance • User acceptance • Schedule • Competitive differentiationProject Management Framework Draft V.1.00 Page 36 of 136
  • 37. Ohio State University—Office of the CIOProject Governance—Activity DefinitionPurpose:The objective of this activity is to define the roles and responsibilities of the various teammembers and stakeholders, and to define the decision-making structure for the project.Participants:Project Manager and stakeholdersInputs: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 DocumentTopProject Management Framework Draft V.1.00 Page 37 of 136
  • 38. Ohio State University—Office of the CIOProject Governance Document Template1. Role Definitions and Responsibilities:Roles Responsibilitiese.g. Project ManagerMentorReviewerQuality ManagerTesting TeamProject team2. Rules of Engagemente.g. a. Communicationb. Status Reportsc. Procurement of human resourcesd. Resource acquisition3. Organizational structure for the project4. Escalation Procedure5. Decision-making Structurea. Technical decisionsb. Changes in scopec. Conflict resolution6. Team Operating Rules7. Team Meeting Structuree.g. Who facilitates themeeting?Who records theminutes of the meeting?Project Management Framework Draft V.1.00 Page 38 of 136
  • 39. Ohio State University—Office of the CIOProject Governance—Guidelines1. 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 requirements3. 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 Manager4. 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. Operating Unit Head Functional Heads Project Senior Project Reviewer Manager Project Manager Project team5. 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.Project Management Framework Draft V.1.00 Page 39 of 136
  • 40. Ohio State University—Office of the CIO6. 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?Project Management Framework Draft V.1.00 Page 40 of 136
  • 41. Ohio State University—Office of the CIOPhase Gate—Activity DefinitionPurpose: The objective of this activity is to ensure that management approves thetransition of a project across its various phases. This will ensure that projects that are notlikely to succeed are ‘killed’ early.Participants: The Project Manager, relevant stakeholdersInputs: Project Status Report [1], important customer communication [1], Phase gateform 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 formProject Management Framework Draft V.1.00 Page 41 of 136
  • 42. Ohio State University—Office of the CIOPhase 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:Project Management Framework Draft V.1.00 Page 42 of 136
  • 43. Ohio State University—Office of the CIOPhase 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.Project Management Framework Draft V.1.00 Page 43 of 136
  • 44. Ohio State University—Office of the CIOPlanning Kick-off Meeting—Activity DefinitionPurpose:The objective of this activity is to review the approved Project Overview Statement, toset expectations, to articulate any risks that are likely to occur, and to dispel any doubtsthat the team may have.Participants:The Project Manager calls for the meeting.The audience includes the relevant stakeholders (i.e. customer representative and affectedbusiness 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 meetingTopProject Management Framework Draft V.1.00 Page 44 of 136
  • 45. Ohio State University—Office of the CIOPlanning Kick-off Meeting Agenda TemplateProject 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 ItemsProject Management Framework Draft V.1.00 Page 45 of 136
  • 46. Ohio State University—Office of the CIOPlanning 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 stakeholdersProject Management Framework Draft V.1.00 Page 46 of 136
  • 47. Ohio State University—Office of the CIOProject Approach—Activity DefinitionPurpose:The objective of this activity is to establish a high-level approach of how to achieve theproject goals specified in the Project Overview Statement, by developing animplementation approach and project policies/standards. The purpose of this Approachdocument is to define the type of solution for the project and the method of deliveringthat solution. This document will re-state the project goal and articulate how this will beachieved. It will also validate which planning elements will be needed for the project.Participants:Project Manager, Project team, relevant stakeholders, and customerInputs: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 DocumentTopProject Management Framework Draft V.1.00 Page 47 of 136
  • 48. Ohio State University—Office of the CIOProject Approach Document Template1. Product/Service Life CycleINSERT LIFE CYCLE HERE2. Similar projects3. Reusable components:4. Project guidelines5. Method6. Justification of methoda. Cost vs. benefitsb. Risks7. Planning elements required8. Dependencies9. Conflict Resolution ProcessProject Management Framework Draft V.1.00 Page 48 of 136
  • 49. Ohio State University—Office of the CIOProject Approach—GuidelinesVirtually every project needs to have a defined approach, however the degree offormality depends on the size and complexity of the project. Without some description ofa Project Approach, it is difficult to plan the activities and results of the project. Adefined life cycle helps to ensure relevance of work being done and continuity of theresults 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 bestway 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/ReviewRequirements Outputs: Customer Specifications, Acceptance SpecificationsAnalysis Project Overview Statement Test Plan Document to be Inputs: Customer requirements reviewed by the Rules: The technical lead needs to Stakeholders and the accompany the Project Manager Development Team for the specifications discussion with the customer. Dependencies: Storyboard needs to be sent by the customer.Planning Outputs: Integrated Project Plan Test cases Plan review by Inputs: Specifications document, relevant stakeholders 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 AProduction Outputs: Components of product System Test Peer code review by Inputs: Plans, specifications. Plan team members Rules: If there is schedule Content review by slippage, the resource needs to Project Manager inform the Project Manager as soon as s/he becomes aware of theProject Management Framework Draft V.1.00 Page 49 of 136
  • 50. Ohio State University—Office of the CIO delay. Dependencies: Component A and B should be complete before work on Component C starts.Testing Outputs: Defect reports Defect Reports Test cases to be Inputs: Product, Test cases, Test reviewed by the Plans Project Manager. Rules: All defects to be rectified within 2 days of capturing the defect. Dependencies: All defects to be corrected before second round of testing.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 Planning8. Dependencies: Any dependencies outside of the Project Managers 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.Project Management Framework Draft V.1.00 Page 50 of 136
  • 51. Ohio State University—Office of the CIO9. 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.Project Management Framework Draft V.1.00 Page 51 of 136
  • 52. Ohio State University—Office of the CIOQuality Strategy—Activity DefinitionPurpose:The objective of this activity is to decide on the Quality Strategy that will be used for theproject.Participants:Project Manager, Project team, and relevant stakeholdersInputs: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 StrategyTopProject Management Framework Draft V.1.00 Page 52 of 136
  • 53. Ohio State University—Office of the CIOQuality Strategy TemplateProject NameDateCreated By1. Quality Assurancee.g. Quality Assurance Responsibility activities Checklist for coding Project Technical Lead Project Checklist Project Manager Training on Dreamweaver Person A to Content developers Customer Review of Project Manager and Customer graphics2. Quality Controle.g. Quality Responsibility Frequency/ Variance to acceptance Control Milestone criteria activity Unit testing Developer After development If not working according to of unit plan, correct the error. System Technical Lead After planning and If the system-testing plan is testing launch of project, different from the acceptance but before criteria (e.g. if the customer development needs to use the learning begins. program on a PC and the system testing will be done on a Mac), the plan needs to be revisited. Peer code Team members At the time of If not working according to review delivery of code to plan, correct the error. the next task. Test cases Project Before If test cases are different from Manager development begins what the customer requires, change the test cases and check to see if other plans are according to what the customer requires. User Project After development If not working according to acceptance Manager, panel of product test cases, correct error. testing of users3. Acceptance criteria e.g. all transactions to be executed without encountering an error.Project Management Framework Draft V.1.00 Page 53 of 136
  • 54. Ohio State University—Office of the CIOQuality Strategy—Guidelines1. 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. Determinewhose responsibility it will be to execute the activity, e.g. user acceptance testing will bedone 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 externalreviews.Decide if user acceptance testing is required or if system and integration testing willsuffice. 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 correctnesscriteria. Agree upon completeness and correctness criteria with the customer. Thecustomer should sign off the project if the product is of acceptable quality. Whatconstitutes 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 ableto execute all the transactions without encountering an error.4.Establish clarity of purpose. A face-to-face meeting may be held with the customer toensure that you have understood their requirements correctly.5.Build customer checkpoints so that the customer is involved at critical junctures in theproject. This ensures that what mistakes were discovered and learned are adjustedquickly.Project Management Framework Draft V.1.00 Page 54 of 136
  • 55. Ohio State University—Office of the CIOIntroduction to the WBSThe 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 thatmust be done to meet the needs of the customer. While the three activities, viz. WBSdevelopment, time and cost estimation, and schedule development are listed in a certainorder in the framework, a Project Manager who has gained some experience in theprocess may actually perform the three activities in a different order.No particular software or tool is recommended for a project work plan. The ProjectManager could use MS Project, MS Excel, or even a whiteboard (reserved for the projectthrough the project life cycle).Project Management Framework Draft V.1.00 Page 55 of 136
  • 56. Ohio State University—Office of the CIOWork Plan- Work Breakdown Structure—Activity DefinitionPurpose: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 theProject Manager to estimate the duration of the project, determine the required resourcesand schedule the work. The Work Breakdown Structure (WBS) is a hierarchicaldescription 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 thecore 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.Project Management Framework Draft V.1.00 Page 56 of 136
  • 57. Ohio State University—Office of the CIO6. 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 StructureProject Management Framework Draft V.1.00 Page 57 of 136
  • 58. Ohio State University—Office of the CIOWork 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.Project Management Framework Draft V.1.00 Page 58 of 136
  • 59. Ohio State University—Office of the CIO 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.Project Management Framework Draft V.1.00 Page 59 of 136
  • 60. Ohio State University—Office of the CIOWork Plan—Estimating Time and Cost—Activity DefinitionPurpose:The objective of this activity is to estimate the time and cost for the lowest level of yourWBS. 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 thetask 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 estimatesProject Management Framework Draft V.1.00 Page 60 of 136
  • 61. Ohio State University—Office of the CIOWork Plan—Estimating Time and Cost—Guidelines1. There are many approaches to estimate time and cost for the lowest level tasks of aWBS. a. Historical Information b. Similarity to other tasks c. Expert advice d. Delphi method e. Three-point method f. Wide-band Delphi method2. Historical information is often available from one or more of the following sources: a. Project Files/Historical data b. Project team knowledge3.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 isactually assigned to the task.6. Task duration could also depend on resource availability. Planned vacations should beconsidered while estimating time.7. For estimating cost, use the blended rate agreed upon in your department. Cost may notbe tracked for all classes of projects.Project Management Framework Draft V.1.00 Page 61 of 136
  • 62. Ohio State University—Office of the CIOWork Plan—Schedule Development—Activity DefinitionPurpose:The objective of this activity is to identify dependencies between tasks, assign resourcesfor each task, look at overall dates, and identify start and end dates for the tasks. TheProject Manager can use the schedule to plan, and implement project tasks and monitorthe progress of the project.Participants:The Project Manager develops the Work Plan/schedule with assistance from the coreproject team, customer representation, and experts within and outside the organization.Inputs:Project Overview Statement [1], Work Breakdown structure [1], Time and costestimates[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 PlanTopProject Management Framework Draft V.1.00 Page 62 of 136
  • 63. Ohio State University—Office of the CIOWork Plan—Schedule Development—Guidelines1.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 planningactivities. e.g. as a rule of thumb the following table could be used for experiencedProject Managers with subject matter expertise.Class Minimal Time spent on Planning activitiesClass 1 4 hoursClass 2 8-10 hoursClass 3 40 hoursClass 4 60 hoursClass 5 80-100 hoursProject management effort (including defining, planning, launching, managing, andclosing 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 taskwill cause a delay in the end date of the project.12. After developing the Work Plan, check if any resources have been over-allocated. Ifthey are, figure out ways to level resources so that they are allocated with the rightamount of work. If a task is not meeting planned limits, you can add more resources toProject Management Framework Draft V.1.00 Page 63 of 136
  • 64. Ohio State University—Office of the CIOthe task so that the task can be performed faster. This is called crashing the task.Project Management Framework Draft V.1.00 Page 64 of 136
  • 65. Ohio State University—Office of the CIORisk Management Strategy Plan—Activity DefinitionPurpose:The objective of this activity is to define how risks will be identified, determine whoowns the responsibility of identifying risks, decide at what frequency the risks need to berevisited, 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 PlanTopProject Management Framework Draft V.1.00 Page 65 of 136
  • 66. Ohio State University—Office of the CIORisk Management Strategy Plan TemplateProject NameDate:Created By:1. Risk Identification Process:2. Risk Monitoring Tool to beused3.Ownership of riskidentification:a. Primary responsibilityb. Contributors to risk identification3. Roles and responsibilitiesResponsible for identificationof riskResponsible for review andmitigation of risksResponsible for updating therisk matrix4. Frequency of revisiting thematrix5. Stakeholders who will be Weekly/bi-weekly and on the occurrence of a risk-informed of risks with high triggering event.probability and severe impact6. Likely strategies to handlerisks7. Issues that are likely tobecome risks.Project Management Framework Draft V.1.00 Page 66 of 136
  • 67. Ohio State University—Office of the CIORisk Management Strategy Planning—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 67 of 136
  • 68. Ohio State University—Office of the CIOCommunication Management Plan—Activity DefinitionPurpose:The objective of this activity is to make sure that team members, customers andstakeholders have the information they need to do their jobs. Proactive communication isimportant on all projects. Communication is also a vital way to manage stakeholdersexpectations 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 efficientlyand effectively to the various constituents. Communication needs to be in the rightformat, to the right target audience with sufficient amount of information and at the righttime.Participants:Communicator: The person who is the source of the informationAudience: The people who receive the informationIn general, the Project Manager, project team members, stakeholders, and the customerare participants and could play the role of the communicator or the audience at any pointin time.Inputs:Project Overview Statement [1], Work Plan[1], Project Approach [2], Governancedocument [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 communication3. 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 PlanTopProject Management Framework Draft V.1.00 Page 68 of 136
  • 69. Ohio State University—Office of the CIOCommunication Plan TemplateProject Name:Date:Created By:Audience Communicator Communication Frequency Medium of Purpose Type CommunicationProject Management Framework Draft V.1.00 Page 69 of 136
  • 70. Ohio State University—Office of the CIOCommunication Planning—GuidelinesThese guidelines help in determining stakeholder communication requirements andensuring that these requirements are met appropriately. Communication could becategorized in the following ways: 1. Internal/external 2. Driven top-down or bottom-up or at the same level1. Determine the stakeholder i.e. the target groups (internal and external) and thecomposition for each group. They could be the sponsor, the operating unit Head, theproject team, the Project Manager, the Project Management Office, the functionalmanager, other departments within OSU like the Help Desk, the customer, or externalvendors. The stakeholders should include anyone who needs or will need thatinformation.2. Determine what information needs to be communicated to the audience. Someexamples 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 forms3. 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, formalpresentations, or status reports.6. Determine who will be sending out this communication.The communicator could be the Project Manager, the project team, the customer, thesponsor, or the functional manager.7. Identify the purpose of the communication. The information could be mandatory, or toprovide 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.Project Management Framework Draft V.1.00 Page 70 of 136
  • 71. Ohio State University—Office of the CIOIssue Management—Activity DefinitionPurpose: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 howthey are acted upon, and their timely resolution.Participants:Project Manager, project team, relevant stakeholdersInputs: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 closedOutputs:Issue Management Plan, Issues logTopProject Management Framework Draft V.1.00 Page 71 of 136
  • 72. Ohio State University—Office of the CIOIssue Management Plan TemplateActivity Comments Responsibility to Frequency of resolve Tracking1.Raising an issue Anyone can raise an Project Manager Weekly issue2. Logging and Project Manager Weeklytrackinge.g.Inter-team conflict The team members Project Managerissues should try to resolve it between themselves first. If a resolution is not possible, then raise the issue to the Project ManagerScope/functionality This may impact Project Managerissues cost or schedule, hence raise to Project Manager immediately.3. Assigning an Project Technicalissue for evaluation Leadand resolutionAbove 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.Project Management Framework Draft V.1.00 Page 72 of 136
  • 73. Ohio State University—Office of the CIOIssues Log TemplateAn example is provided below:Issue Action Effort Responsibility Date Status Comments Closed Plan (Issue owner) (Open/Action by issue (to be being owner filled by implemented/ the Resolved) Project Manager)Issue Action 8 Project Jan Open Still open as1 1 hours Technical 24th, we are Lead 2004 awaiting customer information Action1 8 Project Jan Action being hours Technical 28th, implemented Lead 2004 Action 6 Project Feb Resolved Action Closed. 1 hours Technical 1st, completed. Lead 2004 Issue resolvedIssue Action 40 Graphic Jan Open Can be Change th1 2 hours designer and 26 , implemented Request content 2004 only after filed for developer new approval software arrivesIssue Action 12 Technical lead Jan Open To be th2 1 hours 30 , implemented 2004 after completion of task 147 in scheduleProject Management Framework Draft V.1.00 Page 73 of 136
  • 74. Ohio State University—Office of the CIOIssue Management—Guidelines1. 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 makedecisions when appropriate.6. If there is an impact to effort, scope, cost or schedule, the Project Manager should beinvolved. If there is an impact to effort, scope, cost or schedule, a Change Request mightneed 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 ProjectManager may resolve an issue concerning a small project but a governance committeemight need to step in for larger projects.Project Management Framework Draft V.1.00 Page 74 of 136
  • 75. Ohio State University—Office of the CIOQuality Assurance Plan—Activity DefinitionPurpose:The objective of this activity is to validate that the major deliverables are completed andthat the processes are being implemented with an acceptable level of quality.Participants:The Project Manager prepares this document in consultation with the customerrepresentative. This document should be reviewed and approved by the relevantgovernance structure.Inputs:Project Overview Statement [1]Process:Product-related QA1. 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 QA1. 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, ChecklistsTopProject Management Framework Draft V.1.00 Page 75 of 136
  • 76. Ohio State University—Office of the CIOQuality Assurance Planning TemplateProject NameDateCreated By:1. Acceptance criteriaQuality standards oforganization, customer orexternal organizationChecklists to be referred to2. Potential problems the projectcould face3. External QA recommended? Yes/NoProject-related QA3. Frequency of project planreviews4. Frequency of responding tocommunications5. Frequency at which you wouldwant to interview stakeholders6. Frequency at which to checkfor process improvementsProject Management Framework Draft V.1.00 Page 76 of 136
  • 77. Ohio State University—Office of the CIOQuality Assurance Planning—GuidelinesProduct-related QA1. 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 projects test plan.Project-related QA7. 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.Project Management Framework Draft V.1.00 Page 77 of 136
  • 78. Ohio State University—Office of the CIOResource Plan—Activity DefinitionPurpose:The objective of this activity is to document how many resources and what skills arerequired during the various phases of the project, how the resources will be acquired, toexamine if any of the human resources need training and if so to ensure that they receivethe required training.Participants:The Project Manager prepares the resource plan in conjunction with the core Projectteam.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 PlanTopProject Management Framework Draft V.1.00 Page 78 of 136
  • 79. Ohio State University—Office of the CIOResource Plan TemplateProject 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 Plane.g.Month Resource role Skill Skill Level NumberJan. 2005 Technical SQL Advanced 2 Graphics Photoshop Intermediate 1 Graphics Photoshop Advanced 1 Graphics Flash Advanced 2Feb 20053. Estimated quality and output:e.g. Batch processing for Machine A4. Availability of the required resources:XYZ on vacation from Jan 17th 2005 to Jan 25th 20055. Cost of resources:e.g.Resource Cost per unit No. of units Total costConsultant 200 USD per hour 40 hours 8000 USDMachine B rented 250 USD per day 8 days 2000 USD6. Sharing of resources:A 75% time on project7. Contingencies: 1 extra day for Resource B’s work8. Training Needs: e.g.Resource Training/Skill Current skill level Desired skill levelXYZ .Net Beginner IntermediateProject Management Framework Draft V.1.00 Page 79 of 136
  • 80. Ohio State University—Office of the CIOResources 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.Project Management Framework Draft V.1.00 Page 80 of 136
  • 81. Ohio State University—Office of the CIOProcurement Planning—Activity DefinitionThe University procurement process supersedes this document.Purpose:The objective of this activity is to identify how project needs can best be met byprocuring products and/or services outside the organization. It identifies the procurementstrategies 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 PlanProject Management Framework Draft V.1.00 Page 81 of 136
  • 82. Ohio State University—Office of the CIOProcurement Plan TemplateProject 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?Project Management Framework Draft V.1.00 Page 82 of 136
  • 83. Ohio State University—Office of the CIOProcurement Planning—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 83 of 136
  • 84. Ohio State University—Office of the CIO12. 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.Project Management Framework Draft V.1.00 Page 84 of 136
  • 85. Ohio State University—Office of the CIOOperational Transfer Plan—Activity DefinitionPurpose:The objective of this activity is to lay down the pre-requisites of rolling out anapplication. This is to ensure the smooth transition from the ‘project’ to the ‘going live’stage.Participants:The Project Manager, the Project team, and the customerInputs: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, ChecklistsTopProject Management Framework Draft V.1.00 Page 85 of 136
  • 86. Ohio State University—Office of the CIOOperational Transfer Plan TemplateProject Name:Date:Created By:1. Roles and responsibilities for installationName Roles ResponsibilitiesXYZ Installation team leader2. Activities that must be achieved before installation can start3.Activities that must be achieved for installation to be deemed complete4. Schedule for installation activitiesTask Duration Start date End date Predecessor Resource5. Backups to be taken prior to installation6. 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 to13. 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 installedin?Project Management Framework Draft V.1.00 Page 86 of 136
  • 87. Ohio State University—Office of the CIOOperational Transfer—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 87 of 136
  • 88. Ohio State University—Office of the CIOIntegrated Project Plan—Activity DefinitionPurpose:The objective of this activity is to ensure that the various elements of the project areproperly coordinated. The Project Planning Process provides a framework to developproject plans. Using the activities detailed in this process description and in supportingdocuments, project teams describe the work they will do, develop estimates of effort,develop a schedule, plan their management and technical approaches, identify measuresto 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], CommunicationsPlan[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 PlanTopProject Management Framework Draft V.1.00 Page 88 of 136
  • 89. Ohio State University—Office of the CIOIntegrated Project Planning—GuidelinesIt is important that people working on a project discover early in its lifecycle what itsdependencies are, what services and resources are available, and how to use themappropriately. Addressing integration requirements will help ensure that a project makesthe 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.Project Management Framework Draft V.1.00 Page 89 of 136
  • 90. Ohio State University—Office of the CIOTeam Assignment—Activity DefinitionPurpose:The objective of this activity is to ensure that individuals with the required skills areassigned to a project, and to level resources in the Work Plan. This activity may start asearly as the WBS development activity.Participants:Project Manager, Project team, and relevant stakeholdersInputs:Work Breakdown Structure [1], Time and Cost Estimates [1], Work Plan [1]. ResourcePlan [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 Plan7. 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 AssignmentsFine-tuned Work PlanTopProject Management Framework Draft V.1.00 Page 90 of 136
  • 91. Ohio State University—Office of the CIOTeam Assignment—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 91 of 136
  • 92. Ohio State University—Office of the CIOLaunch Kick-off meeting—Activity DefinitionPurpose:The objective of this activity is to ensure that all the project team members are aware ofthe ground rules of the project.Participants:Project Manager, Project team, and relevant stakeholdersInputs: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 meetingTopProject Management Framework Draft V.1.00 Page 92 of 136
  • 93. Ohio State University—Office of the CIOLaunch Kick-off Meeting Agenda TemplateProject NameStart DateEnd DateProject ManagerProject teamStakeholdersDiscussion of the Project OverviewStatementDiscussion of Communication Plan (ifclass 3,4, or 5)Ground rules of Communication (if Class1, 2)Conflict resolution process: viz. roles andresponsibilities,Operating Rules and expectations(Working style, etc.)Clarification of success criteria,objective, etc.Discussion of overall milestones andhigh-level GanttQuestionsRecap / summaryProject Management Framework Draft V.1.00 Page 93 of 136
  • 94. Ohio State University—Office of the CIOLaunch 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.Project Management Framework Draft V.1.00 Page 94 of 136
  • 95. Ohio State University—Office of the CIOInitial Risk Identification—Activity DefinitionPurpose:The objective of this activity is to ensure that the entire team identifies risks for theproject. This ensures that all perspectives are taken into account while planning for risks.Participants:Project Manager, Project team, and relevant stakeholdersInputs: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 matrixTopProject Management Framework Draft V.1.00 Page 95 of 136
  • 96. Ohio State University—Office of the CIORisk Management Matrix TemplateCategory Risk Probability Impact Exposure Mitigation (Hi- (High- (A,B,C) Strategy medium- medium- low) low)Project Management Framework Draft V.1.00 Page 96 of 136
  • 97. Ohio State University—Office of the CIOInitial Risk Identification—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 97 of 136
  • 98. Ohio State University—Office of the CIOTeam Readiness—Activity DefinitionPurpose:The objective of this activity is to ensure that individuals assigned to a project areprovided the requisite training in order to perform the job and that key goals areidentified for the team members at the start of the project.Participants:Project Manager, Project team, and relevant stakeholdersInputs: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 cohesionOutputs:Key goals for each team member, Training Needs AnalysisTopProject Management Framework Draft V.1.00 Page 98 of 136
  • 99. Ohio State University—Office of the CIOTeam 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.Project Management Framework Draft V.1.00 Page 99 of 136
  • 100. Ohio State University—Office of the CIOPerformance Tracking & Reporting—Activity DefinitionPurpose:The objective of this activity is to ensure that the team is making satisfactory progress tothe project goals. The purpose is to:1. Track all major project variables – cost, time, scope, and quality2. Track actual project accomplishments and results3. Provide visibility of progress as the project proceeds, so that the team and management can take corrective action earlyParticipants:The Project Manager is responsible for this process. The relevant stakeholders areresponsible 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 tasks4. 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 ScheduleTopProject Management Framework Draft V.1.00 Page 100 of 136
  • 101. Ohio State University—Office of the CIOProject Status Report TemplateDate:Project Name:Project Manager:Project Sponsor:Period Covered:Overall Status:Has the customer given negative feedback on any of the product components deliveredfor review? If so, what are the comments?Are Project Risks Being Successfully Mitigated? If there are risks that still exist, pleaselist them with the probability that they will occur.Accomplishments:Key Dates: List milestones that have been completed to date and projected milestones. Milestone Date Due Date Comments CompletedReason 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):Project Management Framework Draft V.1.00 Page 101 of 136
  • 102. Ohio State University—Office of the CIOUnresolved Issues: The following issues are unresolved and require management attention. Issue Assigned To Due DateChange Request: The following important change requests to the project scope are beingtracked. Additional detail is contained in the Project Change Control Log. Change Request Assigned To Due DateNew Risks observed:Trend Information: Is the project getting healthier or sicker?Project Management Framework Draft V.1.00 Page 102 of 136
  • 103. Ohio State University—Office of the CIOPerformance 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.Project Management Framework Draft V.1.00 Page 103 of 136
  • 104. Ohio State University—Office of the CIOSchedule Control—Activity DefinitionPurpose:The objective of this activity is to ensure that tasks are executed as per schedule so thatthe deadline for the project can be met. If the schedule cannot be met, the relevantstakeholders need to be informed.Participants:The Project Manager controls the schedule.Inputs:Work Breakdown Structure[1], Work Plan[1], Integrated Project Plan[3], ChangeRequest 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 planMilestone trend chartsTopProject Management Framework Draft V.1.00 Page 104 of 136
  • 105. Ohio State University—Office of the CIOSchedule 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 CIOProject Management Framework Draft V.1.00 Page 105 of 136
  • 106. Ohio State University—Office of the CIOChange Control—Activity DefinitionPurpose:The objective of this activity is to ensure that all changes to scope are documented andauthorized 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 dateProcess: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 FormTopProject Management Framework Draft V.1.00 Page 106 of 136
  • 107. Ohio State University—Office of the CIO Change Request Form TemplateChange Request FormChange #CustomerProject:Change RequestorDate submittedDate by which changerequest needs to beapprovedDate by which changeneeds to take placeSystem AffectedChange Type Scope change/ Technology change/ OtherImpact Project Activities: Cost (USD)/Effort (Hours)ShortDescriptionJustificationImpact of notimplementing proposedchangeAlternatives to theproposed changeDetailed or Reference Supporting DocumentsDescriptionAssessed By Date:Assessment or Reference Supporting DocumentsNotesInitial impact Analysis Additional Work days: Additional Cost: (of which Rework cost is______)Resolution or Reference Supporting DocumentsNotesFinal recommendation Assessment & Resolution Accepted/Change Not Accepted/Change DeferredCustomer Closeout Date:signature Project Management Framework Draft V.1.00 Page 107 of 136
  • 108. Ohio State University—Office of the CIOProject Manager Date:Closeout signatureSenior Manager signature Date Project Management Framework Draft V.1.00 Page 108 of 136
  • 109. Ohio State University—Office of the CIOChange 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.Project Management Framework Draft V.1.00 Page 109 of 136
  • 110. Ohio State University—Office of the CIOCost Control—Activity DefinitionPurpose:The objective of this activity is to manage project cost such that it is aligned withbudgeted cost.Participants:Project Manager, Stakeholders, SponsorInputs: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 reportsTopProject Management Framework Draft V.1.00 Page 110 of 136
  • 111. Ohio State University—Office of the CIOCost 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.Project Management Framework Draft V.1.00 Page 111 of 136
  • 112. Ohio State University—Office of the CIOQuality Assurance & Control—Activity DefinitionPurpose:The objective of this activity is to ensure that the project team meets the projectrequirements and that all requisite quality criteria are met.Participants:Project Manager, Project teamInputs: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 standardsProcess: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 reportsTopProject Management Framework Draft V.1.00 Page 112 of 136
  • 113. Ohio State University—Office of the CIOQuality 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.Project Management Framework Draft V.1.00 Page 113 of 136
  • 114. Ohio State University—Office of the CIOProcurement Management—Activity DefinitionAny 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, thatthe process of selection is fair and that the quality of work is acceptable.Participants:Project Manager, OSU Purchasing department, and OSU Legal departmentInputs:Project Schedule[1], Work Breakdown Structure[1], Integrated Project Plan[3],Procurement Plan[5], OSU Procurement ProcessProcess: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 WorkTopProject Management Framework Draft V.1.00 Page 114 of 136
  • 115. Ohio State University—Office of the CIOProcurement Management—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 115 of 136
  • 116. Ohio State University—Office of the CIORisk Management—Activity DefinitionPurpose:The objective of this activity is to reduce the probability of the identified risks, identifymitigation strategies, identify contingency plans for the more critical risks, and ifrealized, 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 plansTopProject Management Framework Draft V.1.00 Page 116 of 136
  • 117. Ohio State University—Office of the CIORisk 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 dont 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.Project Management Framework Draft V.1.00 Page 117 of 136
  • 118. Ohio State University—Office of the CIOInformation Distribution—Activity DefinitionPurpose:The objective of this activity is to ensure that all appropriate parties are kept informed.Participants:Project Manager, Project team, and relevant stakeholdersInputs:Integrated Project Plan [3]Process: 1. Execute Communication Management Plan. 2. Monitor and revise communication management plan as necessary.Outputs:Instrument decided in Communication PlanTopProject Management Framework Draft V.1.00 Page 118 of 136
  • 119. Ohio State University—Office of the CIOInformation Distribution—Guidelines1.All relevant information needs to be communicated to the appropriate parties at theright time and in the appropriate format.2.The frequency of team meetings depends on the timetable for the project and the needto get information in a timely manner. For instance, if the project is three weeks, the teammight want to meet twice a week. If the project is eight weeks, weekly is probablyappropriate3. Managing communication on a project is very much a matter of managingexpectations. Status Reports, for instance, are a way of communicating to stakeholdershow the project is progressing against its schedule and budget. You include informationon issues, scope change, risks, etc., as a part of providing information to manageexpectations.Project Management Framework Draft V.1.00 Page 119 of 136
  • 120. Ohio State University—Office of the CIOTime Tracking & Management—Activity DefinitionPurpose:The objective of this activity is to ensure that all time spent on a project is tracked. At anorganizational level, this information can be analyzed and used to estimate likely effortand cost for similar projects.Participants:The Project Manager, Team membersInputs: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 projectsTopProject Management Framework Draft V.1.00 Page 120 of 136
  • 121. Ohio State University—Office of the CIOTime 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.Project Management Framework Draft V.1.00 Page 121 of 136
  • 122. Ohio State University—Office of the CIOTransition to Production—Activity DefinitionPurpose:The objective of this activity is to ensure that the transition of the project to production issmooth.Participants:The customer, Project Manager, the Project team, and the relevant stakeholdersInputs: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 liveTopProject Management Framework Draft V.1.00 Page 122 of 136
  • 123. Ohio State University—Office of the CIOSummary ReportProject Name:Project Manager:Project Description:Initial EstimatedEffort:Revised estimatedeffort:Actual Effort:Initial Estimated Cost:Revised estimatedcost:Actual Cost:Deliverables:Initial End date:Actual End date:Lessons Learned:Recommendations forfuture projects:Project Management Framework Draft V.1.00 Page 123 of 136
  • 124. Ohio State University—Office of the CIOTransition to Production—Guidelines1. The Project Manager ensures that all the necessary testing is carried out.2.The Project Manager ensures that the completeness and correctness criteria of theproject are met.3. If there is no Operational Transfer Plan, the Project Manager needs to ensure thefollowing: 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.Project Management Framework Draft V.1.00 Page 124 of 136
  • 125. Ohio State University—Office of the CIOWrap-up Meeting—Activity DefinitionPurpose:The objective of this activity is to ensure that the project team discusses the project afterthe project has been executed so that Lessons Learned are captured and issues areanalyzed.Participants:Project Manager, Project team, and relevant stakeholdersInputs: Project Schedule[1], Bug Reports[1], Review Reports[1], Integrated ProjectPlan[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:MinutesTopProject Management Framework Draft V.1.00 Page 125 of 136
  • 126. Ohio State University—Office of the CIOWrap-up meeting—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 126 of 136
  • 127. Ohio State University—Office of the CIOLessons Learned—Activity DefinitionPurpose:The objective of this activity is to ensure that the Lessons Learned during the project aredocumented and incorporated in the knowledge base for future use.Participants:Project Manager, Project team, and relevant stakeholdersInputs:Minutes of the various meetings[1], Project Schedule[1], Minutes of the wrap upmeeting[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 DocumentTopProject Management Framework Draft V.1.00 Page 127 of 136
  • 128. Ohio State University—Office of the CIOLessons Learned—Guidelines1. 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.Project Management Framework Draft V.1.00 Page 128 of 136
  • 129. Ohio State University—Office of the CIOAdministrative Closure—Activity DefinitionPurpose:The objective of this activity is to ensure that the Project is approved, accepted andclosed.Participants:Project Manager, Project team, relevant stakeholders, and the CustomerInputs:Project Schedule[1], Integrated Project Plan[4], Operational Transfer Plan[4], Requiredsign-offsProcess: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:MetricsTopProject Management Framework Draft V.1.00 Page 129 of 136
  • 130. Ohio State University—Office of the CIOAdministrative 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/services 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 organizations 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.Project Management Framework Draft V.1.00 Page 130 of 136
  • 131. Ohio State University—Office of the CIOGLOSSARYApproach:A way of doing things. For example, different approaches may be considered forimplementing a project but only one will be chosen.Business Case:A document developed towards the end of the project definition phase to establish themerits and desirability of the project and justification for further project definition. This isused to justify the commitment of resources to a project. This is the informationnecessary to enable approval, authorization and policy-making bodies to assess a projectproposal and reach a reasoned decision.Central RepositoryA central repository, is owned and maintained by someone within your PerformingOrganization, and provides a place where lessons learned and best practices can bearchived for use by all Project Managers in the organization. Over time, as more andmore 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 reportingof proposed changes to an item.Overview statement:A document consisting of a mission statement, including background, purpose, andbenefits, a goal, objectives, scope, assumptions and constraints. A Project Overviewstatement clearly documents project definition in order to bring a project team intonecessary agreement.Configuration audit:A check to ensure that all deliverable items on a project conform with one another and tothe current specification. It ensures that relevant quality assurance procedures have beenimplemented and that there is consistency throughout project documentation.Contingency Plan:An alternative for action if things dont go as planned or if an expected result fails tomaterialize.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 (inour case – the organization refers to a project).Project Management Framework Draft V.1.00 Page 131 of 136
  • 132. Ohio State University—Office of the CIOInitiation:The process of preparing for, assembling resources and getting work started. May applyto any level, e.g. program, project, phase, activity, task. It is the process of committing anorganization 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 teammember, that reflect directly on the key objectives of the project, and that provide thebasis for ratings during performance appraisals.Mitigation:Working to lessen risk by lowering its chances of occurring or by reducing its effect if itdoes occur.Opportunity Costs:The value of an opportunity that is lost or sacrificed when the choice of one course ofaction requires that another course of action must be given up. A non-accounting valuethat can be significant in certain circumstances, usually as a consequence of limitedresources. It is measured by the profit that could have been generated had the resourcesbeen 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 beforeit is completed. Each activity is assigned a best, worst, and most probable completiontime estimate. These estimates are used to determine the average completion time. Theaverage times are used to figure the critical path and the standard deviation of completiontimes for the entire project.Phase gate:The point at the end of a project phase where project performance is measured and adecision is made whether the project can move to the next phase or whether the projectshould be killed.Project:A unique venture with a beginning and an end, undertaken by people to meet establishedgoals within defined constraints of time, resources, and quality.Project Management Framework Draft V.1.00 Page 132 of 136
  • 133. Ohio State University—Office of the CIOProject management:The application of modern management techniques and systems to the execution of aproject from start to finish, to achieve predetermined objectives of scope, quality, timeand cost, to the equal satisfaction of those involved.Quality assurance:A planned and systematic pattern of all actions necessary to provide adequate confidencethat 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 whois affected by the project. A relevant stakeholder in the case of a Project Overviewstatement review could be the sponsor or the Operating Unit Head. In case of a weeklystatus report, the relevant stakeholder could be the Operating Unit Head. In case of TeamDevelopment, the relevant stakeholders could be the people responsible for training.Risk:Risk is the cumulative effect of the chances of uncertain occurrences, which willadversely affect project objectives. It is the degree of exposure to negative events andtheir 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 undertakesto provide to the project sponsor. The required set of end results or products withspecified physical or functional characteristics.Scope creep:On-going requirements increase without corresponding adjustment of approved cost andschedule allowances. As some projects progress, especially through the definition anddevelopment phases, requirements tend to change incrementally, causing the ProjectManager to add to the projects mission or objectives without getting a correspondingincrease 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 bythe project.Versions:A variant of some element (typically a document, or a product); later versions of thiselement typically expand on earlier versions.Project Management Framework Draft V.1.00 Page 133 of 136
  • 134. Ohio State University—Office of the CIOWork Breakdown Structure:A task oriented detailed hierarchical breakdown, which defines the work packages andtasks at a very low level.Workgroup:This could be a project team. In the Project Classification matrix, it refers to the peoplefrom 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 lowestlevel 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 Management Framework Draft V.1.00 Page 134 of 136
  • 135. Ohio State University—Office of the CIOProject Classification - Activity DefinitionPurpose: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 managementactivities need to be carried out for the project. Each class corresponds to a set of projectmanagement 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 ClassProject Management Framework Draft V.1.00 Page 135 of 136
  • 136. Ohio State University—Office of the CIOProject 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.Project Management Framework Draft V.1.00 Page 136 of 136