The Definitive Guide to an Effective PMO (Project Management Office) Process

The Definitive Guide to an Effective PMO Process 1
©RapidValue Solutions
A Whitepaper by RapidValue Solutions
THE DEFINITIVE GUIDE TO AN EFFECTIVE
PMO (PROJECT MANAGEMENT OFFICE) PROCESS
- Achieving Software Delivery Excellence

Index
03 Project Management Office: An Overview
08
11
13
Project Preparation Phase: How to Get Started?
Project Initiation Phase: How to Take the Next Step?
Project Execution Phase: How to Implement the Project?
01 Introduction
12
13
15
Choosing the Right Tool for CI/ CD Process
Managing Environment Configuration and Enabling Rollback Effectively
8 Key Parameters Involved in the Execution
17 Project Closure Phase: The Final Step

Introduction
If you have been observing the global IT outsourcing landscape for some time, you would know by now that
it is ever-changing. OPD(Outsourced Product Development) is a term that has been making rounds for some
time in the current IT scenario. For the unversed, OPD is defined as the process wherein an organization
hires a third-party provider and outsources specific activities pertaining to the development of products and
services. While cost reduction continues to be one of the top reasons for outsourcing the product engineering
work, the relationship between a client and a product development partner is becoming more and more
people and process-driven.
Have you ever wondered how certain businesses achieve stellar delivery excellence? The pivotal reason
behind this could be pinned down upon the foolproof and effective PMO (Project Management Office) and
Governance Process employed by the business.
However, achieving this is no cakewalk and it comes with its own set of challenges.
A common challenge CTO/CIOs or founders of product startups face when they outsource their product
development initiative is tracking the performance of developers. Since you cannot really monitor the
productivity of the outsourced team on a full-time basis, it is critical to know whether your investment in
hiring a dedicated team of developers is justified. Moreover, product development activities today require
companies to juggle various dimensions. Companies must ensure they are making the right use of limited
resources, allocating people, time, and money to the projects that will best meet their short and long-term
strategic goals.
That raises a crucial question: how should they measure the performance of their product development
teams? Project metrics help you gain quantitative insights into your team’s performance and provide goals
for your team that can be more easily measured. They also enable software teams to monitor productivity
across workflow stages, access software quality, while introducing more clarity to the development process.

In this fast-paced delivery era, project quality management is pivotal in designing processes that completely
satisfy the need for which the project is undertaken. It is important to measure what we are managing, and
hence quality metrics are important to know the current health of the project. However, it is not just the
metrics that help achieve software delivery excellence.
A very integral part of software delivery is undoubtedly the PMO process, and in order to streamline the PMO
process, there are certain existing key practices. An efficient PMO process could help the organization to gain
the utmost control and value of the project by adopting a strategic and tactical approach. What are the key
practices that should be adopted to achieve a successful and efficient PMO process? You may ask!
In this whitepaper, we will walk you through the various aspects of the PMO process and also, based on our
experience, we have put together a list of best practices to be followed to streamline your PMO process.
Some of the other questions that the Engineering Head of a product startup needs to ponder over before
considering outsourced product development are:
• Is my in-house team more productive than the team I’m outsourcing to? Am I paying just for time or
results? How do I ensure the quality of deliverables is up-to mark?
• Are there any project metrics that my OPD partner measures and tracks?
• Does the OPD company have the right project governance framework?
• What would be the right set of project metrics to measure?

Before we discuss the topic of a Project Management Office any further, it is essential to understand the team
structure of the OPD team. Given below is an image depicting the team structure for an easier understanding
of the process.
Project Governance plays an important role in these times when stakeholders are on the lookout for
innovative solutions within a minimal time frame. If businesses increase the speed of the process without
data-driven decision making, it could end up being a failure. Thus, it becomes imperative to share the project
data with the stakeholders to satisfy their curiosity and also improve customer satisfaction. The data takes
into account various aspects like the quality of the project, the timeline, and the utilization of the budget. The
PMO will initiate effective project management and help provide a guideline by taking into consideration all
such parameters that drive customer satisfaction. The project management office will provide dashboard
data that could help with the decision making process. Also, it helps organizations to adhere to the business
objectives while maximizing value from the investments.
Project Management Office: An Overview
Engagement Model
Engagement
Model
Steering
Committee
Project Management
Office
Project Delivery Team
Scrum team 2
Scrum team 1
Sr. Mgmt., Program
Manager
Tech Lead
Scrum team …n
Scrum
Master 1
Scrum
Master 2
Scrum
Master n
Program Sponsor IT ManagersBusiness Leads
Senior Management
Engagement
Director
Onshore
Client
OPD
Partner
Offshore
A Project Management Office is the silver bullet for CEO/CXOs focusing on gaining maximum value from
their projects. Simply defined, the project management office is a department within the organization that
is responsible for maintaining the standards of project management within the organization and ensuring
follow-through to improve productivity and quality. How do they add value to your business?

PMO Challenges: It could be agreed upon that project management is not a walk in the park. If one does
not proceed cautiously, teams could face certain challenges during their project management journey. It is
crucial to anticipate these challenges and stay prepared for them to avoid project failure. Here is a list of key
challenges that the team could face during the project.
01
02
03
04
05
06
07
08
Inefficient change management strategy
Limited clarity of available resources
Lack of visibility into the project’s performance
Ineffective risk management
Poorly defined milestones
Unrealistic and aggressive deadlines
Remote project management concerns
Lack of accountability and teamwork

Project Metrics is the next most important topic that falls under effective project management.
A project team is predicted to yield better results when the project metrics are balanced. An
organization could receive both positive and negative data from these metrics. While positive data
helps recognize and reward accomplishments, negative data help organizations to monitor and
continuously improve the project. What are the factors that determine strong development
metrics?
• It is used by the team: A successful metric is the one that is used voluntarily by the team to
learn and improve without it being imposed or measured by the management.
• It forms a part of a specific experiment: A strong metric is not just measured for a namesake
and is used to solve a particular question about the processes.
• It is surrounded by conversation: Metrics should instigate constructive conversations
surrounding the processes and obstructions that affect the team.
• It is easy to calculate and understand: The phrase ‘Simple is the best’ proves to be true in this
case. Metrics that provide valuable insight but are very complex cannot be used by the team
for guidance.
• It is used along other metrics: As we had discussed earlier, project metrics need to be
balanced. If a single metric that provides great insights is used, the teams would be inclined to
maximize its use at the expense of all else. Thus it is preferred to use several metrics together
for a balanced picture.

Now having discussed various aspects of the project management office, let us discuss its workflow
The workflow of the PMO is divided into four different phases:
Once the team identifies the strong development metrics, the next step should be that of
measurement and reporting of the metrics. Take a look at the metrics measurement and reporting
plan that could be used by the product development team.
• Project Preparation
• Project Initiation
• Project Execution
• Project Closure
Daily
Daily Scrum
Updates
End of Sprint
Story points –Planned vs.
Completed
Sprint Review/Demo
Sprint Retrospective –
Good factors and
improvement factors
Monthly
- time
• Resource Utilization
• SLA Adherence
• Application Up
Program
Level
• Transition/training effectiveness
• % meeting SLA
• Stability of application
• Resolution time
• Productivity
Project
Level
Key Enablers for Incremental Value
• Establish Knowledge Repository
• Implement strong delivery framework and QA Processes
• Process Standardisation
• Root Cause Analysis of defects
• Standard support tools
• Performance tuning and Code restructuring
• Optimal Onsite - Offshore Ratio
• Optimising FTE count
• Process Convergence
• Complete internalisation of processes
• Multi - skilling of FTE – improved efﬁciencies
• Budget control and Application portfolio management
• Location consolidation
• Technology rationalisation
Delivery
Team 1
Delivery
Team 2
Delivery
Team 3
Delivery
Team n

The framework could be illustrated using the following diagram :
Templates
Resource Request
Internal Kick off
Project Charter
Client Kick off
Templates
WBS Forms
Dependencies and R&R
Communication Plan
Schedule
Project Plan
Change Mngnt Plan
Templates
Project Timesheet
BW Status Report
Meeting Minutes
Issue Log
Change Request
Project Plan
Templates
Project Status Reports
Customer Status Report
QA and Phase Milestone
Escalation Path for issues
Templates
Cust Sat Form
Team Evaluation
Closure Report
Project
Initiation
Project
Planning
Project Execution
( Monitoring / Controlling+ Reporting )
Project
Closing
Project
Monitoring /
Controlling
Project
Reporting

Setting Up and Sharing of Coding Standards: Next, share the coding standards document with
the team. This document should include points to be considered to make the application Safe,
Secure, Reliable, Testable, Maintainable, and Portable. Ensure that the coding standards and best
practices are discussed and explained to all the members of the team. Also, decide the code review
strategy to be followed – frequency of peer code review, frequency of external code review, and
reviewer.
Deciding Code Branching and Code Merge Strategy: Having done that, move forward to decide the code
branching to be followed. The branching strategy could be either one of the following:
• Release branching - This is most commonly used in the waterfall model.
• Feature branching - This reduces the time of delivery and testing cycles.
• Task/Story branching- This is ideal for organizations with a mature agile development process.
Once the team receives confirmation from the customer on starting the project, they should start
gearing up for project execution. During this phase, the team decides on the project methodology,
the sprint duration, coding standards, etc. What are the various aspects that need to be considered
while making such decisions? Let us discuss:
Choosing a Project Methodology (Agile/Waterfall): The first step should be to decide on the
project methodology for execution.
• Agile is considered in scenarios where the client is uncertain about the requirements, and
when the timelines are short and the client requires rapid delivery.
• The waterfall model works better in cases where there are complex dependencies. In case the
team has chosen Agile, agree upon the sprint duration with the customer (recommended
duration is two weeks). During this time, identify the technical expectation gap of the resources
and arrange/plan for training/certifications if needed. Also, prepare the resources for customer
interviews, if any.
Project Preparation Phase: How to Get Started?

Drafting the Code Review Checklist: The next step should be to share the code review checklist
to be used in the project. While drafting the checklist, consider questions like:
Tailor the organizational template for Project Plan, Risk Management, Scope and Change
Management, Business Requirements Document, Code Review Analysis, Bug Analysis,
Traceability, Unit Testing, Test Plan, Test Case, Weekly Status Report, and Design and
Architecture Documents.
• Does this code do what it is supposed to do?
• Can this solution be simplified?
• Is this code at the right abstraction level and modular enough?
• Is the code easy to understand?
• Any unwanted API or external calls?
• Does similar functionality already exist in the codebase? If so, why isn’t that functionality
reused?
• Are there any best practices, design patterns, or language - specific patterns that could
improve this code?
• Any use case in which the code does not behave as intended?
• Any inputs or external events that could break the code?
• Are error messages shown to users are user-friendly?
• Are there enough log events? Are they written in a way that helps easy debugging?
• Is authorization and authentication handled in the correct way?
• Is sensitive data securely encrypted and stored?
• Is there any way to improve the performance of the code?
• Manual Code Review and Merge - This is the simplest of merging strategies, wherein
each branch is manually code reviewed and tested before being merged into the
master branch.
• Minimal Continuous Integration - Used most commonly in small development
projects, this strategy involves using a build orchestration tool, like Jenkins, to compile
and test the source code.
• Continuous Integration Pipeline with Quality Gates - Based on the stage-gate
system, this strategy involves the use of tests or gates to validate each and every step
in the overall process.
Now, decide the code merge strategy to be followed. The available options are:

Finally, identify license and certificate requirements of any tools to be used in the project.
Document all decisions and processes to create an onboarding document to ease the onboarding
of team members. List a few static code analysis tools that can be used and procure the leave
plans from the team members so that those can be considered during the project planning.
Other points to keep in mind:
• Do Proof of Concept (PoC) for identified technical unknowns and challenges in the project.
• Assumptions being made for the solution need to be properly communicated.
• Identify the dependencies with respect to third party integration, tools to be used, etc.
• Risk and associated mitigations should be clearly documented.
Creating the RACI Matrix: RACI Matrix could be defined as a responsibility assignment chart
that describes every task/milestone of the project along with the participation by various roles in
completing them. Communicate the RACI Matrix to the team members and relevant stakeholders.
Let us take a look at a sample RACI Matrix.
Internal Kick Off
Project RACI & Escalation Matrix
MVP Requirement/Product Backlog*
High Level requirement sizing & project
re-estimation
Project/Release Planning*
Freeze tools and templates to be used
Establishing environments & source code
branding strategies
Establishing governance & reporting formats
Change and Risk Management sign off from
customer
HLD/LLD
User Story Grooming*
Sprint Planning*
Dev (Unit testing & review)
QA Sign Off
Implement change management process
Sprint Burndown Report*
Risk Mitigation Report
POC Findings
Release Burndown*
I
C
C
C
R
R
I
I
C
I
R
C
C
I
C
C
C
RA
C
I
I
C
I
C
I
I
RA
RA
A
RA
RA
RA
A
A
A
I
A
I
I
A
A
A
A
A
C
I
C
C
R
I
RA
C
C
R
I
I
I
I
I
C
A
R
R
C
R
I
I
C
I
C
C
R
RA
R
R
R
R
C
R
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Project Roles
Name
<insert
name
here>
<insert
name
here>
<insert
name
here>
<insert
name
here>
<insert
name
here>
<insert
name
here>
<insert
name
here>
Account
Manager
Product
owner/
Business
Analyst
Team
Lead/
Team
Process
POC
Project
Manager
QA
Lead
SME/
Tech.
Arch
* To be done only in JIRA
* Responsible, Accountable, Consulted , Informed.

Project Initiation Phase: How to Take the Next Step?
Once the team is done with the planning and preparation, they should move to the initiation phase. Before
that, a project kick-off meeting should be held to align the expectations of the customer and the delivery
team. Clear and regular communication and collaboration are required for this to happen, and that could be
achieved by following the below-mentioned steps.
Efficient and Regular Communication: Agree upon the weekly status review call format and schedule to
discuss high-level stories completed in the previous week, stories planned for the next week, discussion
on risks and open items, holiday, and leave information for next week, etc. Also, agree upon the monthly
governance call format and schedule. Project progress and timelines, cost burndown, open items and
risks, other sprint metrics, feedback, etc can be discussed here. Decide a common platform for the team to
communicate the daily progress, issues, clarifications with customers, and other vendor teams if any. Also,
discuss the escalation plan.
Effective communication lays the groundwork for efficient project governance and management. A report
by the Project Management Institute showed that companies with effective communication enjoyed a
rate of 80% of projects successfully meeting their goals. However, the success rate of those with minimal
communication was only 52%. In addition to the regular status calls, monthly/quarterly governance calls
can be implemented to streamline project management. The existence of an appropriate project structure
is important for the team to make decisions, exchange information, and identify and mitigate risks. Also,
consistent communication between the decision makers, managers, engineers, and business owners ensures
that the development and delivery are very much aligned with the business goals. This is very critical for the
overall program to be successful. Thus, it becomes important to draft a communication plan to facilitate the
same. The recommended plan for communication is as below.

Selecting Project Management Tool: Some tools which can be considered are Trello, Azure DevOps, Jira,
Asana, etc. Also, decide the code repository tools to be used. Some tools which can be considered are GitHub,
BitBucket, and Assembla. Get information on the process to be followed to get access to the customer
network and tools used in the project. Move on to discuss the license & certification requirements of tools to
be used in the project.
Also, schedule a meeting with the technical team of the customer to discuss the expectations on the project-
specific coding standards, code review checklist and check-in process, static code analysis tools to be used,
setting up of the CI/CD process, etc.
Action
Daily Stand-up Meeting
Release Planning
Sprint Planning
Sprint Demo
Sprint Retrospective
Weekly Status
Report
Monthly
Governance call
Review Daily Project
Status
Plan project release
and high level backlog
defined at sprint level
Planned approach and
defined tasks for each
sprint
Show workable demo
from each Sprint
Improve efficiency and
remove impediments
Project Status
Project Status
Every day, 15
mins
In the beginning
of project
Before starting
each Sprint
Completion of
each Sprint
Completion of
each Sprint
Weekly
Monthly
Scrum tool (Jira), used to
track tasks and burn-down
charts
Project management tool
Project management tool
Video/Audio conference
Video/Audio conference
1. A status reports via e-mail
to Client’s POC on activities
planned for the week, status
of
past ones, impediments.
2. Video/Audio conference
1. Status reports via e-mail
to Client’s POC on KPIs and
Sprint parameters, Risks,
Open items.
2. Video/Audio Conference
3. Account planning and
Feedback
Development Team,
Product Owner and Client
Development team,
Development team,
Development team,
Product Owner and
Client
Development team,
Product Owner and
Client
Development team,
Product Owner and
Client
All key stakeholders
Objective
Achieved
People
Involved
Communication
Mechanism
When

Now that the stage has been set for action, the team should be ready for the execution phase. The steps
that need to be taken care of during this phase are:
Implement Management Processes: Prepare a detailed BRD(Business Requirement Document) or
user stories or use cases and UX screens for the confirmed requirements/flow/screens. Also, mention
all nonfunctional requirements in the acceptance criteria for each user story. Consider the browser
compatibility, device compatibility, performance, security, data volume, usability, validations aspects in user
stories. The technical team should start with the architecture and high-level design documents. Once the
user stories are approved, do the estimations and ensure that it is on par with the estimations given in the
proposal. If there is a difference in estimations, keep the management and customer informed and action
items identified.
During each of the development phases
• The dev team should complete the UT of the completed module before releasing it to QA. Also, the
code review of the completed features should be completed and the code review comments have to
be fixed before releasing to QA. Track the effort for each user story on a regular basis during the daily
standups and also update the risk management document.
• Traceability matrix should be updated to track the requirement from BRD through UT, code review, test
case, test case execution status, and defects for each user story.
Project Execution Phase: How to Implement the Project?
Business Req
User Story
Ticket
Number
Execution
Status
Pass / Fail
Summary Primary Test Case
ID
Defect
Ids
Total
Actual
Efforts(hrs)
Total
Estimated
Efforts(hrs)
UTC
Review
Done?
Design
Review
Done?
Code
Review
Done?
Code
Review
Comments
Testing Coding

• Update the design and architecture documents and plan the performance and security testing. UI
responsiveness testing, testing in different browsers and devices should also be planned. Also, identify
unwanted API / cloud function calls and track the certificate/license requirement.
• Sprint review / demo should be done with the customer and all action items have to be captured in
the management tool. Discuss with the customer if the comments from the demo are out of scope
and raise CR if they need those changes.
• Perform an analysis of code review and bugs identified in the sprint, categorize them based on
severity and owner, identify the root cause, and define action items to reduce them in each sprint.

During each sprint, there are specific parameters to be measured and action items to be taken to improve
them. The parameters are as listed below:
• Say-Do Ratio: Ideally your say-do ratio should be 1:1, which means that you have done everything that
you said you would do. More than 85% of completion in each sprint is acceptable.
• Code Review Comments Analysis: Categorize the code review comments raised in the sprint
(especially medium and above severity) and take action to reduce them. For example, if ‘Logical Errors’
are identified more during the review, UT should be improved.
• Bugs Analysis: Categorize the bugs raised in the sprint (especially medium and above severity) and
take action to reduce them. For example, if “Functional” bugs are more in a sprint, improve the user
story grooming and documentation of user stories to also include the boundary scenarios. Developers
should ideally include UT for these cases so that it is tested in the future.
• Static Code Analysis Issues: Make the team aware of the rules configured and ensure that they follow
those.
• Effort Variance of User Stories: (Actual Effort – Planned Effort)/ Planned Effort x 100 should ideally be
0. If there is a difference, refine the estimation process to minimize the variance.
• UT Coverage and Velocity of Team: A UT coverage of 86-90% is considered to be good and a well-
functioning scrum team's velocity should steadily trend upward by roughly 10% for each sprint.
• Capacity Utilization and Budget Burndown: Capacity Utilization should be more than 80% for each
resource in each sprint and budget burndown should match with the planned burn down.
• Customer Identified Bugs in Sprint Builds: This should ideally be 0. If there are any, make sure that
those are included in the test case by QA so that it will be included in the regression testing in the
upcoming sprints.
8 Key Parameters Involved in the Execution Phase

Other important aspects to keep in mind during this phase include:
• Start discussing the QA, UAT, Production setup at least a month before the expected release dates to
these environments.
• Make sure the UAT environment is ready at least 2 sprints before the UAT release.
• Ensure that the Prod environment is ready at least a sprint before the production release.
• Plan for data migration if required, at least 2 sprints before the UAT and production release.
• Plan to prepare necessary documentation (deployment, user manual, KT documents) at least a
sprint before the production release.
Take a look at the following graphical representation of these parameters for further understanding.
During the UAT phase,
• Track all changes/bugs coming from the customer and categorize them and raise CR if required.
• Prepare RCA for the bugs raised and ensure the UAT sign off is received.

During this phase, the team should have completed the project and should receive the project closure email from the
customer. It is important to prepare all the necessary documents and keep them ready during this phase. However,
before the closure of the project, there is an important step that has to be followed named the ‘Project Review.’
Project Review is defined as a formal review of the different aspects of the project performance. Performed after the
project completion, the internal review is usually executed internally, but can also be carried out by an external consultant.
The recommended frequency for the project review is at the end of each sprint for a project. When considering the type
of reviewer, it is best to have a combination of practitioners with an understanding of metrics, as opposed to pure metrics.
This is to ensure that there is an operational view as opposed to a pure metric view. The internal review would reaffirm the
project commitment of the team by reminding them that quality and project management performance are key focus
areas that should be given due attention.
Project Closure Phase: The Final Step

The main motive of a project management office is to ensure that the organization delivers IT projects on budget, on
time, and on scope. Research by Gartner states that 68% of stakeholders consider their PMOs to be bureaucratic, and
only 40% of projects meet their schedule, budget, and quality goals. This is why it is important to identify the best PMO
practices and implement them for effective management and to achieve strategic goals.
The above-mentioned processes, best practices, and quality metrics are derived from project execution experience.
Based on the nature of the project and customer expectations, the above processes can be modified to ensure on-time
delivery with high quality. That said, it is important to understand that these processes will continue to modify and evolve
as new project methodologies are adopted.
Conclusion
Author
Lekshmi Suseela
Senior Manager- Project
Management Office
RapidValue
Amritha Nampalat
Marketing Executive
RapidValue
If you’d like to know more about implementing an effective PMO Process, please reach out to us
at contactus@rapidvaluesolutions.com

Disclaimer:
This document contains information that is confidential and proprietary to RapidValue Solutions Inc. No part of it may be used,
circulated, quoted, or reproduced for distribution outside RapidValue. If you are not the intended recipient of this report, you are
hereby notified that the use, circulation, quoting, or reproducing of this report is strictly prohibited and may be unlawful.
RapidValue is a global leader in digital product engineering, including mobility,
omni-channel,IoT,AI,RPAandcloudservicestoenterprisesworldwide.RapidValue
offers its digital services to the world’s top brands, Fortune 1000 companies and
innovative emerging start-ups. With offices in the United States, the United
Kingdom, Germany and India and operations spread across the Middle-East,
Europe and Canada, RapidValue delivers enterprise services and solutions across
various industry verticals.
www.rapidvaluesolutions.com
+1 877.643.1850
www.rapidvaluesolutions.com/blog
contactus@rapidvaluesolutions.com
September, 2020©RapidValue Solutions

The Definitive Guide to an Effective PMO (Project Management Office) Process

Recommended

Recommended

More Related Content

More from RapidValue

More from RapidValue (20)

Recently uploaded

Recently uploaded (20)

The Definitive Guide to an Effective PMO (Project Management Office) Process