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.

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?

Project Management Office: An Overview

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. 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?

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.

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.

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.

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.

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

The framework could be illustrated using the following diagram :

Project Preparation Phase: How to Get Started?

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

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.

Now, decide the code merge strategy to be followed. The available options are:

• 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.

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:

• 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?

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.

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.

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.

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.

Project Execution Phase: How to Implement the Project?

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.

• 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.

8 Key Parameters Involved in the Execution Phase

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 wellfunctioning 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.

Take a look at the following graphical representation of these parameters for further understanding.

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.

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.

Project Closure Phase: The Final Step

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.

Conclusion

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.