Before traveling or taking a leave of absence, please prepare for the time off by completing the following suggested steps:

1. Give notice in advance to coworkers and managers. Tell them your plan so they can plan to support you as needed. If you plan to leave for more than 2 weeks, please give a heads-up at least one month ahead. 
2. Set up calendar events. The first event can be an "All day" event on a personal calendar, blocking the time with time set to be "Busy." so that others will not invite you to meetings during your absence. The second event can be another "All day" event informing primary contacts of the absence. The event time can be set to "Free" so it doesn't block the calendar time when others accept the invite. The third event can be an "All day" event on an organization calendar for an update to a broader audience. We can set the event time to be "Free." 
3. Delegate the current tasks and the hosted meetings to another person if the leave is longer than two days. If necessary, create a knowledge transfer document to outline the delegation details, including the jobs, meetings, and contacts. Select a project team member to host your meetings and send meeting minutes following the PMO guidelines. 
4. Delegate the approval authority and arrange contacts covering different function areas. 
5. Create an out-of-office auto-email reply. Be careful to avoid setting server-side rules. Instead, use the company-recommended application to prevent duplicate auto-replies. Otherwise, the auto-reply could flood other people's inboxes. 
6. Set your online application status, e.g., update the online status, such as showing out-of-office (OOO) in Slack with the /Status command. 

With these settings, we can ensure everything is handled before our leave. ​​

It's a best practice to guide PMO on what tools to use for project management for project planning, scheduling, content collaboration, and others. The standardized tool section in the team can reduce teamwork frictions. 

The following is an example PMO recommendation: 

• Spreadsheet: Use Quip (New Document embed @ Spreadsheet). For advanced features, use Microsoft Excel.
• Documentation : Use Quip
• Project Management / Planning / Task Tracking: Use Wrike
• Presentation: Use Keynote
• Conference Calls:Use Webex
• Text messages: Use Slack
• Large Files (when you cannot use box eg: recordings, secure files: Use Box
• Bug Fixing / Agile Dev Project : Radar 
• Production Ticketing : Central Station 
• Changes to Production: Corporate change control system

In the guideline, the functionality coverage is described for each tool. This is an evolving list. As new demands or new tools come out, PMO will constantly evaluate the options and recommend best practices. ​​​

​Project manager onboarding establishes the foundations of PMO arrangement. We use "basic five" to refer to the PMO project manager onboarding principles. 

1. Document Template 
Every project manager in PMO is required to be familiar with the PMO documentation templates. The most crucial element of this includes: 

• Review the project summary page to comprehend the project scope, roadmap, significant milestones, project team, stakeholders, and the current project status. A project manager needs to make sure the status is up-to-date. 
• Review the business requirement, design, and test document templates to understand content requirements and manage gate review meetings and sign-offs. 

​2. Processing Workflow 
Processing workflow specifies the steps taken during project execution, especially the gate reviews needed to maintain project management quality and governance. 

3. Meeting Guideline
The meeting is a critical and high-cost method in project execution. We required a session to cover PMO project meeting guidelines. 

4. Tools 
PMO requires all project managers to use tools recommended by the PMO office, including project management (Wrike), content collaboration (Quip/Box), communication (Slack), Agile board (JIRA), and know how these tools are worked together to support projects execution. PMO usually outlines the relationship and role of these tools to ensure proper understanding. Training the trainers is suggested so that their peers can provide mentoring assistance when a new PM joins the team. 

5. Governance 
PMO governance ensures consistent quality across all programs and over time. The requirements could include the following:

• Invite the PMO leader as optional to all your customer meetings, project gate review meetings, weekly project status meeting, and monthly project review meetings. As discussed in the meeting guideline, all these meetings require meeting minutes. The PMO leader reviews quality and assesses project risk by reading the meeting minutes and communications. 
• CC the PMO leader to business communications, escalations, and announcements. The goal is the same, ensuring the PMO leader can clearly backtrack the progress in project execution to assess risk and provide suggestions. 
• PMO reviews with project managers in PMO review meetings to going through weekly management reports and monthly project reviews. The weekly review focuses on status and risk mitigation. The monthly review will request PM to go through the project summary page outlining the project scope, roadmap, major milestone, the current project status, team, stakeholders, project current situation, and risk mitigation. 

In practice, we require every project manager in the PMO to go through this and be able to schedule 30min meeting with PMO leaders to confirm completely understand everything before starting full speed in the management project. 

Role and Responsibility (R & R&R) identifies relationships between functional areas (role) and the person responsible for the function delivery. Roles are also referred to as one's position in a project team. Responsibilities often are defined as duties or job descriptions. 

​Specifying a clear role and responsibility for a project team is a critical PMO practice, which helps teams void stepping on each other, thus reducing conflicts. The following is an example role and responsibility definition: 

• ​​Portfolio Managers manage strategic relationships with businesses with oversight of all projects. 
• Product Managers define and articulate the product roadmap and own product quality and capability.
• Project Managers are responsible for the project delivery. It's vital to clarify project management role is a facilitating role. They don't own the product roadmap or business case nor need to decide what to do in every sprint. They clarify, understand, plan, organize and execute but do not prioritize nor define project scope. 
• Business Analysts liaise with the business to capture, detail, and fulfill business requirements.
• Technical Managers lead the delivery team to deliver a portfolio of products & solutions.
  • Technical Functional Lead (Application Lead): Single point of responsibility for delivery of all technical elements to the stated requirements
  • Technical Lead/Developer: Develops code to agreed standards, quality, and timelines
  • Solution Architect: Defines the end-to-end product architecture and associated integration across different components or technologies
• Operations Managers improve the stability and effectiveness of production environments. Serves needs by ticket, so no one individual is assigned to each project.
  • Operations Engineer: Maintains infrastructure health and provides framework support
• Frameworks Managers are responsible for the roadmap and health of a frameworks and for ensuring that the frameworks is fit-for-purpose 
  • Framework Engineer: Develops and maintains frameworks
  • Framework Project Manager: Responsible for the oversight of development and maintenance of frameworks

It is totally fine for a person to carry multiple roles and responsibilities in practice. Some projects don't need all the functions. The importance of this exercise is the full coverage of the commitments and clarity of each person's expectations in the project.

Standardizing meeting convention demonstrates the PMO's professionalism. The standard defines the type of meetings, their naming convention, and planning recommendations. The following are suggested : 

• (Must Have) ​Project Kick-Off Meeting marks the official start of project execution and PMO engagement. It is a critical project management checkpoint and should be taken seriously. 
• (Must Have) Project Status Meeting is another crucial project meeting besides the project kick-off. The meeting can be scheduled regularly with frequency to be Weekly / Monthly / Bi-Weekly, but weekly is recommended. 
  • Name:  <Project Name> <Frequency> "Status Meeting". 
  • Example: When Project Name is Zeus, the project status meeting name can be Zeus Weekly Status Meeting​
• (Optional) A Project Planning Meeting is required when the project plan needs adjustments and in-depth discussion. The frequency should sync up with the project status meeting. 
• (Optional) Daily Standup Meeting is required when frequent communications are needed within the project team, especially during Agile project execution.
  • Name: ​<Project Name> "Daily Standup" 
  • Example: For Project Name Zeus, the meeting invite subject should be: Zeus Daily Standup
• (Optional) Working Session Meetings are ad-hoc meetings that hold detailed breakout discussions. The meeting needs to be scheduled as soon as the demand is identified. It's recommended to announce these meetings to permit anyone who likes to join the sessions. 
  • Name: <Project Name> <Meeting Title>. The meeting title should reflect the reason for the meeting in short. 
  • Example: For Project Name Zeus,  the meeting name can be Zeus Discussion of PII Dashboard
• (Recommended ) Steering Committee Meeting is required when a leadership update or executive decision is needed during project execution. 
  • Name: <Project Name> "Steering Committee Meeting." 
  • Example: For Project Name Zeus, the meeting name can be: Zeus Steering Committee Meeting
• (Must Have) Project Review Meeting should be scheduled with PMO to assess and mitigate risks and implement project governance. 
  • Name: <Project Name> " Project Review Meeting" 
  • Example: For Project Name Zeus, the meeting name can be: Zeus Project Review Meeting​​

To standardize, PMO needs to give clear instructions, explain the importance, and continuously calibrate project managers' behaviors. ​

The meeting is a required method of getting project work done. The following guideline gives detailed suggestions when booking a project meeting. 

Choose Audience Carefully  Make sure all stakeholders are invited but not invite anyone who would not be able to contribute or make decisions. For stakeholders who only need to be informed, you can add them to the email group to receive the meeting minutes. The goal is to save people's time and ensure good meeting attendance. A viable test is to check if all invited attendees accept the meeting invitation with active participation. If not, reconsider your invitation plan. 

Book the Calendar Timely In general, we should book a meeting on the Calendar at lest one week beforethe meeting starts. If the session lasts more than 1 day, it is recommended to block the Calendar several weeks ahead. ​

Send Invitation with Details  Invitation should provide essential information related to the session, which generally includes: 

• Subject : <Project Name> <Meeting Name>
• Location - Conf room / Webex 
• Agenda - Discussion topics and objectives 
• Link to Project Information (or meeting background information if needed)
  • Project summary page (Quip / Wrike link)
  • Project email group
  • Slack channel​

It's essential to remember meetings are a high-cost activity. A productive meeting leads to concrete results like facilitating collaboration or decision-making. If we don't plan it well, we may have too many meetings, invite too many people who don't show up, who don't speak up, or many are multi-tasking during the session. We would also want to avoid meeting discussions that lead to no decisions, action, or consensus within the team.  ​

Reference 

1. Tammy Adams, Janet A. Means, Michael Spivey, The Project Meeting Facilitator: Facilitation Skills to Make the Most of Project Meetings, By  October, 2007

Project managers record the meeting to track conversation details, allow people who miss the session to catch up later or keep a historical record of the project decisions. Some PMs also use the recording to aid the creation of meeting minutes when you can't engage in discussion while keeping notes. 

It seems like recording the meeting can only help, but it is not. Putting the recording can make people feel formal and hesitate to raise questions or comments without preparation. Therefore, brainstorm sessions usually are not suitable for recording. You might also skip recording for team sync up because recording makes people feel judged. 

The recording meeting should not be too long because people generally are not good at watching lengthy videos. Therefore, the agenda and content of a recorded meeting need to be more prepared. 
The essence of the decision is empathy for meeting your participants and knowing what you need to achieve in the meeting. 

For meeting ethnic, you would need to announce your recording before it starts. If you need to record the session for meeting minute creation, you don't have to disclose it. You may record the session privately and delete the recording after you finish the minute creation. ​

When we establish a new PMO or change the existing PMO practices, we can follow an assessment process described as follows: 

• Workflow optimization typically takes six weeks, starting from understanding each process's business processes and workflows. For each process, we need to know what the business uses, the steps, who are involved in each step, and the relationship between the steps.
• New process setup typically takes 8~12 months to implement if there is limited executive engagement. The process setup requires stakeholders to review and propose the new process for buy-ins short proof of concept project to test the new approach and collect feedback. Then, we followed the implementation of the process with details guidelines and support. 
• Project flow restructuring: After we set up the business process, the project management needs a deep dive that takes 12 months, which is the destructing based on industry best practices, which typically fall into Agile, Waterfall, or something missing both. 
• People change: this is a challenging part that usually takes 12 months. We must understand each team member's and stakeholders' perspective, expectations, and working style. The goal is to make sure their voice gets heard, engage their participation, and accommodate their needs for long-term support. 

1. New sdtarndard adoption. Typically takes 12 months to gain momentum. The process requires early engagement for input, creating standards, and review with the team, starting with initial adoption and collecting feedback. The bar should be introduced in steps to avoid dramatic changes in the process and sudden void increases in the overheads. 

These are the PMO setup and change management that we have experienced. We hope this is helpful to you. ​

Project managers (PM) are directly accountable for the success or failure of the projects. They heavily rely on the team to take ownership of tasks for the project execution. 
​
The following is an example summary of what they do and don't do. 
Do 

• Create and manage projects plan: PMs create the project plan, including task breakdowns, timelines, and assignments. PMs use it to control and follow-up during the plan execution. 
• Manage risks: PMs create and execute risk management plans by collecting risks and mitigating the risks. PMs don't have to identify all the risks. Instead, all project team members should contribute.
• Lead project communication: PM is a liaison overseeing stakeholder engagement and communications.

Don't

• ​Follow up for technical approvals: Developers take the ownership to follow-up approval for environment setup requests or security reviews. 
• Host technical breakout discussion: Development leads are responsible for hosting technical meetings and reporting to PM. 

Clarifying with the team on what PMO do and don't do helps avoid conflicts and ensures PMs can stay focused on executing the project plan. ​​

PMO Governance is a management structure for entry, tracking, reporting, and loopback for all projects/programs and teams managed by PMO. 

The fundament list of checks includes 

• Project lifecycle, delivery process, and documentation 
• Project communication 
• Project management tools and techniques 
• Project team resource on-boarding and off-boarding regulation 
• Project report and KPIs
• Project manager training 

A PMO Governance Framework ensures the PMO office establishes the standard guidelines and manages authority distribution during practice.