Value of a PMO

1
The Value of a Project Management Office
2
Agenda

• Problem Statement
• Solution Project Management Office
• Results Critical Success Factors
• Next Steps

3
Problem Statement
4
Types of Work

• Operations
• Projects

5
Project

• A project is a temporary endeavor undertaken to
  create a unique product or service.
• Temporary definite beginning and definite end
• Unique the product or service is different in
  some distinguishing way from all similar products
  or services
• PMBOK

6
Project
Operations
7
Problems

• Lack of formal training
• No consistent management
• Lack of prioritization
• No formal tracking
• Lack of communication
• Lack of functional user involvement

8
Problems

• Not On-Time
• Not On-Budget
• Not Meeting Expectations

9
SolutionFirst Attempt
10
First Attempt

• Inventory projects
• Current, approved and pending
• Prioritize current projects
• Schedule projects and set end-dates
• Require project plans
• Implement Project Central
• Trained staff

11
Project Managers

• Individual responsible for the project
• Assigned to a specific application area
• Other technical staff

12
Problems continued

• Lack of communications
• Lack of functional user involvements
• Lack of project management skill sets
• Not on-time
• Not on-budget

13
1995 Standish Group

• Resolution Type 1, or project success
• The project is completed on-time and on-budget,
  with all features and functions as initially
  specified.
• Resolution Type 2, or project challenged
• The project is completed and operational but
  over-budget, over the time estimate, and offers
  fewer features and functions than originally
  specified.
• Resolution Type 3, or project impaired
• The project is cancelled at some point during the
  development cycle.

14
Results

• Overall, the success rate for IT projects was
  only 16.2
• Challenged projects (overtime or over budget)
  accounted for 52.7,
• Impaired projects (cancelled) 31.1.

83.8 failure rate
15
Failure Stats
16
Causes

• One of the major causes of both cost and time
  overruns is restarts.
• For every 100 projects that start, there are 94
  restarts.
• This does not mean that 94 of 100 will have one
  restart, some projects can have several restarts.

17
Project Success Factors

• User Involvement 15.9
• Executive Management Support 13.9
• Clear Statement of Requirements 13.0
• Proper Planning 9.6
• Realistic Expectations 8.2
• Smaller Project Milestones 7.7
• Competent Staff 7.2
• Ownership 5.3
• Clear Vision Objectives 2.9
• Hard-Working, Focused Staff 2.4
• Other 13.9

18
Why Projects Fail

• Incomplete Requirements 13.1
• Lack of User Involvement 12.4
• Lack of Resources 10.6
• Unrealistic Expectations 9.9
• Lack of Executive Support 9.3
• Changing Requirements Specifications 8.7
• Lack of Planning 8.1
• Didn't Need It Any Longer 7.5
• Lack of IT Management 6.2
• Technology Illiteracy 4.3
• Other 9.9

19
SolutionProject ManagementOffice (PMO)
20
Project Management Office (PMO)

• Provide the structure and expertise needed to
  improve project success rates

21
Goals

• Improve Project Success
• Standardize the Project Process

22
Objectives

• Follow consistent methodology
• Improve PM skills
• Improve management
• Improve communication
• Improve functional user involvement
• Prioritize projects
• Monitor progress/budget

23
PeopleProcessTechnology
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
Implementation Phase

• Schedule Project
• Assign PM
• Identify Project Team
• Executive Sponsor
• Functional Lead(s)
• Technical Lead(s)
• Other Resources

29
Implementation Phase

• Formulate Steering Committee
• Create a Communications Team

30
Implementation Phase cont.

• Develop Project Charter
• Identify Executive Sponsor
• Set Expectations
• Sets Milestones
• Identify Project Team
• Roles
• Responsibilities

31
Implementation Phase cont.

• Project Kickoff
• Project Plan
• Sub-Plans
• Implementation
• Location

32
Implementation Phase cont.

• Project Meetings
• Weekly Progress Reports
• Accomplishments
• Risks/Issues
• Steering Committee Meetings
• Communication Meetings

33
The 7 Warning Signs

• Lack of a compelling business case
• No Agreement to requirements
• Lack of a current published plan
• No user involvement
• Lack of executive support
• Lack of Change Control process
• Lack of Accurate status reporting

Anthony C. Mersino, PMP 1995- 2002 CNET Networks,
Inc
34
Business Case

• Why Important
• It should offer a cost-benefit analysis and will
  often consider business risks and the impact of
  external events on the project.
• Organizations use business cases to prioritize
  their limited resources for those opportunities
  that will provide the greatest return.

• Project Feasibility document

35
No Agreement to Requirements

• Why Important
• In the Standish Group report, the three
  most-common factors in challenged projects were
  requirements related.
• Requirements suggest the size and shape of the
  system being built.
• They define what the system should and shouldnt
  do.

• Project Charter

36
Lack of a Current Published Plan

• Why Important
• Every project is a unique undertaking and each
  should have a project plan.
• Plans are essential for communications with all
  stakeholders, for providing an indication of
  progress, and for determining the work remaining
  to be completed.

• Policy requires all plans published to project
  server and updated weekly

37
(No Transcript)
38
No user involvement

• Why Important
• Lack of user participation can mean that users
  are resistant to change.
• Projects need input from the client or the user
  group. Without it, requirements and system design
  take place in a vacuum.

• Deep involvement of Functional users

39
Lack of Executive Support

• Why Important
• He or she can help to keep a project focused and
  on track and help remove major roadblocks for the
  team,
• Project sponsors must be competent to clear those
  roadblocks, and they must have the power to
  resolve issues with conflicting interests. How we
  account

• Project Charter

40
Lack of Change Control Process

• Why Important
• Projects without change control processes are
  impossible to estimate accurately because the
  size of the solution is changing continuously.
• In addition, changes usually result in some
  rework that further delays progress and
  de-motivates the project team.

• PMs required to have change control
• PMO must approve all budget changes

41
Lack of Accurate Status Reporting

• Why Important
• Reports provides communications to the
  stakeholders and offers a mechanism to determine
  whether corrective action is required.
• Reports also serves as a scorecard to show where
  the project is versus the plan.

• Status reports published to Project Server weekly

42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
Project Policies

• Draft UPP
• IT Project Policy
• Testing Policy

47
Draft UPP

• An IT Project is not necessarily just technical
  in nature
• Most IT projects are addressing the business
  needs of the requester and applies technology to
  satisfy these needs.
• Some examples of IT project are setting up file
  and back-up file shares, installing or upgrading
  an application, improving the technology
  infrastructure of an area (installing switches,
  fiber, servers), etc.
• All projects that have an IT component must be
  vetted by the IT Services PMO
• If the project is predominantly IT in nature then
  IT Services PMO will manage the project

48
IT Services Policy

• Planning the Project
• Visualize the Goal
• Determine the tasks
• There must be One Leader
• Assign People to Jobs
• Manage Expectations/Risks

• Executing the Plan
• Use an appropriate leadership style
• Know what's going on
• Tell people what's going on
• Dynamic Scheduling
• Transition to production

49
Testing Policy

• Unless previously approved, a test plan will be
  developed and executed for each development
  initiative The developer will test the initiative
  first in order to uncover any issues.
• An appropriate end-user expert will be called
  upon to thoroughly test the initiative.
• After testing is completed, an e-mail sent by an
  appropriate end-user validating the accurate
  completion of the testing will be required before
  the initiative will be placed into production.
• If the initiative requires a Change Request, the
  text of the e-mail approval will be pasted into
  the Activity section of the request form.

50
Project Closure

• Project Complete
• Transition to Operations
• Formal Project Closure
• Post Project Review

51
Results/Critical Success Factors
52
Results

• On-Time
• On-Budget
• Increased User Satisfaction
• More Projects Completed

53
Critical Success Factors

• Management of Expectations
• Adequate Budget
• Cross-functional Teams
• Strategic Use of Consultants
• Right Project Manager
• Effective Steering Committee
• Minimal Scope Creep

54
Next Steps
55
Next Steps

• More Documentation
• Better Transition to Operations
• Improved Project Reviews
• Staff Evaluations
• User Assessments
• Resource usage
• Formal Approval Process

56
(No Transcript)
57
(No Transcript)
58
Approval Process

• Academic Technology Advisory Committee
• University Policy Procedure

59
Academic Technology Advisory Committee

• Key Academic Representatives
• Charge
• Recommend/prioritize technology projects that fit
  with the universitys academic technology plan
• Recommend IT Strategic Plan

60
University Policy Procedures

• Formal policy regarding IT projects
• VP/Dean Approval
• IT Services Approval
• Funding Plan

61
Approval Process
62
Summary

• Problem Statement
• Solution PMO
• Results Critical Success Factors
• Next Steps

63
Questions