Voices on Project Management

By Christian Bisson

Within the realm of agile project management, the composition of a team greatly impacts its success. While all team members play a vital role, the inclusion of an external product owner (as opposed to an internal one) poses challenges that can hinder teams’ potential to deliver value to users. 

In this post, I will highlight four potential pitfalls of having a product owner external to the team, with real-life examples underscoring the benefits of an integrated team approach.

1. Misalignment and Unclear Vision

When a product owner is external to the team, misalignment and an unclear vision can arise. The absence of direct day-to-day collaboration stifles the shared understanding of project goals, priorities, and user needs. This lack of alignment makes it difficult for the team to make informed decisions and deliver a product that meets customer expectations.

Example: Imagine a software development project where the product owner is external and has limited interaction with the team. This separation hinders effective communication and prevents the product owner from gaining in-depth knowledge of the project domain. As a result, misaligned priorities and a fuzzy vision emerge, leading to a disconnect between the team's efforts and the desired outcomes.

2. Inefficient Prioritization and Decision Making

An external product owner often leads to inefficient prioritization and decision-making processes. Without a direct line of communication, the product owner's expertise and insights may not reach the team effectively. As a result, crucial decisions regarding scope, timelines and trade-offs may be delayed or misinterpreted, leading to project inefficiencies and missed opportunities.

Example: In a marketing campaign project, an external product owner who lacks real-time interaction with the team may struggle to grasp the evolving market trends and user preferences. Consequently, delays in decision making occur, preventing timely adjustments to the campaign strategy, ultimately impacting its effectiveness and return on investment.

3. Communication Gaps and Feedback Delays

With an external product owner, communication gaps and feedback delays become commonplace. The limited availability and reduced involvement of the product owner hinder continuous communication and the timely exchange of information. This results in a slower feedback loop, preventing the team from promptly addressing concerns, adapting to changing requirements, and delivering high-quality increments.

Example: In a mobile app development project, an external product owner may have competing priorities and limited availability for sprint reviews. As a result, feedback on delivered iterations may be delayed, preventing the team from incorporating valuable insights—and potentially leading to inefficient use of development resources.

4. Detached from User-Centric Mindset

When the product owner is external, the team risks losing touch with a user-centric mindset. The direct contact between the product owner and end users diminishes, inhibiting the team's understanding of user needs, preferences and pain points. Without this critical insight, the team may struggle to develop solutions that truly resonate with the target audience.

Example: Consider an e-commerce project where an external product owner has limited interactions with actual customers. The team, lacking direct access to user feedback and insights, may fail to anticipate user behavior, resulting in an e-commerce platform that falls short of meeting customers' expectations and inhibits business growth.

Conclusion

In the agile realm, the inclusion of an external product owner introduces several pitfalls that can hinder project success. Misalignment, inefficient decision making, communication gaps, and a detached user-centric mindset are among the challenges an integrated team approach aims to mitigate. By recognizing the drawbacks of an external product owner, agile teams can foster collaboration, transparency, and a deep understanding of customer needs, ultimately leading to more successful project outcomes.

The above points assume there is one external product owner for the team. However, if there are multiple external product owners in a team, all the challenges mentioned earlier become even more significant. It not only amplifies the existing issues, but also adds to the tension and confusion within the team.
 

By Dr. Lynda Bourne

The generally accepted way of assessing progress on a project, and predicting its completion, is to use a critical path method schedule. However, the CPM paradigm does not work across a wide range of projects where there is no predetermined sequence of working that must be followed. There may be a high level “road map” outlining the desired route to completion and/or specific constraints on the sequencing of parts of the work but in most agile projects, the people doing the work have a high degree of flexibility in choosing the way most of the work is accomplished.

The focus of this post is to offer a practical solution to the challenge of assessing progress, and calculating the likely completion date in agile projects.

WPM as an Alternative to ES and CPM
Work performance management (WPM) is designed as an alternative approach to project controls. It uses the same concept as earned schedule, but offers a simple, practical tool that uses project metrics that are already being used for other purposes.

The function of WPM is to assess progress and calculate a predicted completion date in a consistent, repeatable, and defensible way by comparing the amount of work achieved at a point in time with the amount of work planned to have been achieved at the same point in time. Then based on this data, you calculate an expected completion date.

The Theoretical Basis of WPM
WPM has been designed to fill an identified gap in the current controls systems used on agile projects. It is based on the same premise used in earned schedule and earned duration, and is expected to achieve a similar level of reliability by comparing the amount of work planned to be accomplished to the amount of work actually achieved in the period through to a data date (time now). However, unlike ES and ED, WPM focuses on the core elements of the work.

WPM Terminology
The terminology used for the data points in WPM is:

• WP = Work Planned               measured in an appropriate unit – cumulative over time
• WA = Work Accomplished     measured on the same basis as WP
• PC = Planned Completion     project duration in time units (days, weeks, months)
• TN = Time Now                       the number of PC time units to the date of assessment
• TE = Time Earned                   the number of PC time units to the point where WA = WP

From this information, the work performance measures are calculated as follows:

• WPV = Work Performed Variance TE - TN,
  negative values show the schedule slip in PC time units
• WPI = Work Performed Index         TE/TN,
  values less than 1.0 show less work has been accomplished than planned
• EC = Expected Completion            the expected project duration in PC time units calculated by                                      PC/WPI = EC
   

Applying WPM to a Project Using Scrum
Scheduling the work should be as realistic as possible, but in many situations a straightforward pragmatic approach will suffice. Take for example a 20-week software project that has 27 stories of various size, a total of 86 story points, and the resource planning to use two scrum teams. In the absence of any other information, you could assume:

• The first two weeks are needed for team development, planning and other start-up processes
• Sprints are expected to take two weeks each
• The last two weeks will be for contingencies, bug fixes and other finalization work

This leaves 16 weeks for productive work; therefore, the first stories should be delivered at the end of the first productive sprint, Week 4, and all stories by the end of Week 18.

This means the rate of planned production between the start of Week 2 and the end of Week 18 is 86/16 = 5.375 story points per week. Based on these assumptions, at the end of Week 4 (two weeks of production), we can expect 10+ story points to be complete, and at the end of Week 18 all 86 story points complete. The rest of the planned distribution is simply a straight line between these two points.

We know sprints will not take exactly two weeks every time (some will overrun, and occasionally some will finish early), and we also know the number of story points generated in each sprint will vary. But on average, if the two sprint teams together are not completing a bit over 5.3 story points per week, every week, the project will finish late.

Once this basic rate of production has been determined for the project, WPM measures the actual work delivered (WA) and shows the time variance at time now (TN) and uses this information to predict the expected completion (EC).

For example, at the end of Week 8, three sprints should have been completed by both teams, and we are expecting 30 story points complete. But only 23 have been delivered. Velocity calculation will indicate more sprints will be needed, and the burndown chart will show the work is behind plan. But what does this mean from a time perspective?

A look at the planned rate of production will show 23 story points should have been finished during Week 7 (the actual fraction is 7.3). Therefore, the work is 0.7 weeks (3.5 working days) late. The work performance index (WPI) is 0.9125.

Dividing the original duration (20 weeks) by the WPI suggests the revised duration for the project is 21.9178 weeks; the variance at completion is -1.9178 weeks, or 13.4 calendar days late.

If these calculations look similar, they are based on the well-tried formula used in earned value management and earned schedule—all I’ve done is shift the metric to a direct measure of the work performed.

Conclusions
WPM is designed to be a simple robust performance measurement system that will provide an accurate assessment of the project’s status from a time management perspective. It can assess how far ahead or behind plan the work currently is—and based on this information, the likely project completion date based on the assumption work will continue at the current rate

The two requirements to implement WPM are:

• A consistent metric to measure the work planned and accomplished
• A simple but robust assessment of when the work was planned to be done

The metric used can be a core deliverable (e.g., 2,000 computers replaced in an organization), or a representation of work such as “story points,” or the monetary value of the components to be delivered to the client.

Peripheral and support activities can usually be ignored when establishing the WPM metric; they rarely impact the project delivery independently. Failures in the support areas typically manifest in delays to the primary delivery metric.

Questions?
Has anyone seen or used something like this in the “real world”? I would love to hear if you have.

By Peter Tarhanidis, Ph.D.

There is a dramatic increase in the strategies corporations implement to meet the needs of their stakeholders. Driving value from all parts of an organization and its functions may seem like repetitive exercises—and even feel more like a medieval gauntlet with only a few successful programs. HBR (2021) wrote that by 2027, about 88 million people will be working in project management—with economic activity reaching $20 trillion USD. Also noted: Only 35% of projects are successful, leaving immense waste of resources.

There are many reasons projects fail. HBR (2021) states of the 70% of failed projects, and after exhaustive root-cause analysis across all industries, one can identify common themes such as undervaluing project management skills and methods, and poor performance. Yet organizations that apply project management methods recognized their performance had a 2.5 more times chance to be successful, and organizations can waste 28 times less resources. As such, when applied, the implementation of PM methods works.

Yet in a world filled with a variety of project taxonomies, many organizational boards are now contemplating the need to implement environmental, social and corporate governance (ESG) and corporate social responsibility (CSR) programs. Forbes states the benefits of ESG and CSR initiatives include:

1. Advancing organizational culture, empowering staff to do social good, and welcoming diversity.
2. Encouraging partners and investors who are interested in long-run strategy to manage risks and opportunities by emphasizing the organization’s ethics.
3. Raising an organization’s staff confidence and productivity, creating a workplace that achieves the business mission.

Therefore, to ensure success for ESG and CSR programs, an organization’s top leaders need to prioritize and align across all the organization’s businesses. Leaders can use the balanced scorecard to achieve this alignment, and can extend its use across the entire project portfolio.

This theory was developed by Kaplan and Norton, which state the balanced scorecard method converts the organization’s strategy into performance objectives, measures, targets and initiatives. Linking the concept of cause and effect, the balanced scorecard covers four perspectives:

1. Customer: How do customers see us?
2. Internal: What must we excel at?
3. Innovation and learning: Can we continue to improve and create value?
4. Financial: How do we look to shareholders?

Marr (N.B.) reported over 50% of companies have used this approach in the United States, the United Kingdom, Northern Europe and Japan. One clear benefit has been to align the organization’s structure to achieve its strategic goals.

In conclusion, applying project management methods and aligning an organization’s performance through the balanced scorecard can unlock ESG and CSR benefits that can supercharge a company’s efforts to achieve its mission.

References

1. HBR: The Project Economy Has Arrived
2. HBR: The Balanced Scorecard—Measures that Drive Performance
3. Project Management Statistics: Trends and Common Mistakes in 2023
4. Forbes: Three Reasons Why CSR And ESG Matter to Businesses
5. Balanced Scorecard: How Many Companies Use This To

By Yasmina Khelifi, PMI-ACP, PMI-PBA, PMP

What’s the next step in your project management career? For some people, it’s hard to know what your mission is. For others, they like their jobs and also have side projects. And for some, their side projects become their day jobs.

I’m reading Working Identity, a very insightful book by Dr. Herminia Ibarra, an organizational psychologist. The book is about career transitions and how to find the next step in your career.

The author describes a career transition framework in three steps, based on her research and in-depth interviews:

• Crafting experiments
• Shifting connections
• Making sense

Reading this book, I wanted to share some thoughts about working identities as a project manager. Why is this important? According to me, it helps you build your career in the project management world and develop your elevator pitch. It also helps you to be more self-aware and self-confident in your abilities.

Possible selves as a project manager
My journey as a project manager began with my first role. I became a PM thanks to the sponsorship of a manager, so I thought it was luck—and I experienced impostor syndrome.

I observed how other PMs behaved and what was valued by the organization. There were project manager role models in the organization. I remember I tried to be stricter than I wanted to sometimes because I observed other people behave that way, so and I thought it was the right way to act. But were they the role models I wanted to identify with?

I wanted to take more time to onboard people. I developed documents, a glossary and an annex. No one asked me to do so, but for me it was the right approach. But I was not sure if it was the best path to follow.

So my formative years were full of questions, wrong assumptions and hesitations. I did not have a mentor in project manager, but I got feedback from my managers, my peers and my colleagues. I got more negative feedback than positive—or at least I listened more to the negative feedback:

• “You are not strategic.”
• “You do not communicate well.”
• “You should not have sent this email.”

These first working experiences contributed to the perception I had of myself, the labels and competences I thought I had—or needed to work on.

As years passed, I gained more self-confidence and developed different selves. I was initially a technical project manager, and I was proud of being technical and keeping up with the team. I’m now more of a leader project manager—facilitating solutions, creating collaborations across the globe.

If people tell me, “You’re not technical,” I reply: “I have a technical background, but don’t expect to become a technical expert.” And I’m comfortable with that answer.

Let us apply the framework described in the book to help inform how you move forward in your project management career:

1. Crafting experiments
This is what I discovered in 2018 by volunteering. I could experiment with new activities. I discovered I liked presenting webinars; I liked using visuals in presentations.

Do you want to work in a new industry? Perhaps you can volunteer in an organization there?

By exploring new paths, you’ll better define what you enjoy (and don’t). Sometimes, we have long dreamt of ideal roles and work. But in reality, they are not always the right fit.

2. Shifting connections
Be part of project management communities in your workplace. This is also a way to build bridges in the company and learn new working opportunities. Also be part of communities outside of your organization. You can also earn a certification.

Don’t limit yourself to just project management communities. I’m part of a coaching community and a marketing one. Are you afraid of not fitting in? Don’t worry—you’ll learn step by step.

Exchange ideas and experiences with people by chatting (online or in person).

3. Making sense
By experimenting, talking with people, asking questions and asking for feedback, you’ll pave the path for your PM career. Each experience will enrich your project manager identities. It takes time and courage.

We are all comprised of multiple traits, and we run multiple projects at work and in life. We have to acknowledge our diversity.

What working identities do you have as a project manager?

by Dave Wakeman, PMP

On a recent visit to Reddit, I noticed a trend from some project managers—who were asking questions about how you can tell if your company is doing project management all wrong.

That got me thinking about some signs that an organization doesn’t have a healthy PM culture—and three big ones came to mind. Do you experience any of these where you work?

1. No idea why the role of project manager is key to a project’s success: I believe we’ve all been there—we see someone assigned as the project lead due to being in the wrong place at the wrong time.

Why do I say that? Because just throwing out the PM assignment is never a case of being in the right place at the right time.

This is truly the biggest warning sign that an organization isn’t project manager ready—they just have no definition of why the role of PM is so important to a project’s success.

Instead of having a clear expectation of the PM’s role with a defined process in place to help with achieving specific goals (including communication expectations, a definition of success, and an understanding of how the project ties into the organization’s strategy), the organization basically sticks its hand into a paper bag with pieces of paper, drawing one name out. (Or worse.)

Beware!

2. No clear definition of success: This one seems to take hold in a lot of organizations, and it is usually coupled with the impression that “I’ll know it when I see it.”

This kind of attitude almost guarantees failure. There are exceptions where a project comes together well without this definition in place—but that is very rare.

Why? Because without an understanding of what success looks like, any direction is a good direction.

This can be frustrating for all stakeholders, because when pressed for objectives or measures, a lot of time the feedback comes back as fluffy terms that aren’t related to the project’s success like “man hours,” “activities” or something else.

Bad project organizations judge success by “feel.” Good project organizations judge success with metrics.

That way, you can say, “We hit our target. Here is why…”; or, “We missed the mark. Here’s why, and here is what we can do to change it next time…”

3. No resource investment tied to specific projects: This is one I’ve been blindsided by in the past.

Why? Because I’ve fallen prey to the answer, “Whatever it takes!”

Trust me: “Whatever it takes!” is never actually “Whatever it takes!”

Organizations without a project culture underestimate the resources needed to make a project successful. This leads them to offer “commitments” or “promises.”

Most of the time, when a PM tries to cash in on those “promises” and “commitments,” it is impossible. The resources aren’t actually available.

This stands in contrast with an organization that is built for project management—where you have the scope, you know what success is going to look like, and you have a clear understanding of the resources that are going to be needed to hit the project’s objectives.

Does this mean that there are never changes or limits to the resources available? No. Not even close.

What this does mean is that a good project organization starts with some base level of commitment of resources, not just “commitments” and “promises.”

To me, every project requires these minimums from an organization in order to give success a chance:

1. An appreciation of the role of the PM. You are a leader, not a magician.
2. A clear definition of success, not just platitudes.
3. Resources. Maybe not everything I wanted, but more than “promises” or “commitments.”

I’m curious what things you have noticed that set an organization’s projects up for failure. Let us know in the comments below.