Voices on Project Management

by , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Vivek Prakash
Christian Bisson
Rebecca Braglio
Cyndee Miller
David Wakeman
Jen Skrabak
Mario Trentim
Shobhna Raghupathy
Rex Holmlin
Roberto Toledo
Wanda Curlee
Taralyn Frasqueri-Molina

Recent Posts

When Project Benefits Erode

What Do Next-Gen Project Leaders Look Like?

How to Avoid Useless Meetings

Future-Proof Projects — and Careers — With a Little Engineered Serendipity

I, Project: A Peek Into a Machine-Powered Future

Portfolio Governance—Ensuring Alignment to Strategy (Part 2: Definitions)



By Jen Skrabak, PMP, PfMP

In the first part of this series, I introduced PMI’s new governance practice guide and reviewed basic differences between organizational (corporate) governance, portfolio management governance and portfolio governance.

With that foundation, I’ll now discuss the four basic governance functions, which together can ensure alignment to strategy. Since portfolios include programs and projects by definition, those are not called out separately.

  • Oversight. Provide guidance, direction and leadership for portfolios
  • Control. How to monitor, measure and report on portfolio status
  • Integration. Provide strategic alignment and integration for the portfolio
  • Decision-making. Provide decision-making structure, thresholds and membership, including delegation of authority for portfolios

In addition, there are four basic governance domains:

  • Alignment. Creating an integrated governance framework, and defining the governance relationships and hierarchy between portfolio governing bodies and other governing bodies (enterprise, functional, program and project-specific)
  • Risk. Identifying and resolving threats and opportunities proactively to ensure the balance of risk and reward for the portfolio
  • Communications. Disseminating information, engaging stakeholders and ensuring organizational change is carried out effectively
  • Performance. Measuring and evaluating KPIs to ensure portfolio value

For some portfolio managers, there may be confusion over governance activities versus portfolio management activities. Portfolio managers may play a governance role on certain programs and projects and provide oversight and decision-making. However, day-to-day portfolio management is distinct from governance, as shown in the diagram below:

Look for part three of this series—which will be focused on key success factors—in the coming weeks! And comment below to share your reactions.


Posted by Jen Skrabak on: May 02, 2016 04:12 PM | Permalink | Comments (2)

Is Your Agile Communications Toolkit Up to Snuff?

By Taralyn Frasqueri-Molina

A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate. 

Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.

Here's a short list of tools I've used on all of my projects.  

Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.  

Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.

Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.

Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.

Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.

Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!

What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.

Posted by Taralyn Frasqueri-Molina on: March 24, 2016 12:30 PM | Permalink | Comments (7)

Agile, or Real Agile?

Categories: Agile

By Christian Bisson, PMP

Agile approaches allow for iterative and flexible avenues to develop software. (It can be used in other fields, of course; I work in the software world.) When used properly, it can be an efficient way to adapt to changes in requirements and scope, and provide stakeholders with an up-to-date and ongoing list of deliverables to review.

Unfortunately, it’s a misunderstood approach that leaves many of us wondering if they’re really working in agile ways. Here are a few misconceptions I’ve encountered throughout the years.


Things just change names

My favorite misconception of agile is that terms suddenly need new names.

Meetings become “scrums” or “daily scrums”—even though the team is just having a regular meeting. A “week” becomes a “sprint”—even though there is no deliverable/release at the end.


Going faster is agile

Project managers sometimes “crash” a schedule to speed up project deliveries, knowing that it uses more budget in order to meet a deadline. Sometimes “crashing” is confused with “agile,” which is thought to deliver projects sooner and cheaper by having everyone start their work sooner than they would have in a traditional waterfall approach.

Having people start sooner and risk rework is still crashing even if the practice is called “agile.”


Stakeholders don’t have to be involved

Stakeholder involvement is a critical part of the agile approach. It requires them to be available and in constant discussion with the team. This prevents surprises and allows constant feedback.

The misconception I see sometimes is that a team can work “full agile,” with stakeholders only involved when they receive assets and go through their typical review cycles.


We’ll just “try” agile

Agile is not about trying out a new software. It’s a culture, and it involves everyone from stakeholders to the team. Some believe that a few people can “try agile” on a project and see how it goes, even though none of them worked in an agile environment before.


Scope and cost can be fixed

Although agile could work with a fixed cost, it is quite the trap. Agile assumes that what will be delivered is the work that the team was able to deliver in a set amount of sprints, and each sprint will cost a certain amount based on the team’s size (among other things).

This means that if a feature took twice the amount of time estimated because it was decided to create something a bit more complex, then another feature might be removed or budget will be added to compensate. However, if you keep the budget the same but still expect to deliver everything planned on day one, then this more complex feature is simply scope creep.

These are just a few examples of agile misconceptions. My bottom line: When I’m told stakeholders want to use “the agile approach,” I make sure to ask for a definition of agile.

Have you encountered other agile misconceptions? Share them below!

Posted by Christian Bisson on: March 11, 2016 02:45 PM | Permalink | Comments (0)

Agile in Asia: Gaining Ground, and for Good Reason

Categories: Agile








In recent years, agile approaches have rapidly gained ground in many parts of the world—but not everywhere. Some areas of Asia, including where I live (Taiwan), have generally speaking not yet embraced agile ideas and practices, despite their value and potential in the region. For this reason, I’ve been working to promote the adoption of agile approaches.

What is agile? It means being flexible and able to quickly adapt to unpredictability. Agile approaches are useful where the environment is constantly changing, where requirements are not fixed or where stakeholders face constant uncertainty.

Agile is typically used in software development, but it’s becoming more suitable in any organization facing rapid changes. Developed over 20 years, agile practices focus on customer value and emphasizing collaboration.

My work has involved training Agile Certified Professionals (PMI-ACP)®, organizing agile communities, promoting agile practices and reporting on the successful use of agile. I have a digital magazine, “PM-Mag ,” with over 100,000 readers across the Chinese-speaking world. Two of the editors have earned the PMI-ACP® credential.

Through my company, I ‘ve also commissioned reports and articles about the use of agile to generate its acceptance and support. I’ve also taken advantage of other media (such as radio and YouTube videos) to raise awareness of agile in the project management world. And then there are other more novel approaches—like an ACP song played at events and before speeches. I introduced a “Hybrid PM” badge that I award to project managers I see taking up agile ideas.

In the last year alone, I trained 149 PMI-ACPs, accounting for nearly 50 percent of the PMI-ACPs currently working in Taiwan.

It was my honor to win the 2015 Agile Award for Person Who Has Done the Most to Promote Agile. The competition was strong, and I’m very humbled by this recognition.

Currently in their sixth year, The Agile Awards are organized by business management consultancy Yoh to recognize businesses, organizations and individuals who actively promote knowledge of agile, as well as its proper application and development. In the past, the awards have been dominated by Europeans and Americans.

I hope that my recognition will spur more international recognition of agile methods in project management, encouraging the further development of agile in Asia and allowing European professionals to understand agile application and development throughout Asia.

To improve the acceptance of agile even more, I encourage those who have already gained their PMP to learn from agile, especially the concepts of incremental delivery, adding business value and embracing change. These new ways of running businesses can improve the competitiveness of small to medium-sized businesses. The added value is too great to ignore.

Posted by Lung-Hung Chou on: March 03, 2016 06:24 PM | Permalink | Comments (1)

Help! I Have Both Waterfall & Agile Projects in My Program (Part 2)

By Kevin Korterud

I’m frequently asked how program managers can synchronize projects using waterfall approaches with those using agile or other approaches. As programs are launched to address larger and more complex business problems, harmonizing a program’s projects becomes an essential component of success.

In my last post, I shared two tips for achieving harmony: remember that there’s no such thing as agile or waterfall programs, and make the correct delivery approach choice before a project begins.

Here are two more tips.

3. Establish a Program PMO and an Agile COE

One of the critical success factors for any large program is the program management office (PMO). The program-level PMO enables the program manager to spend time on higher-value activities while the PMO creates the operational governance, reporting and overall management foundations required to run a program.

As agile and other delivery approaches mature, there is a great need for a COE (Center of Excellence) model that fosters efficient and effective delivery approaches for projects on programs. Just as PMI has created a consistent approach to project management, agile and other delivery approaches are at a point in their maturity cycle where consistency is needed for them as well.

An agile COE can facilitate this consistency while serving as a clearinghouse for improved agile practices. This COE can also address different variants in waterfall, supplier and governmental delivery approaches, thus resulting in an overall harmonized approach for program and project delivery. 

4. Speak the Same Metrics Reporting Language  

George Bernard Shaw once said, “England and America are two countries separated by a common language.” Being a program manager with projects utilizing multiple delivery approaches can feel like living in one country separated by multiple languages!

On a program, it is essential that no matter their delivery approach, projects need to be able to both accurately describe their progress and do it in a way consistent with other projects. When dealing with projects with multiple delivery approaches, a suitable translation needs to be in place for progress metrics. This is particularly necessary for stakeholders such as finance, human resources or other business functions where an easily understood definition of progress is critical.

For example, agile projects do a great job in counting projected versus actual requirements and their weighted points. Using the total and completed requirements, a percentage completion can be calculated that is consistent with a waterfall delivery approach. Other agile-specific metrics such as effort per story point can be used to supplement the core progress metrics.

In addition, even between waterfall delivery approaches there needs to be defined a consistent approach for earned value structures, tracking actual cost and other progress essentials. (Note that aside from progress metrics, the concepts of risks, issues, dependencies, milestones, cost forecasts and governance escalations all remain the same no matter the project delivery approach.)

Program managers are orchestrators of both project delivery and the attainment of business results. They need to be always thinking about eventual business outcomes, no matter which delivery approaches are in play. Remember: no one chooses an airline or car model because the company used agile or waterfall on their projects—it’s all about the experience.

What methods have you seen employed in programs to handle multiple delivery approaches? 


Posted by Kevin Korterud on: February 19, 2016 05:54 PM | Permalink | Comments (5)

"A classic is something that everybody wants to have read and nobody wants to read."

- Mark Twain