A team leader can establish a routine for seeking advance advice from team members. This could be done through an email or a brief message asking for suggestions on improving teamwork.

The quality of the advice will depend mainly on having a team with diverse backgrounds. After gathering these suggestions, bring the topics to a team discussion to inspire new ideas. As a project manager, engaging everyone to unlock their potential and cultivate a sense of ownership is important. Additionally, it's helpful to break down problems into manageable parts and organize discussions to stay focused on the topics at hand.

A crucial part of this process is keeping notes and ensuring that all feedback is acted upon or addressed. If feedback is taken seriously, team members may be able to participate in future discussions.

Sprint planning meeting creates a plan for Sprint in agile project management with engagement from product owners, scrum masters, and the development team. PMO suggests that the scrum master take ownership of the sprint planning meeting and follow the guidelines to run the Sprint planning. 

Before the Spring Planning Meeting

• Schedule a 1-hr session before the Sprint starts.
• Make the request in email for the team to get ready for the sprint planning meeting with (1) product owner providing the list of to-dos for the next Sprint, (2) all the team members logging all the tasks they are working on or planning to do with the up-to-date status, (3) dev manager assigning all the tasks to the dedicated team member. The goal is for the team to have a clear scope and prioritization and effectively estimate the workload during sprint planning. 

During the Sprint Planning Meeting

• Start from the big picture by confirming all preparations are complete, including tasks in the current sprints, tasks in the plan, and the backlog. 
• Confirm the Sprint objectives by going through the tasks requested by the product owner. The team understands the requirements and thoroughly reviews the tasks with the scope, impacts, and dependencies. 
• Go through the current task and plan for work for each team member. 
• Review the tasks per Epic to make sure the sprint objectives are met. 

After the Sprint Planning Meeting

• Send meeting minutes with a report of the tasks assigned and the decisions made.

After the Sprint planning, all new requests must go through the change control process. This helps The project team stay focused on the planned tasks. 

The project scope refers to a detailed list of deliverables or features associated with a project. It's essential to clearly define the project scope before starting any project. A well-articulated scope description helps effectively manage stakeholder expectations. To clearly outline what is included in the project and what is not, we recommend dividing the description into two sections:

• The Scope outlines the list of deliverables.
• Out of Scope refers to the areas not included in the project.

The key is not taking things for granted. If there is an assumption or any constraints, you will also record them in your scope statement. Never assume people would know. Follow the change control process if any scope changes occur after the project kick-off. Scope change, or Scope creep, impacts the project plan, but it might not be as bad as it might be because of customers' increasing demands. Be clear of the Scope, but be ready to handle the changes. 

​

People say that you don't take ownership of your project because you lack a proactive plan of action. The key difference lies in whether you are focused on managing day-to-day operations or if you have a clear future vision and understand what needs to be accomplished.

To address this issue, consider creating a to-do list at the beginning of each week. This list can help you assess whether your tasks are reactive or proactive.

Metrics like Key Performance Indicators (KPIs) provide valuable insights into PMO performance, which helps the project team strive for high achievements. PMO suggests portfolio managers and project managers follow the guide to define KPIs. 

• Choose Realistic Yet Stretching Goals. The goals should be stretching but SMART-Specific, Measurable, Achievable, Relevant, and Time-Bound. 
• Limit KPIs. We recommend tracking only a few KPIs, like 3 KPIs, to keep the team stays focused at a time. The ideal KPIs should be measurable in real-time to adjust project team actions. 
• Keep Cycle Short. We recommend a 6-weekly cycle (42 days) for quick loopback, starting from a goal-setting session and ending with a reflection to celebrate the achievement and discuss the lesson learned. 

PMO suggests the following Portfolio KPI examples: 

• Project Management
  • 100% Project Documentation Standardization
  • 90% of stakeholders give feedback
  • Keep <5 overdue tasks at all time 
  • 9 out of 10 satisfaction from 90% of stakeholders 
  • 95% status meeting attendance rate with 100% participation
  • 90% green status for all projects 
• Operation Efficiency 
  • 98% utilization in the current forecasted budget
• Resource management
  • 100% resources allocated to project tasks
  • 0% resources under-allocated + over-allocated with tasks
  • 100% skillset coverage cover > 1 year portfolio forecast 
  • Reduce per person cost by 10% 
  • Keep resource churn rate < 10% per quarter. 
  • Keep average resource industry experience > 5 years. 
• Customer Satisfaction/Loyalty (How do customers see us?) 
  • > 4/5 customer satisfaction score 
  • >4/5 customer net promoter score 
• ​Execution Focus (What must we excel at?) 
  • If key resources are focused on strategic projects
• Strategic Growth/Innovation (How can we continue improving and creating value?) 
  • >20% future-looking project

After setting up the KPIs, the project manager and portfolio manager need to guide and assist the project team in achieving better results.

The project charter page is one of the" Big Three" project documents, along with the project plan and requirement document. It serves as the source of truth, summarizing the project's key artifacts and answering the questions of the project's why, what, how, and when questions.  As part of PMO best practices, we would create a project chart page from day one and keep it updated at all times during project operation.  

The content includes the project scope, benefits, timeline, team, stakeholders, and risks. The following is the best practice for creating and maintaining a project chapter page:  

• All summary pages are owned and reviewed by the portfolio manager before publishing. 
• A consistent project name is needed across all project pages/documentation. 
• Clear project scope should include in-scope, out-of-scope, and assumptions.
• All the resources need a % allocation, and the assignment should be updated as required every week. 
• All stakeholders need to be added, and we need to confirm that the user has access to the document. We would require all stakeholders to access the project summary page unless exception approval is given.
• All major project milestones need to be listed and tracked with "Not Started," "Completed," or "In Progress." '
• For the communication plan, please include the answers to the following questions: 
  • How often will you update the external stakeholders, project owners, and team members?
  • Who receives the report?
  • Who needs to be aware and informed about the project?
  • Which tool is to be used for the distribution of the message?
  • Where is project information stored?
  • Add risk and assumptions.
• ​RAID in project management stands for risks, assumptions, issues, and dependencies. ​

The best practice requires creating a project charter before project planning and the kick-off meeting, which is shared with all stakeholders. Reviewing the page regularly (at least weekly) is essential to ensure all the information is up-to-date and accurate. ​  

Wrike is a project management tool used in our PMO to drive process governance, display progress, manage the team's workload, and guide workflow operations. Let's discuss the best practices for using it.

Before creating the project, we need some preparation as follows: 
1. Create a project folder in Quip using the PMO template.
2. Create the project summary page by collecting the following information:

• Gather requirements from stakeholders. If the project is related to an initiative or product, translate the requirements to OKR and product features.
• Define the scope of the project.
• Define the success criteria.

3. Create the Project Onboarding document and review the project execution plan with the PMO leader.
4. Create the project plan in Wrike:

• Create a new workspace and a new project.
• Add the Work Breakdown Structure.
• Define Project Activities - What activities must be performed to create the project deliverables?
• Estimate the timelines or plan backward to deliver at a given timeline.
• Assign resources to the Project activities.
• Add Tasks: Per project standardization, placeholders should be created for all the significant tasks in the D2P process (refer to the D2P blueprint). Please don't add new tasks only for risks or special occasions because we use the task turndown rate to track project delivery progress.

5. Review your plan before publishing and consult significant changes with the PMO Leader for review.
6. If you plan to run the project in Agile (or using the Agile tool where the ticket system is well integrated) 

• Create a Sprint folder with Active, Completed, and Backlog folders.
• Split tasks into logical and doable Sprints.

7. Task Update:

• Before closing each task (marking it as completed), add the project details and attach the related documents.
• For meetings, refer to where the meeting minutes/recordings and presentation are.
• For document creation, add the links to the documents.
• For communication with decisions, record the email record.
• For dev issues, add radar tickets and necessary tech information.
• Follow up with all overdue tasks in your daily standup meeting, and clean up weekly to ensure there are no overdue tasks and everything runs smoothly within the week.
• Create a report listing overdue projects.
• If the task change impacts the project or sprint plan, seek feedback from the PMO Leader before closing tasks/sprints and, if needed, make changes to the subsequent Sprint and tasks to include the required changes. The goal should be to deliver success defined and agreed upon with the stakeholders.

8. Status Meeting:

• Avoid directly jumping into each task during the status meeting and requesting updates. Instead:
• Show the project plan first so the team knows where they are from the overall project plan perspective and emphasize the project objectives/goals.
• Review what has been done and what is coming soon (all tasks will be started and due next week).
• Keep annotating the task as you get updates to track the conversation.
• Update the task status as soon as the team gets started.
• Avoid changing due dates to shift the project schedule. Instead, add notes to the project to show the delay. If there is a date change, add notes to explain the reason for future reference.
• Copy the meeting minute email to the status meeting task before closing.

In summary, Wrike is a tool to keep project plans structured with easy updates. However, it lacks collaborative reporting and content sharing offered by document systems like Quip. Using it along with other tools is necessary. ​

Project manager in general need to create minute for all project meeting and send to meeting attendees and relevant stakeholders in email. The main purpose is  to keep record of decision made and planned action times.  

Create the Minutes Email by selecting Replying to All from the meeting event on the calendar and send out Meeting Minutes within same day of the meeting. If possible, it suggestion to send out the minutes within 2-3 hours. 

Follow the format to create the content. The minutes needs be brief and only include content from the meeting and include the following:

• Subject : <Project Name> <Meeting Name> +Meeting Minutes +(<Date>)
• Email Body : (Optional)
  • Title : <Project Name> <Meeting Name>
  • Date : <Date> <Time> <Time Zone>
  • Attendees (Optional): You would include attendees if this business user meeting. For project status/planning meeting, you can skip this unless you have limited attendance.
  • Minutes:
  • Project Status: On Track (green) | At Risk (Yellow/Red)
    Start with " 1. Project status On Track (green) | At Risk (Yellow/Red)"
    • What's Completed
    • What's In Progress / Pending along with ETA and owner
    • Major Discussion Items (always use bullets and to the point)
    • Action Items : <Who> to do <What> <by when>. Make sure assign a DRI (direct responsible individual) for each action item to prevent the bystanders effect. 
    • e.g. @Richard to complete the user list confirmation ETA 8/6.
  • Link : Add link to the past records of meeting minutes at the end of the email body for reference to old minutes, Its also recommended to include link to the Project Summary Page at the end. 

​Log Minutes : Always log Meeting Minutes in Quip or Wrike with the meeting minutes, recordings and presentation.

Editor's Notes: Product managers often ask, "Why do I need to include a link to the project summary page in the status meeting agenda and meeting minutes? ​" The short answer is this link help user locate the project information quickly. Join the community. If you'd like to learn more about this FAQ, join the community for the details. ​​

Email Template 
-- Copy the following section ---
Title : <Project Name> <Meeting Name>
Date : <Date> <Time> <Time Zone>

Project Summary: <Link to project summary page> 
Slack Channel: <slack channel>
Email Group: <email group>

Attendees (Optional)
You would include attendees if this business user meeting. For project status/planning meeting, you can skip this unless you have limited attendance. 

Minutes: 
1.Project Status: <Project Name> Status <On Track> | <At Risk (Yellow/Red>
2.Discussions

• What's Completed
• What's In Progress / Pending along with ETA and Owner
• Major Discussion Items (always use bullets and to the point)
• Action Items : <Who> to do <What> <by When>
  e.g. @Richard to complete the user list confirmation ETA 8/6. 

Link <Minute Link> 
Add link to the Meeting Minutes page at the end of the email body for reference to old minutes

Recording: <Recording attachment or link>

Presentation: <Presentation attachment or link>

--- End of File ---

A steering committee consists of key stakeholders who oversee, support and guide a project in the right direction. Its members are typically managers from the departments involved in the project. Regular meetings should be scheduled for the steering committee to provide project updates, discuss any issues, and make important decisions regarding the project. The Project Management Office (PMO) requires:

• Schedule the steering committee meeting immediately following the kick-off meeting. The sessions can be held monthly or bi-monthly, depending on the main project phases. We can also arrange steering committee meetings when urgent issues arise. Make a clear roster of committee members outlining their roles and responsibilities.
• Create a presentation at each meeting with the agenda, project status, the current plan, issues to address, and next steps. 
• Send meeting minutes after each meeting, capturing decisions on issues and plan updates. 

PMO requires the setup of steering committee meetings when crossing-team support and decisions are needed.

​

In case of a meeting cancellation, the host needs to send a cancellation or reschedule notice as soon as the cancellation is confirmed. The following actions are recommended:

• Send the notification to all of the impacted team members and stakeholders 
• Include the reason for the cancellation
• Log the cancellation in the project report or the tracking tools for future reference. 

Project managers should avoid rescheduling or canceling meetings very often.

​

Starting a new project is the first step in the project management process. Here are the recommended steps to consider:

1. Create a project summary or charter and the PMO onboarding document.
2. Review these documents with the PMO Leader before the kick-off meeting. Ensure that the following topics are addressed:

• Project requirements
• Clarification of project scope
• Project benefits and values
• Initial project plan and methodology
• Project communication plan

3. Begin stakeholder engagement to gather inputs.
4. Conduct the kick-off meeting.
5. Record the session to establish a communication baseline.
6. Finalize the project requirements and scope.
7. Work on proofs of concept or technology validation as needed, considering the Front-End Loading (FEL) approach.
8. Review the finalized requirements with the PMO Leader again.

This structured approach will help ensure a smooth project start.

Overcommitment could happen when trying too hard to meet the customer's expectations. Let's discuss how you can recognize that you have overcommitted yourself or for your company and  how to resolve the issue. 

Sincerity is the Key. First, admit that overcommitment is a bad thing and should not happen in the first place. However, when some aspects of work are overlooked and result in overcommitments, you would honestly admit the mistake and reduce the impact on customers and the company. If anything changed effects your early commitments, you also should communicate with customers immediately. Keep the customer "in the know" helps get a better understanding and build trust. 

Tip- DON'T: DON'T try to solve the problems without communicating with the customer. Otherwise, it can make things worse. 

Question: Give an example of a time where you were not able to meet a commitment to a team member. What was the commitment and what prevent you from meeting it. What was the outcome, and what did you learn from it?  Learning to say No and knowing your limit are critical to answer the question. ​