Tag: Business Analysis

The Courage to Try Something Old – Use Cases

There are many articles about project management trends for 2023. Among the common threads are a focus on AI and more automated PM tools. There are also contradictory trends like workers returning to the office or continuing to work from home. What I find most interesting, though, is that many of the trends have been around for years—like change management, agile and hybrid development methods, and focusing on benefits.[i] Does that mean that these old horses are not really trends? Not at all. It means that even when these techniques are out of favor, they are needed to successfully manage our projects.


One “old” trend I was happy to see was entitled Use Cases Are Back.[ii] Not that they’ve ever gone away. They’ve had different formats and names, like the Given, When, Then format, but the thought processes needed to develop a use case model have always been required.

To review, a use case is a model that describes how stakeholders want to use pretty much anything that’s being built, like a car, an elevator, a phone app, or a change to an existing system. But defining them is not easy. We can’t just ask our stakeholders how they would like to use a microwave or what functionality is needed in a sales app. We need to ask the right questions. And a use case model is a great tool for getting at those requirements.

A use case model, like almost all models, has both a graphical and textual component.[iii] The first component, a use case diagram, is a picture of the how the stakeholders will interact with what’s being developed. It identifies all stakeholder groups who will use the end product and how they want to use it. It also describes all the systems and other components needed to make it work. It becomes a picture of all the people and technical components, as well as all the functionality needed to make it useable. And it’s a great picture of the scope of the effort.


Some PMs and BAs have trouble getting started, so I have developed 5 business questions that can provide a jumpstart in the creation of a use case diagram.

Use Case Diagram Questions

  1. What’s being built? It’s usually called a system, but we can call it whatever we want. Examples include a new car, a change to an order system, and kitchen cabinets.
  2. Who are the stakeholders who will use this system? These are often called actors, such as an auto service consultant, a consumer, and cabinet designer.
  3. How do these stakeholders want to use the system? What functionality do they need? These are the use cases themselves. They are stated as high-level processes, like Start Car, Order Product, Measure Cabinets.
  4. What other systems or components will interact directly with the system? These are also commonly called actors, like Ignition system, Replenishment system, and Cabinet Delivery Schedule system.
  5. How will the actors and the system talk to each other? These eventually become the user interfaces that allow the system to recognize what the actor wants to do. The driver sends some signal to the Start Car use case. A consumer enters an item into Order Product use case. A cabinet designer enters measurements into a design cabinet use case.

The textual component is known as a use case narrative or scenario. It describes the process steps which detail the interaction between the stakeholders and what’s being built.




For example, how do we start the car? Does the driver put a key into the ignition? Press a button? Does the car start when the car phone app is connected and the driver opens the door? Something else? There is no one right answer. But the questions below will help our stakeholders go through the required thought processes.

Use Case Scenario Questions:

  1. How do I know where to begin? Preconditions provide the answer. They tell us where to begin by describing what has already occurred. In our example, do I already have my keys? Have I already unlocked the car? Adjusted the mirrors? More preconditions mean that the use case scenario will be shorter and there will be fewer different paths. For example, if a precondition is that I have my keys, we don’t need to document what happens when I’ve lost my keys in this scenario.
  2. How do I know when I’m done? These are the postconditions. We stop when we reach these conditions. The pre and post conditions form the scope of the use case because they define what’s in and out of each one.
  3. What is the most common way of getting from the pre to the post condition? This is the “happy path.” There are no decisions in this path, such as what happens if the car won’t start.
  4. What are other ways of getting from the pre to the postcondition? These are the alternate paths. The car starts, but it takes three tries.
  5. What prevents us from getting to the postcondition? These are the exception paths, like when the battery is dead.

Use case models are extremely useful for getting the requirements of the interaction between stakeholders and what’s being built. There are other ways of getting them, but the structure of the use case can help us focus on what questions to ask and ultimately saves time and frustration.

[i] https://www.theprojectgroup.com/blog/en/project-management-trends/; https://www.replicon.com/blog/project-management-trends/ are two examples.
[ii] https://www.projecttimes.com/articles/top-business-trends-to-watch-for-in-2023/
[iii] I’m not including a use case diagram because of the many different conventions used. What’s important are the thought processes, not the conventions.

Practical PM for Everyone

Project management is a process that, when done well, enables optimal performance. Why wouldn’t everyone want to know how to manage projects?


Everyone Has Projects

A project is an effort to create a result in a finite time. According to PMI, “a project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.”

Everyone is part of projects. Some projects are long, large, and complex, like a lunar expedition or the implementation of a new system in an organization. Others are moderate and more personal – planning a party, buying a car, moving, painting your house. Others are quite simple, for example getting up and out of the house, packing for a vacation, grocery shopping, doing the dishes, cooking a meal. Even the individual activities of regular operations like answering emails or working to close a sale fit the definition of projects. we can consider them as mini-projects.


Therefore, everyone would do well to know the basic principles of project management and adapt them to the size and complexity of the projects at hand.

Professional PMs would add value by promoting wide-spread appreciation and knowledge of project management for all.


Agile Adaptability

Applying a complex project management process with forms, protocols, and reports to manage your at home cooking dinner project or a small project that is repeated many times is not skillful.

You might like to be formal and explicit because it makes you feel good but if there are others involved you might drive them crazy and waste lots of time and effort.


At the same time, doing any project without a plan, without writing things down (for example a shopping list), with ambiguous or inadequate communication, and without looking back to learn from the experience is equally unskillful. It is likely to lead to extra trips to the store to get missing ingredients, too much or too little food, misunderstandings of who will do what, and when.

Planning, performing, monitoring, controlling, and closing happen in every project, the way we do them varies widely depending on the situation. It was the intention of the earlier founders of the agile approach to point this out and promote the idea that the project team does best to adapt practices to the needs of their project, stakeholders, and setting, while being aware of the need for a degree of structure and discipline.




The Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions     over     processes and tools

Working software                     over     comprehensive documentation

Customer collaboration            over     contract negotiation

Responding to change              over     following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”



Communication and Collaboration

To enable an adaptive and agile approach make sure that all stakeholders have a sense of  the basic principles of project management.

The basics are what everyone should know about managing a project, even if they are not managing one. Knowing the process and principles stakeholders can assess how well the project is being managed. They will be able to connect a sense of the project’s health  accomplishment and progress.


The basics are:

  1. Plan, to create a clear sense of what is to be accomplished, how, where, by when, by whom, and for how much it will cost. Remember that plans are always subject to change. Planning is not over until the project is over.
  2. Let go into execution, the performance. It’s like dance or a play. You learn the steps and your role and surrender into performing them.
  3. Mindfully monitor and control to assess progress against the plan and to adjust. Make it part of the performance so it doesn’t get in the way.
  4. Close. Take a step back to assess performance. Tie up loose ends. Learn from the experience. Turn over the results.

So simple, if there is understanding, adaptability, effective communication and collaboration.

Without these the project management process becomes a burden. With them the probability of project success goes way up.


What gets in the Way?

You’d think that everyone would be eager to apply the basics and to understand, adapt, communicate, and collaborate. But it is not the case.  The principle things that get in the way are:

  • Lack of process thinking – Thinking all that is needed is to put heads down and do the work instead of recognizing that objectives are met by skillfully applying effort to perform a set of definable steps or tasks.
  • Too much process thinking – over formalizing project management, creating unnecessary bureaucracy and overhead.
  • Not recognizing the value – thinking that the effort to manage the project is not worthwhile.
  • Thinking that it is too hard to engage others in the work required – believing that changing stakeholder mindsets about project management is impossible.
  • Personality traits – for example, closed-mindedness, impatience, fear of being criticized and controlled, and over confidence block attempts to implement some degree of planning and control.


What to Do About It

Removing the obstacles to implementing the right kind of project management (PM) requires a learning process in which PM champions convince stakeholders that PM is a practical process that adds value by upgrading performance and promoting project success.

Breaking through resistance to PM requires mindset change and changing people’s minds is no easy task.


It is not just about getting people to take a PM course, though an appropriate one, with a skilled facilitator, is a good place to start. It is committing to a dialog that addresses resistance to applying PM principles coupled with a commitment to the agility to adapt the principles to fit the projects being performed and the people who manage and perform them.

It takes time and patience with an understanding that much of the resistance is reasonable given experience with dysfunctional PM and rigid project management professionals who don’t adapt the process to the situation at hand.

Best of PMTimes: Closing a Project: What, When and How

Projects, by nature, are to be closed. I am sure you know this. The two authorities made this obvious in their definitions of what project is.


Take a moment to review the definitions from PMI and AXELOS.

A project is a TEMPORARY endeavor undertaken to create a unique product, service or result. (PMBoK Guide 6th Edition)

The above is the definition of a project by PMI (Project Management Institute), an organization founded in 1969, with headquarters in the USA and who has been providing guides, standards, and certifications, amongst other things, on project management since its inception. The key word is that definition is TEMPORARY, which literally means must have a start and end time.

Let’s move over a minute and take a look at the definition of a project from another body.

A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case (Managing Successful Projects with PRINCE2, AXELOS)

One thing is common to the two definitions. Did you see it? Yes. It’s the word TEMPORARY. A project is temporary and must be closed. Don’t confuse the term TEMPORARY with SHORT. I have got few of this concern from some of the students I train. A project can be for between 1 month and 36 months. It just means it must start and end at a particular date

Now, let me take you through the WHAT, WHEN AND HOW of closing a Project.

Note: I will not discuss whether the project is successful or failed.


WHAT is Closing A Project?

It’s has been established that every project has a start date and an end date. So, the process of completing the work on the project to an end is exactly what closing a project is. Nothing more, nothing less. If you are not closing an exercise or ending an exercise, then you need to know that the exercise isn’t a project.

It could be an operation. One of the differences between a project and an operation is that while projects are temporary, operations are ongoing and continuous. No matter how long the duration of a project is, it must end.


WHEN do you CLOSE a Project

Well, there are three circumstances under which a project can be closed. Yeah, THREE! One out of every ten readers of this article will find this surprising. Just give me a second and I will explain the three times.


1. When the project has delivered all the objectives and/or RESULT.

This is probably the most popular and most desirous time when a project should be closed. At the beginning of the project, a set of objectives, deliverables, and results were set. The PM and the whole organization rolled up their sleeves and started working towards building and delivering the objectives and deliverables for the project. Once the objective is met and the deliverables completed and accepted by the Project Sponsor/owner, it is time to close the project. Reason? The PM and the team have completed all they committed to, and there isn’t anything left to do on the project. What if there is a modification or an addition to the deliverables of the project. Well, that’s called scope creep, if there is no adjustment to other components that may be affected, and once the addition didn’t go through change control for approval, and no re-baseline, then it has to be initiated as a new project, after closing the current project.

For PRINCE2, Once the project has delivered what was specified in the business case of the project mandate, while for PMI, once it has developed the content of the approved scope.


2. When the objectives of the project can’t be met again

This is often called TERMINATION. Hopefully, it can be done early.

This is usually not a very pleasant one, but it’s usually a reality. It could be as a result of the complexity of the project or a combination of many other things. I recall working on a project with some client in the financial services industry a few years back. The business case and feasibility were highly optimistic and the organization decided to invest in the project hoping for the objective to be realized. However, after series of attempts, efforts, and re-baselining by the project team and the stakeholder, it became clear to even the blind stranger that the approach and the technology chosen for the project couldn’t meet the objective, the organization had to terminate the project for that same reason.

At times it could be that the organization had spent so much money on the project, yet they haven’t realized any benefit and at every point in time, there was no sign that the project would still deliver the objective.
Please note that in most cases, the project manager and the team are not responsible for this, and often should not be blamed.



3. When the objective of the project is no longer needed

This is often called early termination.

We live in a dynamic and constantly changing environment, and there are many actors and factors driving the market and corporate space. Most of these factors could be a technological change, a governmental policy, a change in strategy and direction for the organization etc. PRINCE2 advises that at every point on the project, the project organization should continually check for business justification, to ensure the business case is still valid. If at any point the organization realizes that the business case has become invalid, the only thing left is to close the project. A typical example was a project I was working on for a client to penetrate a new market and release a product that would solve a particular challenge. We were about 45% into the project when the government introduced an initiative that would address a similar challenge at no cost. It became obvious that the product would not make many sales, hence the objective and business case became invalid. We had to terminate the project immediately. This is better than going head to complete the project. Organizations don’t just initiate or complete a project for the mere sake of completing a project, the product of the project must be valid all through and the end product must be desired and desirable at all time.

Another example was a consulting project I was working on with a startup to rebrand the company. Midway into the project, there was a merger and acquisition with another company it became instantly known that there was no need to rebrand the company anymore. Again, this could be at no fault of the project team.

In the next section, I would highlight how to close a project, irrespective of when it is closed.


HOW to close a Project

No matter when. You need to close the project. About three years ago, I worked on a research project with about twelve other professionals to review project management processes and health check of organizations within three continents, and we found out that a lot of organizations don’t close projects well, and this is quite worrisome. As they were completing one project, the team was being drafted to other projects or assignment without proper closure process. Hence the reason I decided to write this article.

This process will be broken that into two different sections. The first section will highlight steps to closing a project whose objectives have been met, while the second would highlight the steps to close a project whose objective is either not needed again, or can’t be met.

How to close a project whose objective has been met.

  1. Confirm that all the deliverables have been completed and accepted by the appropriate approving authority. Here you will need to reference your plan, specifically your approved scope and acceptance criteria
  2. Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
  3. Close any procurement component of the project.
  4. Gather the team and update lessons learned on the project.
  5. Release all resources and provide feedback as required.
  6. Complete end of project report and archive project information.
  7. Celebrate. And I mean it.


How to close a project whose objective can’t be met or whose objective is not needed again

  1. Validate the reason for the early termination.
  2. Determine all the deliverables that have been created so far, and ensure they are accepted.
  3. Obtain formal closure notification from the Sponsor.
  4. Close any procurement engagement.
  5. Update lessons learned with the team.
  6. Release resources and complete end of project report, capturing the stage the project was at when it was closed, the reason it was closed and the lessons learned and archive project information.
  7. Celebrate (if you have the courage to).

Collaborative Relationships Between Project and Functional Managers

This article addresses the project manager/functional manager relationship with an emphasis on collaboration, reporting, expectations, and empathy.


One of the nice things about PM is that the principles don’t change much over the years. One of the disheartening things is that the problems also don’t seem to change. Collaboration remains a key to the wellbeing of organizations, particularly, the collaboration between project managers (PMs) and functional managers (FMs). It is still a challenge that hinges on clarity, communication, understanding, and empathy.


Over the years there has been continued interest in a paper I wrote 25 years ago, The Project Manager/Functional Manager Partnership[1]. The key point then as now is that there is a need for clarity regarding roles and responsibilities, priorities, and communication protocols regarding commitments and status.  Clarity leads to understanding, hopefully, resulting in empathy – a sense of feeling for others.


Roles and Responsibilities

The role of the project manager focuses on the accomplishment of project objectives – getting the work done on time, within budget to deliver a quality outcome.

The role of the functional manager, a manager of a department usually associated with a specific discipline,  is to ensure that properly trained and well motivated resources (people) are available for project work. Some FMs lead departments that perform the work as a service, while others provide resources to be directly managed by project managers.

For example, the manager of a project management office is responsible for making sure that project managers are available for assignment to projects. Those PMs report directly to a program manager or steering committee with regard to project related activities.


The manager of business analysts provides her department’s people for work on projects and programs. The BAs typically report to the project manager. A Quality Assurance manager provides testing services as well as quality management standards and procedures, and oversite in the form of audits. Testers typically report directly to the FM and not the PM. Other functional managers provide engineers, procurement experts, attorneys, and more.

The manager of a software development department may be responsible for providing programmers to work on projects and ongoing system maintenance activities. Or they may be responsible for managing the programmers for the delivery of software for projects.


Reporting To

Regardless of whether the task is to provide people or services, functional managers “report to” project managers in the same way that a contractor reports to a client.

The idea of what “reporting to” means is a point of conflict between FMs and PMs. Commonly the term means that there is a hierarchy in which the person reporting to the other is under the authority of the other.


In project work, the FM does not report to the PM in that way. The PM does not have the authority to tell the FM what to do and how to do it. But the FM does have the responsibility to tell the PM what is going on, to provide information regarding plans, estimates, projections, status, and changes to resource availability.

Part of the needed clarity is about how and when this reporting will be done. Perhaps the most critical part of this reporting process is notification of changes to commitments.




In healthy organizations FMs take part in project planning. They provide estimates and resource availability information. Where there is a well-functioning project portfolio management process, there is clarity about which projects are to be initiated when. This clarity comes from the knowledge of functional resource availability as well as the priority of each project.

So the FM not only reports to the PMs that he/she/they  serves but also to the portfolio manager. Whenever there is a change to resource availability it will impact project performance.


PM as Client

I find the analogy between FM and contractor to be helpful. A contractor knows that satisfying the client is the most important part of the job. If the client is not satisfied the contractor will suffer. Rational and empathetic clients will understand the contractor’s situation, protect themselves by being realistic in their expectations, and creating agreements that include provisions for both penalties and flexibility.

The FMs that treat the PMs their departments serve as clients deserving quality service will add greater value to their organizations and will better serve their own staff.


The FM’s Situation

The FM and the savvy PM know that there are multiple “clients” vying for the same resources. The FM needs to satisfy them all. Just like some clients, some PMs try to ignore this reality, making themselves believe that they are the only one.

Just like some contracting firms, some FMs overpromise, often caving into unrealistic demands and putting themselves and their resources under unnecessary pressure.

This leads to unreasonable irrational expectations. And irrational expectations lead to conflict, overwork, stress, burnout and missed deadlines.


That is where understanding and empathy comes into play. Effective collaboration is based on the understanding of the other’s situation leading to the ability to maintain rational expectations. This doesn’t mean to be “soft” and allow oneself to be taken advantage of. It means being reasonable and rational.

The FM needs to understand the PMs situation. If the project is behind schedule because functional resources or services are not delivered as expected, the PM will be accountable.

The PM needs to understand the FMs situation. The FM is not in control if resources are out sick or leave, or if project priorities change causing resource shifts. The best the FM can do is to report the situation as it is to the PM and portfolio manager, and be open to having project variances clearly pinned to functional performance variances.


With reasonable and rational expectations set at planning time and made part of the overall organization’s project management and portfolio management process, there will be less conflict, less unnecessary strain on functional resources, and a greater probability of project success.

If there is chronic conflict between PMs and FMs an intervention that seeks the causes and works to resolve them.


[1] Pitagorsky, G. (1998). The project manager/functional manager partnership. Project Management Journal, 29(4), 7–16 (https://www.pmi.org/learning/library/collaborative-relationship-roles-well-being-organization-2062)

Top Business Trends to Watch for in 2023

This past year has been a bit of a respite from the chaos of the last couple of years as many people have settled into working from home, in the office, or some combination. We seem to have arrived at a new normal, at least as it relates to where we’re physically working.

Fortunately, much of what we’re working on and observing from our business training is as dynamic as ever. As members of the Educate 360 family have been doing for the last 30 years, we try to keep our finger on the pulse of what we see happening that suggests trends in various areas of our business world. This year, we are organizing our trends a little differently to better reflect the interplay between the areas we are watching, such as traditional disciplines like project management and business analysis. Further, as our Educate 360 family of specialized training brands continues to grow, we can include more topics to accommodate our broadening range of knowledge and expertise that more comprehensively reflect what’s happening in the business world.


With that in mind, our 2023 Trends Watchlist includes trends in:

Project Work and Product Delivery

  • PM Skills and PM Processes
  • Use Cases are Back!
  • Business Relationship Management is a Hot Certification for Everyone
  • Wither “Transformation”?
  • From “Projects” to “Products” Continues
  • Refocusing on Value
  • PMO – “Pretty Much Over”?


Data Science

  • Text-to-Anything Models


Cloud and Information Security

  • Serverless Architecture
  • The Security Risks of Digital Nomads
  • Shifting the Surface Area of Attacks in a Remote World


Power Skills and Leadership

  • Staying Disciplined to Priorities – Adding Less to Do More.
  • The 45-minute Meeting
  • Attracting & Retaining Talent…Continued


We’d love to hear your thoughts about our observations and prognostications. Join our webinar on January 5, 2023 to hear our contributors talk about these trends, get your thoughts, and answer questions. (Date has passed.)


Project Work and Product Delivery


PM Skills and PM Processes

In the world of project management, we are noticing more awareness of separating project management skills and project management processes. Organizational leaders know when projects are not producing the results expected; the challenge is understanding whether that is a consequence of the knowledge and competencies of the people working on projects, how projects are managed in the organization, or both. Of course, good processes can contribute to better skills and good skills can help develop good processes, but they are two different things. In our discussions with clients, they are paying more attention to whether they need to work on developing the skills of their practitioners or improve their project management processes. As with any good problem-solving, understanding the cause of the problem makes for a more strategic and ultimately successful investment of resources to fix it.


Use Cases are Back!

Use cases became widely adopted in the 1990s as a core model in Rational Unified Process (RUP). They are technology independent so there are no constraints as to how they can be used. Use cases were to be written from a business perspective, in business terminology for the end users to tell a story about their expectations of the system, that is, “If I do this, this is how I expect the solution to respond.” Unfortunately, over time, use cases were co-opted by technical designers who added technical design elements to them, so they ceased to be understood by the business. Eventually, they fell out of favor except by technologists.

However, there has been a resurgence of use cases being used in agile environments and using them as they were meant to be. For example, use case diagrams are again being used to diagram conversations about which “actors” (people or other systems) will interact with the system. They are also being used to provide contextual detail to make sure everyone is on the same page about what the system will or will not do and provide a conversation holder about how the user will interact with the solution. They ensure all questions about possible alternative or exception paths are answered at the outset before these questions bog down work or slow down an agile team’s progress. They also feed nicely into test cases. All of these benefits are again being recognized – in a new type of environment.


Business Relationship Management is a hot certification for everyone.

Organizations are built on relationships. Thus, every organization needs a business relationship management (BRM) capability. Many certified project managers and business analysts are recognizing the value of expanding their capability in this power skill and even pursuing certification. It does not take away from other roles or drive the individual in a different direction, but rather empowers them to thrive with a mission to evolve culture, build partnerships, drive value, and satisfy purpose. As a project manager, BRM capabilities can optimize the value of ideation, and value management. They help link projects to organizational strategy and purpose across functions. As a business analyst, BRM capabilities focus on building partnerships and recognizing, measuring, and communicating value through effective relationship management. As an organizational change manager, BRM capabilities help build strong partnerships with people to help them move from the current state to the future state. Even executives can use this certification to support and communicate organizational factors and value to support strategy and satisfy organizational purpose.


Wither “Transformation”?

While the word, “transformation” continues to be popular both within the Agile community and within organizations pursuing a more adaptive way of working, an emerging trend within both is a growing realization that the word actually underplays the fundamental change needed to realize the desired result. Becoming agile (note the lowercase reference to adaptability versus the uppercase reference to the Agile movement) is starting to be viewed, not as an event that can be defined, planned, executed, and closed; but instead as an evolution, a fundamental shift toward becoming an organization that values learning, along with continuous small improvements, above all else in delivery of customer value. This development will come as no surprise to the founders of the movement, but it represents a significant shift for those organizations who are just beginning to understand what being “agile” truly means.




From “Projects” to “Products” Continues

While this trend began a few years back, the shift from “project-based” thinking to “product-based” thinking will continue and accelerate in the new year. The implications associated with this trend are profound. Organizations will continue to define their “products” (this is often not as easy as it sounds) and be challenged to alter how these products are staffed, funded, developed, deployed and evaluated. One specific aspect of this shift will be the continued emphasis on outcomes – the impact that a product delivery effort has on its intended users and/ or customers. This emphasis will specifically challenge organizations to truly understand who these users and customers are and identify ways to measure the value that they provide from their perspective instead of focusing on legacy measures of success such as “on-time, on-budget”.


Refocusing on Value

With economic tightening underway worldwide there will be increased pressure to define and deliver true value in 2023. “Value” is a word that remains misused and abused in many organizations. Who among us hasn’t been told, “that’s not value-add!” with no definition of the word accompanying that exclamation? With funding plentiful due to governmental subsidies during the pandemic and organizations dealing with the multitude of changes forced on them by COVID, it was easy to relax the definition of what was truly valuable. As the economic cycle trends downward and funding becomes more scarce, organizational discipline around defining and delivering “value” will only increase.


PMO – “Pretty Much Over”?

This title is a re-run of a joke that has circulated for a number of years in the Project Management and Information Technology communities. While 2023 will not see Project Management Offices (PMOs) go away, it will see a shift in both their purpose and structure.  Organizations will continue to realize that a centrally controlled office responsible for policing how individual projects are executed is not adaptive enough to accommodate the change that is ever present in today’s workplace. Instead, PMOs will shift to being smaller organizational units dedicated to laying out and fulfilling the minimum structure necessary for reporting results while, at the same time, becoming a resource that individual efforts can call upon for training and instruction in methods that speed the delivery of value (e.g., removing organizational impediments).


Data Science


Text-to-Anything Models

Recent advances in Machine Learning and GPU Cloud Computing have allowed for the creation of models that can take in text input and generate output in a completely different modality. Consumers may already be familiar with services like DALLE-2, which allows for the generation of images from a text description (text-to-image), but that is only one use case for text input generation. Recent publications have shown work in text-to-video, text-to-3dmodel, and text-to-audio. Text-to-video models allow for the generation of videos (several minutes in length) from just a text description, for example “Video of biking during a sunset” and then viewing an .mp4 output displaying the video. Text-to-3DModel has allowed for the quick creation of 3D digital assets from a simple text description and text-to-audio can generate background MP3 audio files from a simple text description, such as “audio of car alarm in background noise”. We expect to see more use of these technologies in an increasingly wider variety of applications into and beyond 2023.


Cloud and Information Security


Serverless Architecture

Most organizations that have migrated to the cloud did so by simply building out their applications in the cloud the same way they always did on-premises starting with creating virtual machines. As the cloud deployments have matured, we are seeing a shift to the serverless architecture. Instead of worrying about the size and quantity of virtual machines needed to run a given application stack, serverless allows companies to concentrate on the application itself. No longer needing to worry about the underlying instances their applications are running on (operating system and runtime updates and security patches as well as scale) developers can now focus solely on the application and its code. Services such as AWS Fargate, Azure Functions and Google Cloud Run are all examples of this serverless architecture. The move to serverless is being driven in part by cost savings. But serverless is also increasing agility and time to market of solutions.


The Security Risks of Digital Nomads 

The pandemic caught many companies off guard when employees needed to start working from home. It was a challenge for those organizations that must comply with regulatory requirements to make sure their staff was able to access personally identifiable information (PII), protected healthcare information (PHI), and financial information in a secure manner. Many have succeeded in creating a secure environment for those that gain access to sensitive information from home by implementing Administrative, Physical, and Technical controls. As companies continue to allow employees to work from home, a new trend will emerge to compromise the assets that support the critical business processes.


Shifting the Surface Area of Attacks in a Remote World

Hackers will no longer focus on directly attacking a company’s network; a new emphasis will be placed on compromising the end user’s personal accounts and applications used on the same computers gaining access to corporate data. Security professionals will need to focus their attention on the increase in social engineering attacks and phishing emails designed to gather information from the computers being used for remote access. The cached information in memory, temporary files and on the local hard drives on a compromised machine will be a treasure trove for hackers.




Staying Disciplined to Priorities – Adding Less to Do More

As 2023 brings in another year of unprecedented access to data, leaders continue to be inundated with inputs to inform decision-making and prioritization. This access to information is generally positive for leadership but it elevates the need for more disciplined prioritization. Prioritization allows individuals, teams, and organizations to ensure that they are spending time, money, and other resources on the most important initiatives. Priorities can be defined by helpful frameworks to assess the nearly unlimited options a leader has to steer a team forward.

While it may be tempting to take immediate action with the new information presented and regularly add priorities to pursue new opportunities, the best leaders will remain disciplined to ensure that new information enhances ongoing priorities and that new initiatives are not considered for addition until progress is beyond a certain point. When a leader declares something a priority, it should have a strong and clear rationale for pursuit but also have clear checkpoints of progress along the way. This allows the team to stay focused on the end vision of that priority, while also allowing for pivots and tactical changes as necessary with the infusion of new data and information. Too many priorities with too little progress can have a detrimental impact on team productivity and morale.

Priorities can also serve as a fantastic filter for a team’s time allocation – does what I’m about to work on relate to our organization’s priorities? If not, I’m going to limit my time dedicated to it so I can get back to the things that will drive the progress against our organization’s priorities! The pressure will continue to increase for leaders to help their organizations stay disciplined in their priorities, despite temptations to chase after new opportunities with continuous cycles of new data and information in order to accomplish more against their stated priorities and keep their team members engaged and energized.


The 45-Minute Meeting

A tactical leadership trend starting to emerge and likely to increase in popularity in the coming year is the notion of the 45-minute meeting (…or the 25-minute meeting). Three years into the remote / hybrid work environment because of the global pandemic and let’s face it: it is not uncommon to have long stretches of your day in back-to-back virtual meeting environments barely leaving room for a bio-break or scrap of food. We’re all tired!

A simple way to improve productivity and employees’ mental health in the current virtual communication environment is to reduce the duration of meetings. Just because calendar invite preferences default to 30-minute increments, does not mean that they cannot be adjusted. And as meeting durations get customized, people are being more intentional about the time spent virtually collaborating – like sending agendas in advance to help cut down on the awkward silences and gaps to figure out where to take the discussion next or sending relevant materials before the call to provide additional time for digestion and contextualization. The lack of complaints from the recipients of invitations to shorter meetings is also likely to continue. It turns out that the vast majority of people appreciate a few minutes to refill their coffee!


Attracting & Retaining Talent…Continued

This will sound repetitive from last year, but the key leadership issue we are still hearing about is attracting and retaining talent. While the underlying drivers are slightly different, this theme is still the same. A year ago, there was a lot of talk about returning to the office and a hot labor market making people more prone to leaving. While these issues are still there, as a return to office has happened in all sorts of grey ways, and some rumblings of the labor market getting just slightly less hot, these have become just two of multiple factors and not so much THE factors driving the attracting and retaining talent challenge.

What has become the driver is broadly making the workplace one that people want to join and at which they want to remain. This is clearly stating the obvious. However, it seems like the obvious has too many factors to consider: pay, benefits, work-life balance, mission, advancement, fulfillment, feeling welcome, and enjoyment, just to name a few. (As you can see, last year’s prominent topics of COVID-related items and hot labor market are subfactors in this list).

Balancing all of these items seems impossible considering that they are of unique and varying degrees of importance and priority to every individual. It is becoming clear that the simplest answer to hitting the mark on those factors might be the only answer and that is to focus one level up: Is this a place at which people want to work? That simpler question is easier than constantly thinking the next level down to the tens if not hundreds of levers and dials that one tries to get right. Are people happy with what they are doing, do they feel welcome, do they feel they are well-compensated at work?

We can’t get every dial perfectly right and by no means are we saying we can get things right for everyone, but in aggregate, using common sense and basic human empathy can really be the only formula – all the dial-turning is more art than science if you use your common sense and empathy as a leader. Unlike last year when leaders tried to get the exact right formula for inspiring people to return to the office, now with no one item being the most important to everyone, leaders just need to look, listen, and act wholistically to make their company a place at which people want to work.




Educate 360 Professional Training Partners upskills individuals with the Management & Leadership, Data Science, and IT skills needed by technology-led and innovation-driven organizations. Educate 360 is comprised of specialized training brands with footprint throughout the U.S. and Europe including Pierian Training, Project Management Academy, Six Sigma Online, United Training, Velopi, and Watermark Learning.

Jason Cassidy, PMP, is CEO of Educate 360.

Andrea Brockmeier, PMP, is Director of Project Management at Watermark Learning.

Ken Crawshaw is Senior Principal Technical Instructor for United Training.

Amy Farber is Chief Strategy & Commercial Officer, driving growth initiatives across Educate 360.

Dr. Susan Heidorn, PMP, CBAP, BRMP, is Director of Business Solutions at Watermark Learning.

Norman Kennedy, MCT, AAI, is a Cloud and Security focused Senior Technical Trainer at United Training.

Jose Marcel Portilla is Head of Data Science at Pierian Training.

Mike Stuedemann, PMP, CST, is a Scrum-Focused, Agile Agnostic Coach and Trainer at AgilityIRL and partners with Educate 360 for Scrum Alliance courses.