PMI Global Insights

By: Lisa DiTullio

Is it a fad?

The World Economic Forum indicates that over one billion people around the world will need to be reskilled by 2030. The Project Management Institute tells us that 25 million new project professionals are needed within the same time.

Business coaching isn't a fad – it's a necessity.

For project managers, coaching others has become an essential leadership skill, but do we know what a “project coach” looks like? Years ago, my success as a project manager was secured by knowing what needed to be done and doing my best to deliver. As I transitioned into leadership roles, I relied on my knowledge and acquired experience to guide my teammates on how they should get their work done or solve big problems. In other words, I would lead others by reproducing my previous successes. Not only was this approach self-serving, but it also didn’t allow my team members to fully shine on their own.

In today’s world of unrelenting change, the one thing we know is what succeeded in the past may no longer work. Today’s business environment is a tornado of rapid, constant, and disruptive change, making business coaching more important than ever. To succeed in our new reality, we must adopt new ways to challenge team members, so they flourish and grow. With so much to do and so little time, how do project managers successfully stretch and develop others while getting the work done? It happens through the art of asking versus telling, and by acquiring keen listening skills.

While the practice is a dramatic and fundamental shift in traditional leadership behavior, it can be easily learned. In this three-day immersive learning experience, you will switch your mindset and your behavior from telling to asking. Instead of telling team members what to do, you will develop skills on how to ask the “right” questions to team members who are stuck or looking for answers. By adopting coaching techniques, you will encourage new thinking and creativity by challenging individuals to come up with the answers or ideas for themselves, including team members who appear to be difficult to coach. Why is this so valuable? Because it builds their self-confidence, develops new skills, and frees up your time.

Interested in learning more about training specifically developed by project management experts for project managers in a small group setting? Explore upcoming sessions on the PMI Training website and learn more about my upcoming virtual session, The Complete Project Coach, taking place from 19 – 21 November.

By: Klaus Nielsen, MBA, PMI-ACP, PMP

Last year, I presented a one-day course several times for PMI Training that focused on Project Management Principles, which resulted in various reflections, feedback, and discussions that this year's participants have benefitted from.

For those of you who have not yet experienced the course, it is a full day focused on only project management principles. My journey started when I was on the core development team for the PMBOK® Guide – Seventh Edition, whereas by now you know project management principles play a significant part.

Project management principles are a bit of a paradox, explaining the why or, “principles can be understood as fundamental truths or propositions that serve as the foundation for a system of behavior or reasoning,” but also complex to truly master. Let me illustrate what some of our discussions from the courses are all about.

Firstly, we need to have a mutual understanding on what is a project management principle. Yes, we can do that, but which project management principles to use (sorry, it is not just the PMBOK® Guide – Seventh Edition principles) and where are they derived from? This is trickier.

What if some are working agile or others are working predictive, are the project management principles the same? Then add a framework like Scrum, SAFe, Disciplined Agile, or similar and those sets of principles. Wait, beside the PMBOK® Guide – Seventh Edition, do we not also have universal project management principles? Yes, we do. As you can see from these cases, this is complicated. Most participants state they would like to follow some of the project management principles which are relevant to their context. However, how would they really know (think compliance) that they are following the project management principles stated? And if so, what are the benefits of doing so or disbenefits of not doing so?

These are just some of the related questions we discussed, and more are included, as the wisdom of many others is included in the course.

This was an enjoyable and invigorating course and I look forward to offering Mastering Project Management Principles with Klaus Nielsen again on November 20. Visit the PMI Training website for more details.

By: Carlene Szostak

Chatbot technologies, Deep Learning Methods, Generative Adversarial Networks (GANs)… those words weren't part of mainstream business just a few years ago, but that is no longer true.

AI has quickly gone from a niche entity to a big deal, shaking up all industries. You can't go a day without hearing about the latest AI breakthroughs, their impact on our status quo, and the benefits of these advancements. It's not a question of if AI will shake things up; it's more about when and how much. However, there is one part of the AI story that often gets overlooked. Do you have any thoughts on what that might be?

But first...

An important thing to remember is that even with everything AI can do, AI is not fluid. The data currently is not real-time. If  you ask Microsoft Copilot or ChatGPT, they’ll reveal their “training data” was last updated in September 2021 and January 2022.

The "training data" is the foundation for building AI models. You notice the quote - yes, "training data." This means the model is exposed to diverse texts from the internet, books, articles, and other sources, which is the information they provide. This data is used to teach the model to understand language patterns, context, and relationships between words and phrases. As AI expands, I have seen the addition of this phrase: “My responses are based on the knowledge available up to that time. While I strive to provide accurate and relevant information, it's essential to verify the information I provide with more current sources, especially for rapidly changing topics like technology, news, or events.” ¹

Now that we all have a basic understanding of AI functionality, let's talk about what no one is talking about. FACT: AI is not just transforming industries, but the very fabric of human existence. Alright, I might sound a little dramatic, but there are real concerns about privacy, bias, job displacement, and the overall impact on society; we have entered "The Brave New World." ²

Ninety-two years later, this brave new world is now, and it raises important questions about the ethics of AI, algorithm biases, and the potential for AI to worsen existing social inequalities. It might sound deep and intellectual, but as project managers, we need to keep on top of this technology and peel back the layers of AI. Yes, the complexities are evolving daily, every minute, and every nanosecond, but its implications for our future can't be overlooked.

With full disclosure, I have to share that I love AI. I have experienced how AI is an invaluable asset in risk management and using AI-powered analytics for identifying, assessing, and mitigating potential risks. Plus, AI can spot patterns that we humans might totally miss.

But with all these advancements, there are some challenges to face. All industries must adjust to the rapid pace of technological change and carefully navigate ethical considerations surrounding AI. How do we make sure we're using AI in a way that aligns with societal values and is used responsibly?

To tackle these ethical challenges, businesses need to ensure accountability, honesty, and fairness when using AI systems. This means ensuring that AI algorithms are not biased, keeping customer data safe, and giving clear rules to employees, stakeholders, customers, and regulators about how AI will be used in the company. Is this a perfect solution? No, but it is something we can start today, and we should always keep working on it instead of just saying, "mission accomplished."

AI offers many new opportunities for businesses to thrive and grow. However, integrating AI into your operations can be risky. We must be careful not to rely solely on AI as the ultimate authority. Yes, AI is a powerful tool, but it can never replace the importance of ethical and critical thinking. We need to ensure that we use AI as a trained assistant and not as a replacement for human judgment.

Join me at any one of the upcoming PMI Training sessions this year: "Artificial Intelligence Revolution: Empowering Project Managers for Success." In this four-hour session, we'll delve into the world of AI, discussing its challenges, value, and everything in between. Come join us to expand your knowledge of AI and what it means for you.  This training is scheduled for PMI MAX Orlando in June, September Virtual  and November Virtual.  

^{1: Source: ChatGPT}

^{2:  “The Brave New World" is a dystopian novel written by Aldous Huxley, published in 1932. Set in a futuristic world where society is controlled by technology and conditioning, it explores themes such as the dangers of a totalitarian government, the loss of individuality, and the consequences of sacrificing freedom for stability.}

By: Klaus Nielsen, MBA, PMI-ACP, PMP

I have been working with the business case for years. Sometimes it’s a one pager and sometimes it’s 100+ pages illustrating the diversity we need to address. It’s my experience that most practitioners fully understand what a business case is all about – “A business case says: ‘Here is what needs to be done’ and backs it up with evidence.”

However, what are we using the business case for? Is it just approval & getting the money, or something more? What it contains varies very much by the context. Most business cases contain the project description & context, the cost, benefits, risks, executive summary, scenarios and so on, but how it’s covered and the details vary upon the context and pages available. This means that for each section of the business case, the type of content may vary greatly depending on the context. 

We have solved this problem by creating process goal diagrams, which some might recognize from Disciplined Agile. That means for each section of the business case, we present an option list, so the choices for ways of working/tools/techniques are clear to all. 

Let’s say you are going to write the section of the business case describing the reason for doing the project. Some of these options might include opportunity statement, problem statement, study or POC result, project type/categorization, internal/external factors, cause and effect diagram, SARIE, and so on. Choices are great and foster important conversations about our ways of working. To support this, we have created and collected templates for many of these options, so at the end of the training everyone has a comprehensive collection of templates to bring home. During the training, everyone can choose which templates to use for different sections of the business case, which provides flexibility and, when the results are presented, the application of the various templates are illustrated as most groups select different templates to work with.

Sorry to break it to you, but many business cases are somewhat flawed. Most business cases have underestimated the costs and overestimated the benefits. This is a common problem. Taking optimism bias into account might reduce this problem. A simple way to apply optimism bias is the use of weights, so estimates of costs are increased with a factor. This is just one example of some of the problems organizations are facing and we aim to discuss and possibly solve during the training. Other topics are around the business case in an agile environment (Do we need it? If we need the business case, then how much/little to include? Alternatively, a business case is a business case regardless of ways of executing it), the use of risk management related to the business case, for example, and the probability of higher costs or lower benefits, not just execution risks. 

We have been running this course multiple times a year since 2020 with participants from most parts of the world, where the wisdom of all these people has been included in the material together with leading research, best practices, and the national standards from the United Kingdom, for example, which have turned this course into a truly international course and content which many may benefit from.

I look forward to offering Business Case—Best Practices for Success with Klaus Nielsen again March 20-21 and September 16-17. Visit the PMI Training website for more details.

By: Scott L. Bain

A developer was working for a large financial company. The company leaders had an idea for a new product that would allow their customers to participate in foreign stock exchanges without having to stay up all night to time their transactions.

There would be many things to develop. A website that allowed customers to enter buy, sell, limit, and margin orders throughout the day to be transacted later when the foreign markets were open. A database would store all these accumulated transactions. Marketing would have to come up with a plan to promote this new product. Also a component, running on the server, would trigger at midnight to access a web service and commit these transactions as a batch.

The developer in question was assigned to create that timed component. The requirements seemed rather simple: The component would run on the main server and watch the system clock.  At midnight it would activate, retrieve all the transactions that had been stored throughout the day, open a connection to the external service, commit the transactions in the order they were entered, receive a confirmation code from the service, and write a log entry into the company’s daily activity log that included that code.

They knew how to open that web service connection, what the correct logic was to “commit” a transaction, and how to access the company’s logging API. Of course, they knew was “midnight” was. They met with the database administrator to learn the exact nature of the SQL table that would hold the transactions and what key to use to retrieve them in order. All of this seemed relatively familiar and straightforward and so they gave a low estimate on time and effort needed to get the work done.

Indeed, they got the component finished well within that time frame and checked the code in. The website and marketing were still in development and so they moved on to other work.

A few weeks later, the rollout of this new service was scheduled for a Monday. The day arrived and the product launched. It was immediately popular; many transactions were entered all throughout the day and everyone was enthusiastic about the product. The developer went home at the end of the day confident that the component would trigger at midnight and process the orders.

In the wee hours of the morning, they received a text. Disaster occurred; everyone was being called into the office. None of the transactions had gone through and they were anticipating many unhappy customers, perhaps even some legal action taken against the company. The developer went into work feeling a sense of puzzled dread.

What had gone wrong?

The transaction batch did not commit on time. It was too late. An SEC rule stated that if not every transaction was committed then none of them could be as a matter of fairness, so the external service had rejected the entire batch. Massive financial implications were the result.

This developer was relating this story to me a couple of years later.  I knew this person because they had been a student in several of my courses and in them had studied design, analysis, and testing.

“I didn’t know there was a deadline, a window past which the transaction would fail,” they said.

“An unasked question; that’s often the problem,” I replied. 

“Sure,” they said, “but then I realized something.  Even if I had known what that window was, I had accepted the requirement that the batch commit had to happen at midnight.  At midnight.  Nothing can happen at midnight.  Midnight is an infinitely short period of time and computers are not infinitely fast, and neither are internet connections.  Once it is midnight, it is immediately after midnight, right?  So what did the requirement actually mean?  By midnight?  Then how long before midnight should or can I start?  Starting at midnight?  Then how long do I have?  Also, this SEC regulation about all-or-nothing was something I had no idea about.”

“It sounds like this was not your fault,” I said.

“I guess not,” they replied, “but I realize that now, today, the way I work would have prevented this.  Today I would be driving everything from tests and the tests themselves would force me to ask the questions I didn’t.  The acceptance tests would make me ask ‘how will I know if I’ve failed?’ because I would need to start with a failing test.  Also, I would have realized the SEC was a stakeholder to my work and I would have included someone who understood their perspective.  The unit tests would force me to think carefully about the design of the component itself so I could do things like test it without having to execute the test at midnight in my pajamas.”

“Separation of concerns,” I said.

They smiled.  “Exactly. I now know how to achieve that without overcomplicating my designs.  But the real crux here was the fact that I didn’t understand what the requirements really meant, because the communication and collaboration had failed.  I lost that job as a result.”

This is not uncommon, unfortunately.  Communication, especially between technical and non-technical people is extremely unreliable.  Even when everyone intends well, there are too many mismatches among perspectives and too many questions that are missed.

Acceptance Test-Driven Development (ATDD) seeks to address this problem in a fundamental and comprehensive way.  How can we achieve a complete, meaningful, shared view of the product that is being proposed?  How can we record the results of the collaboration in a way that can be validated against the actual work as it is completed?  How will we know when we’ve succeeded?  How will we know when we’ve failed?

ATDD is a framework for highly effective collaboration across all parts of an organization.  It produces tests, but is not a testing activity.  It is a way to ensure that a product’s requirements are fully understood, including everyone’s perspectives. 

It is not a difficult framework, but it is essential if you want to ensure that everyone is on the same page and that the work to be done will be in complete alignment with the business value that drives it. It is something that everyone needs to know how to do.

Join me at PMI Training 17-18 April for NEW! Acceptance Test-Driven Development: Improving Communication, Empowering Collaboration, and Creating a Shared Specification for New Products with Scott Bain (pmi.org). 

Interested in learning more about trainings specifically developed by project management experts for project managers in a small group setting? Check out the PMI Training website for upcoming offerings.