This document provides an overview of a Project Management Office's (PMO) methodology for project delivery. It includes sections on PMO roles and responsibilities, phases of project delivery, key performance indicators, tools used by the PMO, and processes for activities like status reporting, risk management, and quality assurance. The goal of the PMO methodology is to ensure successful project delivery in terms of being on time, on budget, and meeting client and employee satisfaction objectives.

1. PMO – DELIVERY
METHODOLOGY OVERVIEW
Daniel Brody © 2014

2. TABLE OF CONTENTS
 PMO Overview 4
 PMO Roles & Responsibilities6
 PMO Phases9
 Key Performance Indicators 10
 PMO Tools 12
 Statement of Work/Contract 14
 Project Charter 15
 Project Workplan 17
 Project Calendar 18
 Deliverables Inventory 19
 Risk Management 20
05/22/14 2

3. TABLE OF CONTENTS
 Issue Management 22
 Change Request Management 25
 Decision Log 28
 Weekly Status Reports 29
 Monthly Steering Committee Meetings 30
 Meeting Agenda and Minutes 31
 Project QA Process 32
 Document Naming and Storage 33
 Client / Employee Satisfaction Processes 36
 Implementation Methodology Overview 44
05/22/14 3

4. PMO OVERVIEW
What is a Project Management Office (PMO)?
 The PMO is composed of project leadership and administrative support (as required).
 The specific size and composition w ill vary from project to project based on project size,
complexity, client involvement and project management capabilities
 The objective of the PMO is to ensure a successful project delivery:
 On time/on budget and overall control of Scope, Time & Cost
 Excellent client satisfaction
 Excellent employee/team satisfaction
 The benefits of a PMO include:
 Promotion of standard and repeatable delivery processes and deliverables
 Early identification and management of Issues and Risks
 Continual communication throughout the project team and client leadership
05/22/14 4

5. PMO OVERVIEW (CONT’D)
 Specific responsibilities of the PMO include:
 Project w orkplan development and maintenance
 Regular time tracking, including identification of estimates to complete and
variances to budget
 Scope Change Management
 Status Reporting
 Deliverable review
 Project operational and financial analysis
 Risk Management
 Issue Management
 Steering Committee Reporting
 Quality Review s
05/22/14 5

6. PMO ROLES AND
RESPONSIBILITIES
05/22/14 6
The Project Management Office consists of project leadership and administrative
support staff as appropriate for the engagement. Factors such as project team size, risks
and complexity will determine the need for full or part-time Project Office and
Administrative Support.
Managing Director
Project Office
& Admin
Team Leads Team Leads
Project Manager

7. PMO ROLES AND
RESPONSIBILITIES
 Managing Director – The role of the Managing Director is to w ork closely w ith
senior client leadership to ensure a successful delivery process. The Managing
Director is focused on project delivery, successful adoption by user community, and
client satisfaction. The Managing Director w ill serve on the Project Steering
Committee.
 Project Manager – The Project Manager has primary day-to-day responsibility for
the engagement. The PM w ill be responsible for providing w eekly status updates
to the client and for conducting monthly Steering Committee meetings. The PM is
also responsible for Risk Management and Issue Management.
 PMO Manager – The PMO Manager has day-to-day operational responsibility for
managing the PMO and overall quality assurance responsibility for the project.
This individual w ill perform thorough QA assessments, assuring that projects meet
the defined business requirements, identifying risk areas and mitigating actions at
multiple points in the implementation cycle, and producing consolidated reports
from the PMO on all Programs and component projects. The PMO Manager is also
responsible for assessing actual project team time and expense utilization and
estimates to complete, relative to project budgets. The PMO Manager may be a
full or part-time role on the engagement.
05/22/14 7

8. PMO ROLES AND
RESPONSIBILITIES
 Project Administration – Depending on the project, resources may be assigned on a full and/or part-
time basis to assist w ith administrative activities. The Project Administrator has direct responsibility
for maintaining the master project plans, resource schedules, and issue/change logs. This individual
w ill issue the w eekly task sheets, collect w eekly time & estimate to complete reports, apply actuals to
the project plans, and produce w eekly productivity and progress reports. The PA w ill ensure that the
resource schedules are kept current, that standard meeting schedules are maintained, and w ill
facilitate and maintain meeting minutes as required. Offsite IT Solutions personnel w ill be
responsible for entry of financial information, accounts receivable, generation of financial reports,
etc. If Administrative support staff is not assigned to an engagement, these responsibilities may be
allocated amongst the other PMO team members.
 Team Leads – Depending on the engagement, individual team leads w ill be responsible for
developing and managing the project plans associated w ith their specific portions of the project.
These plans w ill roll up into a summary w orkplan. Team leads may also be responsible for preparing
status reports, participating in Steering Committee meetings and risk and issue management.
05/22/14 8

9. PMO PHASES
05/22/14 9
Initiation
(1 week)
Planning
(2 weeks)
Execution
(Project
Duration)
Closure
(1-2 weeks)
• Gather all available
background info (RFP,
proposal, discovery notes,
estimating models, timelines)
• Determine magnitude of
effort
• Schedule review with
@CIOBRODY leadership
• Set-up project (client codes,
project codes, accounting,
etc.)
• Develop detailed scope
statement with client
• Create Project Charter
• Create Project Schedule
• Create a consolidated project
workplan
• Conduct initial Risk
Assessment
• Conduct kickoff meeting(s)
• Obtain stakeholder buy-in of
plans, budget and scope
• Ensure resource availability
• Ongoing workplan
management
• Phase Reviews (QA & Risk
Assessment)
• Assist in management of
Issues and Risks
• Project performance analysis
• Client Satisfaction reviews
• Employee Satisfaction
Reviews
• Change control management
• Final project plan updates
• Communicate project
closure (charge codes
closed, accounting, etc.)
• Ensure @CIOBRODY
Staffing aware of resource
rolloff dates
• Generate Project Report
• Archive documentation
(soft and hard copies)
• Conduct debriefing
• Celebrate
DELIVERABLES
Sales Inputs
• RFP
• Proposal
• Discovery Notes
• Work level estimates
• Project codes
• Initial timelines
• Staffing requests
• Statement of
Work/Contract
• Project Charter
• Project Schedule
• Consolidated Workplan
• Resource Assignments
• Risk Assessment
• Initial Risk Log
• Kickoff presentation
• Updated workplan
• QA Assessment(s)
• Issues Logs
• Risk Assessment(s)
• Risk Logs
• Client Sat Surveys
• Employee Sat Surveys
• Change Logs
• Project performance
reports
• Final workplan
• Final performance/
profitability assessment
• Staff evaluations
• Project Report
• Documentation archives
• Client Sat Survey
• Client sign-off
• Employee Sat Survey
• Archived deliverables
• Follow-on Work

10. KEY PERFORMANCE INDICATORS
05/22/14 10
The chart on the following pages presents potential metrics that can be used by IT Solutions to assess its
performance. KPI’s have been organized by Financial, Operational and Administrative. The chart also indicates
whether the metric can be used to measure Business Development performance and/or to assess the delivery of an
individual project. Oracle will be used to provide these metrics where possible. Where Peoplesoft does not
capture the data needed, the TEMPLATE - Project Performance.xls spreadsheet may be used.
Metric Comment
Financial Metrics Refer to TEMPLATE - Project Performance.xls for details
Project Revenue Variance Broken down by Fees/Expenses and Totals. Calculate by dividing Estimate at
Completion (To Date + ETCs) - Budget. Report by Total as well as % of Budget.
Profitability Margin Broken down by Fees/Expenses and Totals. Calculate by taking fees (expenses and
total) realized per period and subtracting costs. Calculated in dollars as well as %.
Calculate variance vs. original budget.
Efficiency Measures Fees Earned (Budget Fees – ETC Fees). More relative on Fixed Fee
engagements than on T&M since Fees Earned = Hours Worked * Bill Rate.
Change Orders as % of Initial Budget Should not exceed x% of original budget. Measures effectiveness of
discovery/proposal process.
Follow-On Opportunities Proposed $ as well as closed $
Charge-Off % Project Write-Offs (0$ Change Orders, Expense Write-offs, Bill Reductions) as a %
of Total Budget

11. KEY PERFORMANCE INDICATORS
05/22/14 11
Metric Comment
Operational Metrics
Project Hourly Variance Calculate by dividing Estimate at Completion (To Date + ETCs) - Budget.
Report by Total as well as % of Budget.
Efficiency Measures Hours Earned (Budget Hours – ETC) against workplan.
Change Orders as % of Initial Budget Should not exceed x% of original budget. Measures effectiveness of
discovery/proposal process.
Client Satisfaction See TEMPLATE – Client Sat Results.xls and TEMPLATE – Client Sat
Survey.doc for survey form and summary spreadsheet
Project QA Results QA Survey form Form layout shown in TEMPLATE – QA Checklist
Administrative
Overtime %
Days Outstanding Timely payment by clients contributes to cash flow. Often an indicator of client
satisfaction.
Employee Satisfaction Refer to TEMPLATE – Employee Sat.doc
Utilization
Performance Reviews Outstanding Timely feedback critical to Employee Development

12. PMO TOOLSThe follow ing slides present the standard tools w hich w ill be used by the PMO to provide quality delivery
oversight. Use of these tools is required and their application w ill be review ed as part of the project QA process.
05/22/14 12
PMO Deliverable Frequency/When Prepared By Inputs Template
Statement of
Work/Contract
Prior to kickoff Sales Team, Project
Manager, Managing Director
Proposal, Client feedback TEMPLATE – SOW.doc
Project Charter At project kickoff PM or PMO Manager with
input from Sales, Mng. Dir.
Proposal, Contract/SOW TEMPLATE – Project
Charter.doc
Project Workplan Created at kickoff, updated
at least weekly
PM or Team Leads with
input from team
SOW/Contract, Estimating
Models, Methodology
TEMPLATE – Project
Workplan.mpp
Project Calendar Created at kickoff, updated
at least weekly
PM or Project Admin. Workplan, Vacation Calendar
Deliverables Inventory Created at kickoff, updated
as workplan changes
PM Workplan, Methodology TEMPLATE –
Deliverables
Inventory.doc
Risk Assessment Art kickoff and at key
milestones
PMO Manager and/or
Managing Director
Proposal, Contract, Workplan,
Project deliverables, Client Sat
Surveys, Employee Sat Survey
TEMPLATE – Risk
Management Tool.xls
Risk Log Throughout project PM with input from Team
Leads
Risk Assessment TEMPLATE – Risk
Log.xls
Issues Log Throughout project PM or Team Leads with
input from team
IssueTrak www.issuetrak.com/@CI
OBRODY
Change Control Form &
Log
Throughout project PM or Team Leads with
input from team
Client Change Requests, Issues
Log
TEMPLATE – Project
Change Request
Form.doc
Template – Project
Change Request Log

13. PMO TOOLS
05/22/14 13
PMO Deliverable Frequency/When Prepared By Inputs Template
Decision Log Throughout project PM with input from
team leads
Significant client decisions that
should be highlighted and
communicated
TEMPLATE – Decision
Log.xls
Status Reports & Meeting
Minutes
Weekly throughout project PM and Team Leads Issues Log, Risk Log, Change
Request Log, Decision Log, Updated
Workplan
TEMPLATE – Weekly
Status Report.doc
Steering Committee
Presentation & Meeting
Minutes
Monthly throughout
project
Managing Director and
PM
Issues Log, Risk Log, Change
Request Log, Decision Log, Updated
Workplan
TEMPLATE – Steering
Committee
Presentation.ppt
Quality Assurance Checklist At phase/key milestone
completion
PMO Manager or
Managing Director
Proposal, Contract, Workplan, Project
deliverables, Client Sat Surveys,
Employee Sat Surveys, Status reports,
Steering Committee presentations
TEMPLATE – QA
Checklist.xls
Document Naming & Storage
Standards
Throughout sales cycle and
engagement
Sales and project
teams
Directory Structure.xls
Client Satisfaction Survey At kickoff and at
completion of phases/key
milestones
Managing Director or
PMO Manager
Client interviews TEMPLATE.Client
Satisfaction Survey.doc
TEMPLATE – Client
Satisfaction Results.xls
Employee Satisfaction Survey At least quarterly and at
project completion
Managing Director or
PMO Manager
Employee surveys (TEMPLATE –
Employee Satisfaction
Survey)
TEMPLATE –
Employee Sat
Results.xls

14. STATEMENT OF
WORK/CONTRACT
Before beginning any work for a client, a contract or Statement of Work (SOW) will be prepared by the Sales
Team, the Managing Director and the Project Manager. This document should be signed prior to sending any
team members to a client site, although exceptions may be appropriate for existing clients, follow-on
engagements or where the client has agreed to interim funding while the contract details are being finalized.
While the client may have their own standard contract formats, @CIOBRODY should ensure the following
information is presented within the SOW/Contract:
• Scope Definition – this should be a very detailed description of the services and deliverables @CIOBRODY is being engaged
to provide the client. It should describe the underlying business issues, the proposed solution, any integration
requirements, training to be provided, data conversion requirements, etc. in clear and concise terms.
• Assumptions – The SOW/Contract should also detail any assumptions made which impact scope (number or reports to be
written, location of project team members, resources to be provided by the client (people, workspace, computer
equipment, servers, access, project start dates , etc.).
• Timeline – A high-level overview of the key milestones of the engagement should be included in the SOW.
• Change Management – The contract/SOW should include a description of the process for identifying, documenting and
approving changes to scope.
• Project Organization – While specific names in the project organization may not be assigned, the SOW should include an
organization chart which shows the types and levels of client, @CIOBRODY and any vendor or other third party project
team and Steering Committee members. It should also include brief descriptions of key roles and responsibilities.
• Project Financials – The contract/SOW Should include the financial terms, payment schedule, expense policies, etc.
A sample Statement of Work is project in TEMPLATE – SOW.doc
05/22/14 14

15. PROJECT CHARTER
The Project Charter is a governance document. It will be developed during the project’s planning phase and
must be jointly approved by Client and @CIOBRODY Project Management prior to project execution phases.
The Project Charter documents:
 Project objectives, scope, and critical success factors
 Project approach
 Assumptions and planning principles
 Risks and constraints
 Key project resources
 Project workplan, responsibilities, and status reporting
 Project Management, Schedule Reviews, and Status Reporting
 Steering Committee Meetings
 Risk Management Reviews
 Quality Assurance Reviews
 Weekly Financial Reporting
 Time Entry
 Status Reporting
 Project Team Schedules
 Meeting Schedules, Agendas, and Meeting Minutes
 Client Contacts and Communications
05/22/14 15

16. 05/22/14 16
PROJECT CHARTER
The Project Charter continued …
– General and Administrative policies
• Client Transmittals and Approval Documents
• Project Document Storage
• Standard work day
• Travel and Expense Reporting
• Dress Code
• Vacation and time-off requests
• Safety and health

17. PROJECT WORKPLAN
A detailed, task level project workplan will be prepared by the Project Manager and Team Leads. The
workplan will identify milestones, inter-task dependencies and any deliverables associated with each
task. It will also identify individual team members responsible for completing each task, the time
allocated to each team member for the task and the Start and Completion Dates. The workplan should
also include resource loading so that individual team members vacation or other time away from the
project is incorporated.
Microsoft Project will be used as the standard tool for developing workplans, project calendars, time
sheets and for recording time spent, ETCs, etc. It will then provide the data necessary for determining
project efficiency, budget variances and other performance metrics.
Team members will receive weekly (or bi-weekly) time tracking sheets so that they can record the time
spent on each task, the estimate to complete (or % complete) and any revisions to Start/End Dates.
This information should foot to the time sheets submitted to @CIOBRODY so that hours charged to the
project from a billing perspective equal those on the workplan. Reference the PMO Time Entry
Process.doc or Time Entry section of the Project Charter.
This data will also be loaded into the TEMPLATE - Project Performance.xls spreadsheet to calculate
Efficiency Ratios, Margins and Variances.
The workplan should be kept current with any changes to tasks, timelines or resource loadings due to
changes in scope, staffing or other factors.
05/22/14 17

18. PROJECT CALENDAR
A calendar which incorporates project milestones and key deliverable dates from the project workplan,
along with meetings and vacation or other time away for key project team members and clients will be
maintained. This calendar should be incorporated into the Weekly Status Reports to provide management
an ongoing short-term (4-5 week) window of upcoming events.
05/22/14 18
Monday Tuesday Wednesday Thursday Friday
8/12 8/13
8/14
1-2 – Status Meeting
8/15
8/16
Detail Design Sign-
Off
8/19
8/20 8/21
1-2 – Status Meeting
8/22
8/23
1-2 Steering
Committee
8/26
CRP
8/27
CRP
8/28
CRP
1-2 – Status Meeting
8/29
2-3 Steering
Committee Mtg.
8/30
9/2
LABOR DAY
9/3
PM on Vacation
9/4
PM on Vacation
1-2 – Status Meeting
9/5
PM on Vacation
9/6
PM on Vacation

19. DELIVERABLES INVENTORY
Every project, regardless of size or complexity, should maintain an inventory of deliverables. This should
be generated as part of the workplan development process so that team members understand the specific
deliverables they are to produce and that clients understand what deliverables will be produced and when.
A standard file naming convention will be implemented to ensure consistency and allow for easy archival
and retrieval. Additionally, a standard set of file folders will be set up on the server to ensure deliverables
are stored in a common, secured, archived location (vs. individual hard drives) and that team members
know where to look for a specific document, vs. having to search multiple folders.
05/22/14 19
Deliverable Name Description Responsible Milestone
Date
Workpaper X-Ref
System Schematic PowerPoint or Visio drawing
presenting the Inputs, Processes
and Outputs of the system
Technical Architect 11/1/02 ISG.DD.System
Schematic.v1.doc
Test Scripts Word or Excel documents which
present test cases, test inputs and
expected results.
Test Team 12/1/02 ISG. ST.Test
Script.Cycle1.2.v1.doc
Training Plan Word document which provides a
high level summary of training
requirements and over timeline
for training.
Training Team 11/1/02 ISG.TR.Training Plan.IH.
v1.doc

20. RISK MANAGEMENT
Risk Management is an important element of successful project sales and delivery. Early identification
and continual management of serious issues and potential threats to a project is critical to ensuring
client satisfaction and an on-time, on-budget delivery.
Sales Process - During the Business Development cycle, it is important to conduct a thorough
discovery process to identify potential scope, client, technical and/or resource risks. Identifying these
risks early in the process will allow mitigation through reductions in scope or caveats and assumptions
clearly noted in the proposal and contract. This process will also demonstrate to the client a firm
understanding of the complexities of the engagement. The Risk Management Tool should be used by
the person who is responsible for writing the proposal as an initial Risk Assessment mechanism.
Delivery Process – Once an engagement is underway, Risk Identification and Management takes on
two distinct forms.
 Part of the Project Audit/QA process should include periodic risk assessments using the Risk Management Tool that
was also used during the Sales process as described above. This tool allows assessment of threats and risks that
are common to all projects. Conducting this assessment at key milestones/checkpoints throughout the
engagement will allow monitoring of mitigating and contingency plans to ensure their effectiveness and to allow
alternate resolutions to be pursued as appropriate.
 Throughout the engagement, it is the responsibility of senior project leadership to be continually aware of
potential threats to the project’s success. Use of the Risk Log to identify, manage and track all Risks is critical.
Updates on the status of new and previously identified Risks should be part of weekly status reporting and should
be a primary component of Steering Committee discussions.
05/22/14 20

21. RISK MANAGEMENT TOOLS
05/22/14 21
TOOL WHEN USED USED BY COMMENT
Risk Management Tool
(TEMPLATE – Risk
Management Tool.xls)
During proposal process
Project QA’s and Key
Milestone Checkpoints
Sales Lead
Managing Director
Project Manager
PMO Manager
Managing Director
Project Manager
Risks identified during these
reviews should be recorded in the
Risk Log to be tracked and
managed by senior project
management.
Risk Log
(TEMPLATE – Risk Log.xls)
Throughout project Project Manager
Senior project leads
All risks are recorded, tracked and
managed. Internal risks are
reported to @CIOBRODY
management, external risks are
reported on status reports and
discussed at Steering Committee
meetings.

22. ISSUE MANAGEMENT
An Issue is a situation, action, problem, or question arising during the performance of
the project which may or may not be efficiently or effectively resolved. Left un-
resolved, an issue will impede or prohibit project related progress or development by
delaying or suspending work effort. The purpose of issue resolution management is
to ensure issues are identified, logged, and tracked using an established format in
order to facilitate full issue disclosure, timely solutions, minimized project delays, and
minimize budget impacts.
@CIOBRODY has purchased an online Issue Tracking database tool. Issue Traker
allows project team members to record issues. Project management can then assign
responsibility to team members for analysis and manage the resolution process.
The PMO will:
 Maintain the Issue Traker Issue Management Tool and Database
 Assure proper submission and logging of identified issues
 Assure timely assignment of responsibilities for analysis, alternative development, and action planning
 Facilitate daily Issue Log Review Meetings with a “Zero Sum” focus
 Obtain necessary approvals for issue resolution action plans
 Log the approved actions and communicate decisions
 Update project plans and budgets
05/22/14 22

23. ISSUE RESOLUTION PROCESS
05/22/14 23
IssueTrak escalates
issues when
thresholds are missed
Client or team
member identifies
issue
IssueTrak
Issue Document
Assignment
Emails
PM / team lead assess
issue validity and
completes issue form in
Issuetrak
PM/team lead
coordinates analysis
of issue and
alternative
development
• Description
• Issue type
• Priority
• Assignment
• Open Issues
• Un-assigned Issues
• Resolved Issues
• Zero-Sum Focus
Daily Issue Log
PM / team leads
reviews issues log
daily
Escalation Email
to PM
IssueTrak
Issue Resolved,
Added to Project
Plan, Change
Request, or Closed

24. CHANGE REQUEST
MANAGEMENT
On any engagement, management of scope is an important component to the project’s success and to client
satisfaction. On fixed fee engagements, scope control is critical to ensure project profitability. On T&M
engagements, scope control will help ensure an on time, on budget delivery and will avoid potential client
conflicts. While it is not practical to assume a project’s scope will not change over the course of an engagement,
capturing change requests, fully analyzing them to identify potential workarounds and to assess their impact in
terms of costs and timeline changes, as obtaining appropriate client sign-off for any changes is an important
component of project management.
There are two primary components of the Change Request process – the Change Request form which details
individual change requests and a Change Request log which summarizes all requests. The Change Request form
(TEMPLATE – Change Request Form.doc) will be completed once a change to the project scope or agree-upon
requirements has been identified. Changes may result from system or user testing, pilot rollout or from issues
identified as processes and products change.
The person who identifies a potential change should complete a Change Request form, providing a description,
a priority assessment and identifying the impact of not implementing the requested change (workaround).
Once the initial request information has been completed, the project manager should coordinate obtaining the
necessary work level estimates and timeline impacts to assess the change. Based on the work level estimates,
they should provide cost impacts (fees and associated expenses) and review with the client to obtain approval or
to decide to table the change.
The Change Request log should be kept current throughout this process. All open and newly approved change
requests should be presented in the weekly status reports and reviewed in the monthly Steering Committee
meetings.
05/22/14 24

25. CHANGE REQUEST
MANAGEMENT
A Project Change Request is generated to document, track, and control adjustments to scope of work
including the addition or removal of requirements, date changes, resource changes, and budget
changes. The change may or may not impact project schedules or costs. These change requests will
provide a documented trail which will:
 Update revisions to the original definition of expected activities
 Provide information for the assessment of time, resource availability, and cost impact of the
requested change
A Project Change Request will be issued when:
 There may be a delay in obtaining required information or where the delay would impact the
project schedule commitments
 A decision or approval is required which could have a broad impact on business policies, processes,
or procedures
 An issue could impact the scope of work
 Change is the result of the removal of functionality or reduction in project costs
The PMO will ensure that Project Change Requests are fully documented, reviewed, tracked, and that
project impacts are appropriately assessed. The PMO will further ensure that these requests are
approved or rejected in a timely manner.
05/22/14 25

26. CHANGE REQUEST PROCESS
05/22/14 26
Project Admin
updates CR Log
Client (or team
member) identifies
issue
Client (or team
member) identifies
change
IssueTrak
Client (or team member)
determines change is
needed
Change Request
Form
Client (or PM/team lead)
completes Change
Request Form
PM/team lead
coordinates analysis
of request, reviews
with client
• Description
• Priority
• Workarounds
• Solution Alternatives
• Estimate of Effort
• Workplan impact
Change Request
Form
PM provides cost
estimate and obtains
client approval,
updates CR log
Change Request
Log
CR log presented in
weekly status and
monthly Steering
Committee meetings

27. DECISION LOG
A Decision Log is a valuable tool to be used on large, complex projects where client
resources are organizationally or geographically decentralized. It is to be used to help
ensure buy-in and accountability throughout the project team by communicating
decisions which impact the project’s scope or which may cause potential conflict.
Many of the items on the Decision Log will also be documented elsewhere (i.e., test plans,
design documents,etc.), but having a central repository noting significant decisions will
highlight potential conflict areas to ensure full communication and avoid later rework.
All new decisions should be included in the weekly status report and summarized in the
Steering Committee presentation. The Decision Log template and instructions for
completing each field is found in TEMPLATE – Decision Log.xls.
05/22/14 27
# Functional
Area
Description Made
By
Date Approved By Date
Approved
Date
Reported in
Status Mtg.
Impact

28. WEEKLY STATUS REPORTS
As part of the project charter, clients will commit to participating in
weekly status meetings. These meetings should include project
leadership representing @CIOBRODY (PM and Team Leads), vendors (if
appropriate) and the client (key client leads, client PM).
These meetings will ensure the client is continually updated on project
status, project risks, open issues, decisions, scope change requests and
upcoming milestones or project activities. It will also provide project
leadership the opportunity to identify cross-team issues or risks. A
status report will be prepared in advance using the template presented
in TEMPLATE-Weekly Status Report.doc. This pulls in information
from several sources including the workplan, Issues database, Risk Log,
Decision Log and Project Calendar.
During the meeting, minutes should be taken to capture any relevant
discussion or follow-up points. These meeting minutes, along with the
updated status report and supporting documents, should be
redistributed following the meeting.
05/22/14 28

29. MONTHLY STEERING COMMITTEE
MEETINGS
Another component of the project charter will be the establishment of a Steering Committee composed of
senior project leadership (@CIOBRODY, Vendor and Client) and other @CIOBRODY or Client management as
appropriate.
Whereas the weekly status meetings focus on progress to date and open items, the Steering Committee
presentations should generally address open risks, significant issues and scope changes. The format of the
presentations may change, but should include copies of the Risk Logs, Scope Change Logs and Issues Logs (high
priority/impact issues only).
As with the Weekly Status meetings, minutes should be taken during the Steering Committee meetings and
distributed to all participants and Steering Committee members. @CIOBRODY project management should
ensure client participation in these meetings. If clients are not regularly attending the meetings, it should be
documented as a project risk.
While some of the specific agenda items for Steering Committee meetings will vary based on the engagement,
the status of the project and the phase being completed, every Steering Committee should include the
following discussion topics (see TEMPLATE – Steering Committee Presentation.ppt):
 Status Update
 Open and Recently Resolved Risks
 Significant Issues Requiring Senior Management Attention
 Decision Log
 Upcoming milestones
05/22/14 29

30. 05/22/14 30
MEETING AGENDA AND MINUTES
Meeting Agendas will be prepared by the meeting chairperson for all meetings, and distributed to expected
attendees prior to the scheduled time. The agenda should identify items for review and discussion
including who is responsible and expected discussion result, (ie: agreement, decision, direction, or
assignment). Meeting minutes will be recorded by the meeting chairperson or that person’s designee.
Action items and or decisions will be recorded in the IssueTrak data base. Items identified as decisions will
be recorded in the Decision Log. A template and instructions are presented in the TEMPLATE – Meeting
Agenda and Minutes.doc. The template includes:
– Title of Meeting
– Expectations
– Meeting called by
– Date / Time
– Place
– Attendees
– Please Bring
– Agenda Topics, Durations, and Owner
– Special Notes
– Minutes
– Action Items

31. PROJECT QA PROCESS
A Managing Director or other IT Solutions Executive not directly involved in the
project should conduct quarterly Quality Assurance reviews. The object of these
reviews is to ensure the project is being delivered according to @CIOBRODY’s
methodology and standards and that the project is not exposed to significant risk
that could impact its successful completion.
The QA template can be found in TEMPLATE – QA Checklist.xls. The checklist
identifies 53 individual checkpoints addressing items such as:
 Are the Risk and Issues Logs current and are being worked in a timely manner?
 Does the workplan have accurate ETCs?
 Are deliverables in standard format and of good quality?
 Do team members understand their upcoming tasks and responsibilities?
 Is there a test plan?
 Are there sufficient skills on the team?
The individual completing the QA assessment will rate each of the criteria (Good,
Fair, Poor and N/A). The spreadsheet will then calculate a QA score. Once the QA is
completed, the reviewer will work with project leadership (and the client if
appropriate) to develop action plans to address weaknesses identified in the review.
05/22/14 31

32. DOCUMENT NAMING AND
STORAGE
An important component of successful delivery organizations is their knowledge capital. Knowledge capital is
composed of the skills and experiences of individual team members but more importantly, the collective skills
and experience those team members gain within the organization. The ability to use repeatable deliverables
substantially simplifies work effort on subsequent engagements. Therefore, it is important that standard
deliverable formats and hard and soft-copy naming conventions and storage procedures be implemented. This
will allow team members to quickly locate documents and files, promote version control and backup, and will
support other teams who may be engaged in projects with similar characteristics, allowing them to reuse your
deliverables.
• Deliverable Templates – Deliverable template formats will be developed and stored on the shared drive.
Each template will be named with the prefix TEMPLATE – {Template name}.ext. Some templates have
already been created for use, particularly those supporting the PMO; others will be created as a standard
methodology is developed.
• File Naming – All files should be named using the following standard. ISG.{Doc Init}.{Doc Name}v.1.ext:
 ISG – Client Initials
 {Doc Initials} – 2 or 3 letter code indicating then document type. This code is found in the Directory Structure.xls
spreadsheet. Status report = “SR”, Steering Committee presentation = “SC”, etc.
 {Doc Name} – a unique identifier of the document being created. For instance – “Hennepin Sales Order Returns Process
Flow” or “Indiana Harbor Shipping System test Script”.
 v.x – Version. Use v.1, v.2, etc.
 ext – document extension assigned by the application used to create the document (doc, xls, ppt, mpp).
05/22/14 32

33. DOCUMENT NAMING AND
STORAGE
• Header/Footer – In addition to the naming standards, every document should have a standard header and
footer. The header should be formatted in bold font, centered at the top of the page and should include
{Client Name}: {Project Name}
{Document Title}
Subtitle (i.e., Excel tab) if applicable
The footer of every page should be in a small (8 or 10 point) font, and include the following:
{Directory/File Name} Page # Date Created: {mm/dd/yy}
Created By: {Author} Date Modified: {mm/dd/yy}
• Hard Copy retention – at the end of each phase, or whenever a client has signed-off on a document, a
printout should be stored in a deliverables folder. The deliverables should be stored according to the
hierarchy presented in the Directory Structure.xls spreadsheet.
• Original versions of documents which require client sign-off should be forwarded to Pittsburgh. A copy of
any client-signed document should be provided to the client and another retained by the project team.
Documents requiring client sign-off include:
 Contract/Statement of work
 Change requests
 Client satisfaction surveys
 Phase completion/deliverable sign-offs
05/22/14 33

34. DOCUMENT NAMING AND
STORAGE
 Network retention – Every project should have secured file server space for storing project
deliverables. Individual hard drives are not to be used to store any deliverable including work in
process, drafts or final versions, unless the team member is working from a remote location and does
not have access to the server. The server space should be backed up daily, with an offsite backup
made at least weekly. Individual team members should not create their own folders for work in
process or final deliverables. All deliverables should be stored in common folders according to the
hierarchy presented in the Directory Structure.xls spreadsheet.
05/22/14 34

35. CLIENT SATISFACTION PROCESS
The Client Satisfaction Survey process is a key component of @CIOBRODY IT Solutions’
success. Client satisfaction drives the ability to obtain repeat business at existing
clients, to provide additional services such as support agreements and to use clients as
references in obtaining new business. It provides feedback on our consulting skills and
the value we are perceived to provide to clients. It also helps project team members
understand what the client values and expects from us throughout an engagement so
that we can frame our efforts accordingly.
The process is composed of three primary components:
 A Pre-Survey conducted prior to, or shortly after, project kickoff. The Pre-Survey will introduce
the client to the Client Satisfaction survey form and process and will solicit input from the
client. The client will be asked to review the standard satisfaction criteria on our form and to
provide any additional, client-specific criteria that they consider important components of a
successful engagement. The client will also be asked to assign weightings to all the evaluation
criteria. Soliciting this information upfront will allow us to focus our energies accordingly and
to identify any potential issues early on.
 At the completion of each project phase (or at the end of shorter engagements), the client will
be asked to rate us using the standard criteria as well as the additional criteria they may have
added in the first step. They may also provide additional, free-form commentary. If the survey
is being conducted at the end of a phase (vs. end of the project), the client may also change
their assessment criteria and weightings obtained earlier.
 The final step in the review process is logging the results into a spreadsheet which will calculate
an overall client satisfaction index. This will allow for reporting by PM, by client, by line of
business, organization-wide or other criteria.
05/22/14 35

36. CLIENT SATISFACTION SURVEY
FORM
05/22/14 36
Survey Criteria Step 1 – Relative Importance
(Rank 1-Critical to
5-Unimportant
Step 2 – Hudson Score
(1 – Greatly Exceeded
to 5 – Dissatisfied)
Communication Skills
Project Management
Business Understanding
Technical Expertise
Professionalism
Quality of Work
Price/Value
Client Specific Criteria
Where did we greatly exceed your
expectations?
Where did we not exceed your
expectations?
Would you use Hudson Global
Resources IT Solutions for a future
project?
Would you recommend Hudson
Global Resources IT Solutions to
other potential clients?
The Client Satisfaction Survey is very straightforward to ensure client understanding and usage. The table
below summarizes the survey form, which is formatted differently for client distribution and completion.

37. CLIENT SATISFACTION SURVEY
RESULTS
The next slide shows the format of the spreadsheet to be used for entering survey results and
calculating the over Client Satisfaction Survey Score. The PMO Manager or Managing Director
should obtain the survey forms from the client and fill in the yellow-shaded fields with the survey
results.
Additional columns can be added to support extended engagements. This data could also be
extracted into a database for summary reporting by line item/criteria client, by sales person, by
project manager or other criteria as defined by IT Solutions management.
Analysis of the survey results will identify areas where @CIOBRODY may want to focus staff
development efforts or it may highlight areas where individual project manager performance
excels or needs improvement. It may also identify Business Development opportunities.
05/22/14 37

38. EMPLOYEE SATISFACTION
PROCESS
Employee Satisfaction is a key component to being able to attract and retain top talent. Given the
costs to recruit and train resources, keeping existing staff challenged and rewarded can help
manage costs, particularly in an economy where profitability is challenged by shrinking revenue.
Staff turnover rates are also reviewed by stock analysts to assess a company’s stability. High
turnover rates may be an indication of internal issues and may impact the ability to deliver
projects.
The Survey forms should be distributed to all project team members at least quarterly and at the
completion of a project. Employee Satisfaction surveys should be anonymous to allow team
members to be candid in their responses. The PMO Manager or Managing Director responsible
for the engagement (vs. the Project Manager) should be responsible for distributing and collecting
surveys.
The Survey questions and the spreadsheet used to tabulate the results and calculate results are
shown on the following page. The yellow-shaded cells are to be used by the PMO Manager to
enter survey results. Like the Client Satisfaction surveys, summary results may be analyzed by
Managing Director, Director, Manager, Line Item, Client or other criteria to identify areas for
improvement or potential counseling of team leadership.
05/22/14 38

39. @CIOBRODY RESOURCES
IMPLEMENTATION METHODOLOGY
OVERVIEW

40. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 40

41. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 41

42. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 42

43. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 43

44. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 44

45. IMPLEMENTATION METHODOLOGY
OVERVIEW
05/22/14 45