Voices on Project Management

By Peter Tarhanidis, Ph.D.

One of the impacts artificial intelligence has had is prompting a reconstitution of project management. Here I look to leading industry experts to explore the benefits to project management systems due to matured AI software; and the maturity of the project manager as a data- and fact-driven champion of business outcomes and innovation. This combination of advanced project systems performance and leadership competence will significantly transform project success rates.

As a background to the current state of project management, HBR states that $48 trillion is invested annually in projects. The Standish Group notes that only 35% of projects are successful, and 65% of projects waste resources and have unrealized benefits.

Additionally, Proofhub attributes project failure to firms that lack project management delivery systems; they are prone to miss targets and overspend. It noted that 67% of projects fail because project management is undervalued; 44% of all managers do not believe in the importance of project management software; and 46% of firms place a high priority on project management. Also noted: Utilizing a good software program reduces failure by 10%, and scope creep by 17%.

More specifically, a PMI Learning Library article noted some reasons for project failure:

1. Unclear goals and objectives
2. Lack of resource planning
3. Poor communication across the organization
4. Inadequate stakeholder management
5. Poorly defined project scope
6. Inaccurate cost and time estimates
7. Inadequate risk management
8. Inexperienced project managers
9. Unrealistic expectations

Maturing Systems
An HBR article suggests that poor project success rates are due to a low level of available mature systems. Many firms continue to rely on spreadsheets, slides and other applications that haven’t matured current practices. While the current tools are adequate in measuring project performance, they do not allow for the development of intelligent automation and collaboration across the portfolio of projects. The opportunity to apply AI to project management could improve the success ratio by a quantifiable 25%, or trillions of dollars of newly realized benefits for firms and society.

Gartner Inc. analysts predict that by 2030, AI software—driven by conversational AI, machine learning and robotic process automation for gathering data, reporting and tracking—will eliminate 80% of all project management office tasks. Gartner identifies project management disruption in six aspects:

1. Better selection and prioritization
2. Support for the project management office
3. Improved, faster project definition, planning and reporting
4. Virtual project assistants
5. Advanced testing systems and software
6. A new role for the project manager

PwC envisions AI-enabled project management software will improve a project leader’s decision-making process across the following five key areas crucial to success:

1. Business insights improvements by filtering better data for relevant knowledge
2. Risk management assessing scenarios that offer mitigation strategies
3. Human capital in allocating resources more appropriately to meet the business priorities
4. Integrating various technologies and specialists to improve project outcomes
5. Active assistance by enhancing administrative tasks and stakeholder progress communications

PwC posits the advancements in project management software are an opportunity for firms and leaders that are most ready to take advantage of this disruption and reap the rewards.

PM Competence
PMI’s Project Manager Competency Development (PMCD) Framework provides an assessment and development of a project manager’s competence. It is based on the premise that competencies have a direct effect on performance. A project manager’s competence can be categorized in terms of project management knowledge, project management performance and their accomplishments, and personal competency in performing the project activities and personality characteristics. This combination is the stated success criteria for a competent project manager.

AI’s capability to assess disparate sources of big data to obtain actionable insights arms project managers with improved decision-making competence throughout the project lifecycle. However, a challenge noted by PwC’s recent analysis of OECD data (covering 200,000 jobs in 29 countries) warns that AI’s job displacement effect will automate 30% of jobs involving administrative manual tasks by the mid-2030s. This indicates a clear need to upskill project manager competence in order to thrive in the future.

In order to succeed, a firm’s culture of adaptability and lifelong learning is a cornerstone for shifting today’s project management roles into the future. They will need to expand competence in soft skills, business and management skills, technical and digital skills—all working in concert with each other.

IAPM states project managers will face fundamental changes over the next 10 years with job descriptions and roles. It suggests AI will make logical analysis and decisions, allowing the PM to focus their main area of responsibility on creativity, resolving conflicts, and innovation.

Lastly, with any transformation or disruption, one must consider the actions and obstacles—whether financial, management support, or workforce ability—to embrace and enact change. Here are some key considerations to reflect on:

1. Does your firm value project management?
2. Is your firm a quick adopter of intelligence-based project software?
3. Will your firm invest in your competence development?

Post your thoughts in the comments!

References

1. PMI: Project Management Competency Development Framework—Second Edition
2. PMI: Why do projects really fail?
3. HBR: How AI Will Transform Project Management
4. Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over
5. IPAM: Will project managers soon be replaced by AI?
6. PWC: A Virtual Partnership? How Artificial Intelligence will disrupt Project Management and change the role of Project Managers
7. Proofhub: Top 10 Reasons Why Projects Fail (And How to Solve Them)

by Dave Wakeman

I was scrolling ProjectManagement.com recently, looking for inspiration and ideas for this month’s piece when I saw one author pose a question about “business context” and another one post about “business acumen.”

These got my attention, because over the years, my entire collection of posts has been about reinforcing these two points:

1. One, the business context matters.
2. Two, business acumen will make you a better project manager.

So this month, I want to reinforce the importance of your business skills to be a better project manager by highlighting two key ideas.

1. The best project manager can’t fix the wrong project. Peter Drucker said something about the worst waste of timing being doing something that need not be done at all.

One of the key ways that you can use your business skills to improve your PM performance is by understanding what projects are really going to push your business toward its key strategic goals.

This speaks directly to context. You get there with your business acumen.

Why does this matter? First, a lot of projects end up taking place due to momentum. A project starts gaining steam, no one steps in to ask if it is “essential.” It just seems important. So, it gets done.

Second, a lot of projects are done because that’s the way similar projects have been handled in the past. So, a project is just done because it is consistent with “best practices” even if there have been no lessons learned to update the process.

These scenarios highlight the importance of context and business acumen for PMs, because being able to step in and understand if a project is essential and impactful can stop the wrong projects from taking place.

2. Context is key in any situation. The best project manager in the world is still operating in a situation filled with context, no matter what.

The idea of any project, business or PM operating in a vacuum is funny, because nothing occurs in a vacuum. Great PMs know that context matters in every situation, and that context is fluid.

Andy Jordan recently wrote about there being “multiple” contexts, and that is right to a point, but it can be confusing to people. A good PM’s frame of reference for “context” in their projects revolves around the answer to the question of, “What does success look like?”

Why does this matter? One, we need to isolate the signal from the noise. I agree with Andy that there are multiple contexts for any project decision. Where I want you to focus your attention is on recognizing which one is most important.

In the modern business environment, you are never going to be able to manage all the contexts, so the process of isolation and focus matter more than ever.

So, look for the thing that is going to help you achieve “success,” whatever that means in your situation.

Two, the proper context should help you justify your project’s execution. Above, we discussed business acumen and the “right project.” Here is where context helps that come true because the context can change—and likely will change.

So, it is your job to make sure you know what success looks like so that you can place the project in the proper context to ensure that the right projects move forward.

Remember, the best project manager in the world can’t save the wrong project—and that’s where the meeting of business acumen and business context come together.

What do you think? Am I off the mark?

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

A few years ago, I replaced a contractor who was an expert in his field. We met once a week, and he answered my questions. But the domain was new to me. He was an expert, and I was not—so I thought it was normal that I didn't understand it.

He didn't write documents for me. So when he left, I spent difficult months catching up on things. Fortunately, I worked with a helpful technical expert. Then I wrote the necessary documents. We also developed a short training course. Since then, I have had to onboard colleagues, and I could use this documentation.

I belong to many teams at work (and in the volunteering setting), and I’d like to share some thoughts on how this kind of transition can be better handled. Let's call Moa, your new team member.

1. Think of the needs of the newbie. When you onboard someone new, you first need to understand what they need. This is not about you; this is about Moa. You need to take into consideration some questions:

a. Big picture vs. task only: Some people need to have the big picture to understand. Others need to understand only their sandbox.

b. Learning methods: How does Moa learn and memorize?

• Does he need to get documentation?
• Does he need to observe people at work?
• Does he need to talk with you regularly, in addition to documentation?

c. Learning rhythm: What is Moa’s rhythm to learn? I am a bit impatient and need to know what is expected from me from the outset. If I don’t know it, I become anxious. Sometimes I get feedback like “Relax! You have time.” It doesn’t reassure me. On the contrary, it makes me nervous and a bit upset because by these words, I feel like people are not listening to my needs.

d. Face-to-face meetings: If Moa is a remote team member, you’ll have to talk with his manager to plan a face-to-face meeting quickly after he joins. Perhaps a longer visit will be advantageous (and a great opportunity to gather the whole team together).

2. Define the best approach. Once you have had these first conversations, you can tailor an onboarding plan. Onboarding doesn’t stop the first week—it is a journey that can take several months and can take different forms:

• You can have weekly meetings
• You can invite Moa to your conference calls even if it isn’t directly linked to Moa’s role (and you can catch up afterward)
• You can send documents/information
• You can add Moa in the email loops and explain things

3. Demystify languages. You will also be Moa’s “translator.” The language of your team includes:

• Acronyms and vocabulary of the domain and organization
• Business language (for example, French business language is a mix between English and French)

These are the kinds of things you cannot get from training. Perhaps you have a glossary, or you can create one.

4. Uncover the unspoken rituals. When it comes to rituals, people often think of coffee breaks or after-work social gatherings. But rituals also encompass practical things about ways of working.

Perhaps Moa is more interested in those items than the coffee breaks. You can anticipate answering the following questions:

• What types of meetings do we have on the team?
• During the meetings, can questions be asked?
• Are the meetings recorded if I can’t attend?
• Are there minutes?
• How do we communicate?
• How are new ideas proposed?

5. Start early…and include everyone. With the overload at work and deadlines to catch up, your team member sometimes isn't in a hurry to train Moa. That doesn’t mean they don’t want to help him. But onboarding someone takes more time than expected.

We all manage things without writing them down. Or a process is written, but after a while, we adapt it without updating the written process. Because of that, a 30-minute conversation can last longer than expected. Moa may ask many questions, like me.

Welcoming a new member is not only the responsibility of the manager. It is even more important if Moa already works in the company. The onboarding process can start before with a handover period. Moa can begin to meet his colleagues and exchange with them.

Onboarding new members is a key process in the life of a team. It is an opportunity to strengthen ties, and also a learning opportunity for everyone.

What other things do you plan to onboard new team members?

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.