Musings on Project Management

What is 'Portfolio' in Project Portfolio Management?

by Connie van Oostveen

What is a portfolio?

Like Project Management, Program Management, and Business Analysis, the Project Management Institute (PMI) has a body of knowledge for Portfolio Management. PMI defines “a portfolio (or project portfolio) as a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives. The projects or programs of the portfolio may not necessarily be interdependent or directly related. These components of a portfolio are quantifiable; that is, they can be measured, ranked and prioritized." Portfolios can be along organizational lines and multiple organizational units may be involved, for example: Information Systems & Technology (IST) portfolio, strategic portfolio, Enterprise Resource Planning (ERP) portfolio, Finance portfolio. They can be related to a business topic and can cross organizational boundaries. Examples of business-related portfolios area student applications portfolio or IT services portfolio.

Additional distinguishing characteristics of portfolios from projects or programs are:

  • “other work” in a portfolio is often operational in nature
  • portfolios do not have a defined end date, where programs and projects do
  • projects and programs can belong to more than one portfolio
  • portfolios can have portfolios within them (e.g. IST portfolio contains IST strategic plan portfolio)

What is portfolio management?

The Project Management Institute defines "project portfolio management (PPM) — or simply portfolio management (PfM) — ... as the centralized management of one or more portfolios that enable executive management to meet organizational goals and objectives through efficient decision making on portfolios, projects, programs and operations.”

The practice of portfolio management can be seen when annual (or longer- term) planning occurs. Identify work: what projects, programs, operational work needs to be done in the coming year? The process may ask for requests, and consider costs, risks, the impact on the organization, strategic alignment, benefits of the work, resource management/capacity. Some organizations (especially private industry) may look at the return on investment (ROI). The identified work may go through a screening and selection/prioritization process: ‘What are the priorities?’ ‘What work do we have to put on hold?’ As the planned work is being executed, portfolio management have processes in place to make adjustments to the portfolio as external and other factors impacts are considered (e.g. new legislation, planned efforts may not bring the intended benefits).

Are you interested in networking further on this topic? Where do you see portfolio management being used at Waterloo and what processes are defined and in place?

I’ve only scratched the surface here, and I hope this is helpful information. Please, if you have more questions, do ask. “The only bad question is the question that isn’t asked!”

Project Lessons Learned

by Pam Fluttert

One of the advantages of coming together as a community is to learn from what others have experienced. Within Information Systems & Technology (IST), an analysis of project lessons learned was completed.

  • 25 percent of our lessons learned reported pertained to communications management
  • 20 percent of lessons learned pertained to procurement management
  • 17 percent of our lessons learned pertained to scope management

Top 10 lessons

Here are a sample of IST’s top 10 lessons across select closed projects (in order, from highest number of repeats):

  1. Manage vendor throughout the project
  2. Assess potential impacts and dependencies as early as possible
  3. Communicate across all stakeholders early and often according to interest and impact *
  4. Understand requirements and objectives to appropriately define scope *
  5. Manage and collaborate with stakeholders according to their interest and impact
  6. Gain support from stakeholders up front
  7. Ensure vendor quality and values align with University expectations
  8. Ensure the right resources are available and their commitment understood
  9. Communicate with appropriate methods
  10. Reiterate project goals often

Common issues

Of these lessons, the two marked with an ‘*’ are repeated from the previous few years, continuing to be issues for many of our projects. There are many reasons why these are continuing issues, some of which may include:

  • Communicating with some stakeholder groups is much more difficult than others (e.g. students and faculty who don’t typically read an email or other common methods used)
  • Finding the balance between too much communication and not enough communication for stakeholder groups
  • Not doing the appropriate stakeholder analysis to understand the interest and impact of various stakeholder groups
  • Projects don’t always have access to resources with communications expertise
  • Objectives and scope can be somewhat “fuzzy” when first defined for the project, making it difficult to know what success should look like
  • Identifying the appropriate people who can provide requirements can sometimes be difficult on campus
  • At times, we don’t spend enough time on gathering requirements because this process can be difficult and time consuming
  • Projects don’t always have access to resources who are skilled at helping stakeholders define their requirements (e.g. helping them distinguish between what they need vs want, or even pull the requirement from every day processes and put it into words)

A Tactical Approach to Change Management

by Jonathan Woodcock

Understanding Change Management

Organizational Change Management is a big, complex subject that discusses how to tackle big, complex problems where many people are involved. The subject provides several examples of methodology, practice, and viewpoints on how to manage change at an organizational level. However, the work must be done at a personal, one-to-one level if it is to be done effectively. Unfortunately, the tactics (the day-to-day actions of undertaking change) are often the most difficult and underdescribed parts of change management. 

A focus on people

Once the strategic work of defining and choosing a direction is complete, it comes down to working with people. Yes, we must assess things like awareness and desire for the change, but how does that change happen within a team or an organization? With the people - the individuals who have to change and are affected by it?

Simple answers to hard questions

The good news is that you already have the tools and skills to address questions like:

  • How do you motivate and engage a group, team or organization to change?
  • How do you generate understanding and buy in for the change?
  • How do discover the challenges, issues and roadblocks for the change to actually happen?

The answer to all of the above is quite simply: you ask and you listen. The hard part is that in order to be effective, you end up having to ask everyone who will be impacted by the particular change or outcome. And in order to get the best results, you're going to have to talk to them all individually. Yes, one at a time, and the listening part is the most important.

Change: one-on-one

As a project manager (PM), I am frequently exposed to new teams with widely differing perspectives, backgrounds, and historical baggage. The one constant is that as a PM, I'm always coming in holding a big bag of change in the form of a project. I also want reproducible processes and methods to work with so I'm not wasting everyone's time reinventing the wheel. To that end I follow these simple steps when introducing a new project or change initiative:

  1. Introduce the whole model to the team or group in question.
  2. Meet individually and confidentially with every member of the group.
  3. Build feedback loops at the individual and group levels.
  4. Identify themes and recommendations for tactics to achieve change in those themes.
  5. Summarize, track, and report to the group as a whole.

The key here is that it is those affected by the change who will be providing the language and perceptions of the change in order to guide recommendations and action. Introducing the whole model at once, and being clear up front that you are exploring the impact of change is an important first step in establishing transparency.  Setting expectations collectively helps prime comfort in the discussions to come. 

Building trust

If you are clear up front that the meetings and notes will be confidential and that the individuals will have full control over what was recorded, you are setting the expectation of agency and control in the process. This individual sense of control is so significant in successfully implementing change that any effort put into supporting this step is worthwhile. The recorded summary is shared back to the team providing the opportunity for those most affected to frame the change in their own words. It also effectively closes the loop on transparency and accountability for yourself and the sponsors of the change. 

But what do you ask in the one on one meetings?

Three questions and a sneaky trick 

While I often attempt to set a comfortable, informal tone in the actual one-on-one meetings, it is important to give people time to prepare their answers. Given that this activity is likely to be done with many people, some level of pre-booking or scheduling is to be expected. Several days ahead of the meeting I provide the following questions as an agenda:

  1. In your own words, describe your role on the team or in the process.
  2. What are some areas you see as opportunities for improvement?
  3. What are things that absolutely cannot be changed?

At the time of the meeting I reiterate that the discussion is confidential and that they will have the opportunity to see the raw notes from the discussion and make any comments or corrections before they are summarized anonymously. We then conduct the interview in such a way as to ensure the individual is driving the conversation. To do this I recommend you:

  • avoid editorializing
  • facilitate the conversation if needed
  • repeat comments back to the individual for understanding, and to ensure they are feeling heard and understood

What you're listening for

The conversation will tend to wander among the three topics (question areas). Listen for opportunities when the individual is speaking about their role, and for the pain points associated with the things they feel cannot change. Capture all of this using the language presented to you from the individual. It is important from both a transparency and buy-in perspective that you align the presentation of the change to the understanding, language and perception of those most affected.

One extra sneaky question

Once I'm confident we've captured as much as can be in the time available I sneak in one extra question, "Given we're going to do some work and make some changes, please take a minute and imagine that in six months (and again with one year) we've come to the end of that change process and it has been successful. What does that look or feel like to you?"

This question is almost always met with pleasant surprise. While it is often hard to imagine a clear path between now and the end of a project or change effort, it's often possible to imagine what a win looks like at the other end. Not only does this prime thinking about successful outcomes, but it also primes thinking about change happening over time. More importantly, it gives some of the most useful information in the form of success criteria for your efforts in the words of the team.  

Reporting, transparency and accountability

Once the individuals have had a chance to provide their feedback on your notes, it's your job to translate those notes into an anonymized summary for presentation to the group as a whole.  

What you're summarizing

Question one tells you who you're working with, and their own view of their role apart from job description or function. This is the opportunity to identify the key stakeholders in the change, as well as those most affected and most in need of ongoing input, support and attention. Recommendations arising from this question will be around where you see gaps in needed skills or knowledge, as well as strengths to focus on and leverage.

Question two tells you where you can generate engagement and buy in. If someone is highlighting an issue and it aligns with the needs for the overall change, engaging them in or even making them responsible for resolving that issue is a powerful way to keep them focused, engaged, and working with the change. Recommendations arising from this question will include some of the quick wins needed to sustain the ongoing efforts.

Question three tells you where your risks are, and where your biggest obstacles will be. Best case scenario will have a common item or theme across all individuals and you can ensure that touchstone stays intact through the change. Worst case, you're going to identify who you will need to engage and guide most through changing something they are resistant to changing. Recommendations arising from this question will involve scoping the change and putting boundaries in place to ease concerns of the team or group.

Finally the success question translates directly into success criteria for your efforts. In the best case you will be able to translate those things into measures and metrics. Reporting on these measures throughout the project or change effort not only helps to sustain the ongoing effort, but reminds the team or group that progress is being made, and those leading are measuring based on their expert input.

Change happens, live there

It is a cliché that the only constant is change, but it's also a reality for many of us. Finding positive ways to engage with change and support your colleagues through change is not only a good way to survive in a constantly changing environment, but will improve things here at Waterloo. And it truly is as simple as asking, and then listening.

A Typical Day in the Life of an Agile Project Manager

by Stacey Mahoney

Lately, I have been trying to manage most of my projects in more of an Agile approach; not fully Agile, but using some of the core Agile concepts including scrum, time boxing in sprints, focusing more on interactions and responding more to change. This approach has been working successfully for these projects - but it does keep me on my toes each day. I often plan a day a certain way and then experience something completely different!! 

In this post, I'll take you through a typical day as an Agile Project Manager (PM) - or at least what was planned versus what actually happened.


8:00 a.m.

  • Log in to my computer and check my Outlook Calendar to see what is planned for the day
  • In addition to the meetings/time booked in my calendar, I also need to keep an eye on our production/operations Request Tracker (RT) queue should any urgent issues arise

8:05 a.m.

  • Quickly check email and see an urgent operational item that I need to look into immediately

8:05-8:30 a.m.

  • After some investigation, we have fixed the urgent item
  • Back to the day as planned

8:30-9:00 a.m.

  • Cleanup project tasks in TeamDynamix (TDX) for this current project sprint
  • Run "completed work" reports and begin some data manipulation needed for sprint reports

9:00-10:00 a.m.

  • Project team meets; start with another quick look at the current project tasks and realize we forgot to mark a few things complete
  • Good news is this increases our burndown (i.e. the amount of work we got done), but bad news is that the report I ran is already out of date
  • Close out the current project sprint and spend approximately 15 minutes having a retrospective conversation: What went well? What are the areas for improvement? Common items that come up include:
    • What went well: dedicated work/project space; blocked work time; all project work centralized in TDX
    • Areas for improvement: additional calendar blocking and integration of Skype tool; clarify communications; new feature rollout methodology
  • Use "cheat sheet" to review and plan for the next sprint (e.g. project goals, milestone timeline, team member scheduled absences, important dates, new and outstanding tasks and related story points)
    • Tough decisions have to be made sometimes regarding what work gets scheduled for the next sprint; a review of the project priorities, scope, dependencies, and other factors aid this process
    • Although this particular project is more of an Agile project, there are still dependencies between tasks and the only way to ensure nothing is missed is to have conversations about this work each sprint 
    • A report summarizing the plan for the next sprint would be ideal but will have to wait as it is already 10:05 a.m.

10:05 a.m.

  • Return to desk to record notes from the meeting
  • Update reporting
  • Craft update email for project stakeholders on the sprint retrospective and planning meeting
    • Click send at 10:20 a.m., gaining 10 minutes in my schedule

10:20 a.m.

  • Run into another PM which prompts us to discuss some useful "Lessons Learned" from a previous project 

11:20 a.m.

  • Receive a production support/operations request and connect with a team member to work to resolve the issue
  • Use Skype to call into a Project Scrum at 11:45 (technology definitely helps me multi-task)

12:05 p.m.

  • Lunch, some email and a walk to get a coffee


1:00 p.m.

  • Head to the project room to brainstorm the project "Improvement List", which will help determine the scope and focus of the work for the upcoming months
  • 23 process related improvements, their impact, effort, and rank against established project goals are recorded on the whiteboard and a photo is taken

2:00 p.m.

  • A project stakeholder and their manager unexpectedly join the second hour of blocked project meeting time to review and clarify an assigned task and timeline
  • A rough breakdown of the task and its dependencies help demonstrate why this work is so critical

3:00 p.m.

  • Planned project time is used instead to help the stakeholder complete their task
  • Project team members are available to assist and complete related testing

4:00 p.m.

  • Status of each task is noted in TDX
  • Only 50% of the task is completed with the stakeholder and the project team did not finish identifying future project scope -- additional meeting time will be required 

4:10 p.m.

  • Prioritization of remaining work will take place in the morning -  it is time to head home

Key learning

My number one learning in trying to apply more Agile Project Management tools and techniques - be ready to respond to change! Your day may never go as planned; but that is ok. The work got done and that is what matters!

To learn more about Agile, you can visit: