Category Archives: Agile Project Management

What is an Agile Project Manager?

I’ve participated in some discussions recently that indicate that there is still a lot of confusion and controversy about what is an Agile Project Manager is. It’s understandable why this confusion exists:

  • There have been some very strong stereotypes built up over many years of what “project management” is and what a “Project Manager” is.  Those stereotypes are centered around the belief that “project management” is limited entirely to traditional plan-driven project management and project managers are so heavily engrained into that way of thinking that they can’t possibly adapt to an Agile environment.
  • PMI has made a step in the right direction by introducing the PMI-ACP certification.  That certification at least recognizes Agile as a legitimate form of project management but PMI has never really defined exactly what an “Agile Project Manager” is and what role he/she might play in the real world.
  • Many people think of Agile in a very narrow sense as limited to simple, single-team Scrum projects; and, because there is no “Project Manager” role defined at that level, they assume that there is no role for Agile project management at all in an Agile environment; however, there is more to Agile than simple, single-team projects.

In order to better understand what “Agile Project Management” is, we need to get past these stereotypes and develop a broader vision of what “project management” is, what “Agile” is, and what an “Agile Project Manager” is.

First, we need to recognize that the discipline of ”project management” isn’t limited to traditional, plan-driven project management with an emphasis on planning and control just because that’s the way project management has been typically practiced for many years.  There is actually a lot of “project management” going on in an Agile project although it may not look like the traditional, narrow view of what project management is at all:

  • It’s a different style of project management with an emphasis on taking an adaptive approach to maximize the value of the project in an uncertain environment rather than the traditional emphasis on planning and control; however, if you take a broader view of what “project management” is, it is still project management.
  • And, although you may not find anyone with the title of “Project Manager” at a team level in an Agile project, there’s a lot of project management going on – the project management functions that would normally be performed by an individual with the title of “Project Manager” have just been distributed among the other members of the team:
    • The Product Owner has a lot of responsibilities that might be performed by a project manager in a traditional plan-driven project.  He/she is responsible for the overall successful business outcome of the project which means delivering a valuable product in a timely and cost-effective manner and making all decisions that would normally be done by a Project Manager for risk management as well as planning and managing the overall effort.
    • The Scrum Master also has some responsibilities that might be done by a project manager including removing obstacles and facilitating the project team.  It may be a different style of leadership, but it is still leadership.
    • And, finally every member of the development team has some project management functions on a very small scale for planning, scheduling, tracking, and reporting on their own work as well as the work of the team as a whole.

A related stereotype is that many people think that there is a binary and mutually exclusive choice between “Agile” and “Waterfall” and try to force-fit their projects to one of those extremes when a better approach is to go in the other direction and fit the methodology to the project.  And, “Agile” and traditional plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two.  There are many projects that call for blending those two approaches in the right proportions to fit a given situation particularly as you get into larger, more complex, enterprise-level projects.

So what is an “Agile Project Manager”?

In my opinion, an Agile Project Manager is equally trained and skilled in applying both Agile and traditional plan-driven project management principles and practices and knows how to blend them together in the right proportions to fit a given situation.  That is exactly what the training I’ve developed is all about – it is designed to:

  • Help people see “Agile” and traditional plan-driven project management in a fresh new perspective as complementary rather than competitive, and
  • Help project managers better understand what “Agile Project Management” is and what they need to do to prepare for it

So What role might an “Agile Project Manager” play in a real-world project?

I think it’s sad that some project managers see there only alternative in an Agile environment is to become a Scrum Master because the role of an Agile Project Manager is so ill-defined and poorly-understood.  I hope that the Agile Project Management training curriculum I’ve developed can help project managers see this new perspective and lead the rest of the profession into demonstrating successful Agile Project Management leadership. In my training, I’ve identified several potential roles that an Agile Project Manager might play:

  1. Team-level Role – There is officially no role for an “Agile Project Manager” at the team level in an Agile project; however, a project manager who is skilled in blending Agile and traditional plan-driven project management principles and practices can play a real value-added role as either a Product Owner, a Scrum Master, or an Agile Coach
  2. Hybrid Agile Role – For lots of reasons, companies choose to implement a hybrid Agile approach and this is an ideal environment for an Agile Project Manager to work in. An example would be an Agile contracting situation.
  3. Enterprise-level Role – As projects grow in scope and complexity to an enterprise level, there is a much more significant need for a dedicated Agile Project Manager role. As an example, I did a case study in my latest book on a project at Harvard Pilgrim that involved over 100 Agile teams – you just can’t do an effort like that without some form of project/program management

My training includes much more detail on this and several real-world case studies illustrating each of these roles.

What’s Next After Agile?

I recently saw a discussion on another forum where an individual raised the question of “What’s next after Agile?” and someone speculated that the next big methodology might be Lean.  I’ve also seen some people suggest that Kanban will become the next big methodology.  I’ve seen this pattern before – I call it the “Program Du Jour” pattern.  Here’s one of my favorite quotes on this subject:

“Americans are our own worst enemy when it comes to new business concepts. We love novelty and newness. We become so enamored with new ideas, we burn through them the way a child rips through toys on Christmas morning – squeals of delight, followed by three or four minutes of interest, then onto the next plaything. That is our pattern with new management techniques, too.

Barry Sheehy, Hyler Bracey, & Rick Frazier, Winning the Race for Value, American Management Association, 1996

The above quote was about business concepts and management techniques but the same thing can be said about methodologies.

Here’s an example – when Six Sigma came into vogue in the 1990’s and early 2000’s, it was really hot, everyone wanted to jump on the Six Sigma bandwagon, and any other earlier process improvement approach was considered obsolete and passé.  I published my first book on Business Excellence in 2003 and I interviewed a number of companies for my book at that time.  What I saw was that:

  • Many companies were doing Six Sigma very superficially and mechanically. In these companies there was a lot of “hoopla” and very visible ceremonies about Six Sigma including Black Belts, Green Belts, etc.  The implementation in many of these companies was not very successful because the company was looking for a “silver bullet” and when it didn’t meet their expectations, the company tossed it out and started looking for the next “silver bullet”.
  • In other companies where I thought Six Sigma was more successful and lasting, there was a big difference.   Six Sigma was seen only as a tool and not a “silver bullet” or panacea,
    people in the company understood Six Sigma at a deeper level, and the implementation was not just mechanical and superficial.   Six Sigma was so well-integrated into the way the company did business that it might not even have been very visible that it was Six Sigma and they might not even have called it “Six Sigma”

I see a similar pattern with Agile today.  Many people today see “Agile” as a “silver bullet” or panacea for almost any problem you might have; in many cases the implementation of Agile is superficial and mechanical; and, when it doesn’t work, there’s a tendency to toss it out and look for something new to replace it.  I think that kind of thinking has some serious flaws.

Rather than Agile being replaced by something new, what I hope that will happen is that:

  • People’s understanding of Agile will mature, they will start to understand the principles and values behind it at a deeper level, and they will go beyond superficial and mechanical implementations
  • People will stop seeing Agile as a “panacea” or “silver bullet” for any problem you might have and rather than force-fitting all problems to some particular methodology like Agile, they will recognize the need to go in the other direction and fit the methodology to the problem
  • People will also recognize that “Agile” does not make all other management approaches obsolete and passé and:
    • There’s a need to see Agile and more traditional plan-driven approaches in a fresh new perspective as complementary rather being competitive
    • Various Agile approaches such as Scrum, Kanban, and Lean are also complementary to each other rather than competitive

This is exactly the kind of thinking I’ve tried to help people develop in the curriculum in the new Agile Project Management Academy.  To learn more about that, you can check it out here:

Agile Project Management Academy

Agile Project Management Academy

I am very pleased to announce the opening of the Agile Project Management Academy! The Agile Project Management Academy is an online school that is dedicated to helping project managers and other students learn how to successfully integrate Agile and traditional plan-driven project management principles and practices in the right proportions to fit any situation and to develop a very high impact and adaptive project management approach that provides the best of those two worlds.

You can enroll in the Agile Project Management Academy at no charge by clicking this link. There is no obligation to purchase a course if you enroll in the school and enrolling in the school will keep you informed of new courses and discount offers that become available. You can also enroll in either of these two free courses to try it out with no obligation:

Any of my Udemy students will recognize the courses in the Agile Project Management Academy as courses that have been offered on Udemy that have drawn over 10,000 students and over 300 5-star reviews. I will continue to offer these courses on Udemy; however, offering these courses through the Agile Project Management Academy creates some new opportunities that were not available on the Udemy platform. The new platform provides:

  • A dedicated focus on Agile Project Management that will help students realize the full benefits of these courses in a much more integrated environment
  • More ways for students to take courses including bundled discounts and subscriptions
  • Much more capabilities for direct communication with students to create a more interactive learning experience
  • The ability to integrate courses from other providers with my own courses to provide a more complete learning experience
  • Better and more timely support for students

I hope you enjoy this new capability! I am very excited to make it available! Enrollment in the school is free and anyone who registers in the school will receive email updates of new courses as well as enhancements to existing courses. You can enroll in the school at no charge here:

Agile Project Management Academy

You can find a summary of the courses that are offered as well as some discount coupons for all of the courses here:

Course Summaries and Discount Coupons

Please send me an email if you have any questions or comments on this new capability:

Send email to Chuck

For any student who has previously purchased one of my courses through Udemy, I will be happy to provide access to the equivalent course in the new Agile Project Management Academy at no charge. If you would like to take advantage of that offer, just send me an email.

What Certification Should I Get?

I’ve gotten lots of questions from students in my Agile Project Management training along the lines of “What certification should I get?”. It’s understandable that there’s a lot of confusion about this because there is so much change going on in this area and it can be somewhat of a moving target to decide where to take your career direction; however, I’m not a big fan of chasing after certifications and I’d like to share some of my thoughts on that subject…

First, a lot of people seem to view a certification as a “ticket to get a new job”…For example, almost anyone can get a Certified Scrum Master (CSM) certification if they can pay the money to sit through a 2-day training course. And, various training companies have done their best to promote this idea in order to sell their training courses. There are literally hundreds of what I call “exam-cram” courses out there that are designed to get you through a certification exam and little more than that. I don’t think that’s healthy – it does a disservice to the profession and to the people getting those certifications.

I think a better way to view a certification is evidence that you already have an acceptable level of knowledge, skills, as well as actual experience to perform a given job. Unfortunately, that’s not universally true in the way many certifications are designed and implemented in the real world, but that’s a better way to look at certifications in my opinion.

Here’s the approach I recommend to my students:

  1. Get a good base of knowledge to make a sensible decision of what you think is the best career direction for yourself. This is not an easy thing to do because the whole area associated with Agile and; in particular, Agile Project Management is rapidly evolving and the roles in this area are also changing and evolving. It can be a moving target to try to plan your career direction in this environment.
  2. Once you’ve made a decision on your most logical career direction, work on developing some more knowledge that is specific to that career direction
  3. Acquire some real world job knowledge from working in that role
  4. Decide what certification is most relevant to that role and get a certification to show that you have the appropriate knowledge, skills, and experience to do that job

A lot of people seem to want to short-circuit this process and just go out and get a certification and get a job and I think that could be a big mistake without doing steps 1-3 above first.

All of the Agile Project Management training courses I’ve developed are designed around helping people take a sensible approach to exactly this problem but you have to realize that it’s not just a matter of taking an “exam-prep” course and then going out and taking a certification exam. My courses are not really designed to be “exam prep” courses – they go beyond that and try to focus on the knowledge and skills to do the job in the real world. You can find information plus current discount coupons on all of my courses here:

http://agileprojectmanagementacademy.com/courses

In particular, my “How to Prepare for PMI-ACP Certification” course is a free course and has some very good information to compare various certifications related to Agile and Agile Project Management. If you have any questions about your own career direction, feel free to send me an email and I’ll be glad to help:

Send email to Chuck

My Methodology is Better than Your Methodology

There are a lot of people who get caught up in what I call “methodology wars” where they are intent on their position that my methodology is better than your methodology and whatever methodology they advocate is better at solving any problem you can possibly imagine than any other methodology. You can see this in the many “agile versus waterfall” discussions and other discussions where SAFe, Kanban, or some other methodology/framework is positioned as a “silver bullet” for any problem you might have. They also tend to ignore all other methodologies as obsolete or irrelevant.

The truth is that all methodologies and frameworks have strengths and weaknesses depending on the situation and the right approach is to fit the methodology to the situation rather than force-fitting a problem to some pre-defined methodology. Sometimes that may require customizing a methodology to fit the problem and/or using a combination of elements from different methodologies. It’s a lot more difficult to do that, but it can be done – it requires:

  • Knowledge of a broader range of methodologies and frameworks,
  • Ability to see the strengths and weaknesses of those methodologies objectively, and
  • A deeper understanding of the principles behind those methodologies to know how they might be combined to fit a given situation

Here’s an example – I just finished adding some material on “Lean Software Development” to my online training courses on Agile Project Management.  Lean is not widely-used as a standalone methodology and it clearly didn’t win the “methodology wars” but the principles behind lean are the foundation for all Agile methodologies including Scrum.  If you look at the principles behind lean, they may appear to be at odds with other Agile methodologies:

  • Lean heavily emphasizes eliminating waste in a process to improve efficiency, while
  • Agile is more heavily-focused on taking a flexible and adaptive approach to meet customer needs and is less concerned about just eliminating waste

If you pursued each of these goals in isolation and to an extreme; they might be in conflict with each other, but if they are blended together in the right proportions to fit a given situation, they can be very complementary rather than competitive.

Here’s another example – many people seem to believe that all forms of traditional project management are obsolete and irrelevant and have been totally replaced by Agile.  On the surface; if you look at traditional, plan-driven project management and Agile, they may appear to be at odds with each other; and if each approach is pursued in isolation and to an extreme, they probably will be in conflict but that shouldn’t preclude blending the principles behind the two approaches together in the right proportions to fit a given situation.

This kind of thinking is commonly called “Systems thinking” – it requires seeing a problem in a holistic context and understanding the dynamics of the problem at a deeper level rather than mechanically imposing a predefined solution on a given problem.  This is the kind of approach I’ve tried to help students develop in all of my online Agile Project Management training courses.

Agile Project Management Roadmap

I recently published an article on “Preparing for the PMI-ACP® Exam“. I want to expand on that article in the broader context of: What is the “Agile Project Management Roadmap” for a Project Manager with little or no Agile experience to become a well-qualified Agile Project Manager and where does PMI-ACP® certification fit into that process? Here’s a simplified, high-level diagram that shows what I think that process looks like and how the online training I’ve developed fits into that “road map”:

Agile Project Management Training Roadmap

Here’s some notes on this “road map”

  • It’s important to recognize that the typical Project Manager who has little or no Agile experience can’t just go out and take the PMI-ACP certification exam (even if they took at least 21 hours of training first), you need at least 1,500 hours of experience in an Agile environment to qualify to take the exam
  • In order to get 1,500 hours experience in an Agile environment, you need some knowledge to be able to perform that role. That’s the primary need that my current online training courses fill. Those courses provide an excellent foundation and an equivalent level of knowledge for most of the topics required for PMI-ACP but it’s more focused on preparing someone to assume a real-world role rather than “exam prep” training
  • After you get the 1,500 hours of experience, you need to take an exam-prep course before you can take the PMI-ACP® exam. A total of at least 21 hours of training is required to qualify to take the exam. My courses, as they exist now, will satisfy about 7.5 hours of this requirement
  • Finally, it’s important to recognize that getting PMI-ACP® certification doesn’t immediately give someone the skills to get a job. PMI-ACP® certification is a test of general Agile knowledge and is not oriented around qualifying someone to perform a particular role. This is a very controversial topic; but, in general, there is no role for an Agile Project Manager at the team level in an Agile environment, the typical role for an Agile Project Manager would be at a higher enterprise level and PMI-ACP® definitely does not prepare someone for that role. That’s requires additional training beyond the level of PMI-ACP® certification and that’s the need my Advanced Agile PM Training course are designed to satisfy.

It’s very important to recognize that Agile will precipitate a dramatic transformation of the Project Management profession as we know it today and PMI-ACP® certification is a good step in the right direction but I think most people will agree that it’s just a test of general Agile knowledge and doesn’t go far enough to prepare project managers for a specific Agile Project Management role and to address the real challenge that many project managers face of “How do I blend Agile and traditional Project Management” principles and practices in the right proportions to fit a given situation?”

Why Should a Project Manager Care About Agile?

Why Should a Project Manager Care About Agile? Many people in the project management profession seem to be in “denial” about the impact of Agile. Many seem to think it is something that they can ignore that has no impact on the project management profession. There are a number of potential reasons why project managers might believe that Agile doesn’t have any impact on them and that the project management will continue to be limited to traditional plan-driven approaches that haven’t changed significantly since the 1950’s and 1960’s:

  • There is a big misconception that “Agile” and “Waterfall” are binary and mutually-exclusive choices which might lead a project manager to believe that he/she can concentrate on “Waterfall” projects and ignore Agile.
  • Agile and traditional plan-driven project management are treated as separate and independent domains of knowledge with little or no integration between the two and it can be quite challenging for anyone to try to figure out how to blend the two approaches together in the right proportions to fit a given project
  • The role of a project manager at the team level in an Agile project is completely undefined and it would be a big risk for anyone to move their career in that direction for that reason. The path of least resistance is to continue to focus on traditional, plan-driven project management and ignore Agile for as long as possible.
  • There may also be an opinion that “Agile” is just a passing fad and will go away and/or the people who do Agile or just a bunch of “cowboys” and it really isn’t a legitimate form of project management at all.

Here’s my perspective:

  • There are many myths, stereotypes, and misconceptions about both traditional project management and Agile that have caused a lot of polarization between these two communities. I’ve developed a free online training course that is designed to help project managers get past some of these misconceptions and see Agile and traditional plan-driven project management in a fresh new light as complementary to each other rather than competitive. Check it out here:

    “Learn the Truth About Agile versus Waterfall”

  • Agile is precipitating a major transformation of the project management profession that will cause us to rethink many things we have taken for granted about project management for a long time. Anyone who ignores this trend risks becoming a “dinosaur”. I believe that in the not-too-distant future, a project manager who only knows how to do traditional, plan-driven project management will be like a carpenter who only knows how to use a hammer.
  • Even if you’re never involved in a real Agile project, learning the Agile principles and practices will broaden your thinking, expand the number of “tools” in your toolkit, and make you a better project manager.

I saw a similar transformation when I worked in the Quality Management profession in the 1990’s and early 2000’s. At that time, the Quality Management profession was shifting from an emphasis on quality control and inspection where someone with the title of “Quality Manager” was responsible for quality and played the role of enforcing quality standards. We learned that a much more effective approach was to engage everyone in feeling responsibility for the quality of products and services and integrating a proactive focus on building quality into the process rather than inspecting for quality at the end of the process.

That was a gut-wrenching change for many people in the Quality Management profession and I can remember that there were a lot of people who were out of work at that time who were slow to recognize and adapt to that transformation. The similarities to the Project Management profession are obvious to me and I hope I can help project managers see the need to recognize and adapt to this transformation. Check out my blog post on “The Future of Project Management” for more on this.

Multi-Dimensional Project Management

I recently wrote a post on “Adaptive versus Plan-driven Project Management”. It occurred to me that this same framework would be useful to help people understand the migration that I believe is happening in the project management profession. Here’s how I see the migration to a new multi-Dimensional project management approach that is likely to take place in the future:

Project Management Transition

I don’t think that anyone today would disagree that “Project Management”, as we’ve known it, is heavily defined by plan-driven principles and practices as shown by the oval in the left-hand column of this diagram and there are many stereotypes that heavily associate “Project Management” with plan-driven practices. What I believe is likely to happen within the project management profession in the future is this:

  • At a team level, a large percentage of project management roles are likely to migrate towards a more adaptive approach over some period of time. That means that many of those project management roles might disappear and project managers who are only qualified to do plan-driven project management at a team level may have to move in one of two different directions:
    • Move up to assume a higher-level enterprise-level role managing larger, more complex projects
    • Develop more adaptive project management skills
  • Project Managers who are already managing larger, more complex projects and enterprise-level projects may be less impacted by this migration; however, even at that level, the demand for project managers who only know how to do plan-driven project management will likely decline significantly.
    • Some of these new roles may not even be recognizable as we know project management today and may not even have the title of “Project Manager” associated with them. For that reason, I think we need to shift our thinking about what “Project Management” is. Instead of thinking of it as a narrow vertical column that is dominated by plan-driven thinking, what I believe is needed is more of a broader, multi-dimensional view of project management that goes beyond just doing traditional, plan-driven project management functions and also embraces a more adaptive approach to project management.

      In my opinion, project managers of the future will need to take on a broader range of roles and must be able to operate in either a plan-driven role or a more adaptive project management role and should be able to select the appropriate blend of those two approaches to fit a given situation rather than force-fitting all projects to a plan-driven approach.

      It seems to me that the Project Management profession needs an image makeover to shift the image of how people think of what “Project Management” is to prepare people for this migration that I believe is likely to happen. I think that there are a lot of people in the project management profession who are in “denial” and seem to think that the way we’ve been doing project management will go on unchanged into the future. I hope this post has helped people more clearly see this migration trend.

Adaptive versus Plan-driven Project Management

I’ve written several articles on the subject of why the comparison of “Agile versus Waterfall” that is so widely used is so inaccurate and misleading. A better way to view it is to think of adaptive versus plan-driven project management. Check it out here:

Learn the Truth About ‘Agile versus Waterfall’

There’s a lot of reasons why that comparison isn’t very meaningful and can be misleading – What is Agile? What is Waterfall? What are you comparing to what? Is it really a meaningful comparison? (I don’t think so)

A much more objective and meaningful way of comparing different methodologies is needed and I think the comparison of “Adaptive” versus “Plan-driven” is much better-suited for that purpose. Here’s how those terms are defined:

  • Plan-driven – “Plan-driven software development is a more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation” (Source: http://en.wikiversity.org/wiki/Plan-driven_software_development
  • Adaptive – An “Adaptive” approach, on the other hand is characterized by having a less well-defined plan that is more adaptable to fit the situation as the project progresses. It’s more of a rolling-wave planning approach where the plan evolves as the project evolves.

This is not a binary, all-or-nothing choice between 100% plan-driven and 100% adaptive:

  • You don’t typically find many situations that have an absolutely rigid plan down to the smallest detail that is not subject to any kind of change and
  • You don’t typically find situations that are totally unplanned where you just start doing something without any kind of plan and make up the plan as you go.

Most situations lie somewhere between those two extremes – there is a continuum of different approaches from a heavily plan-driven approach at one extreme and a heavily adaptive approach at the other extreme with lots of alternatives in the middle. If you were to plot different approaches on this continuum, here’s a sketch of what it might look this:

Adaptive versus Plan-driven Project Management

Here’s some notes on this diagram:

  • This is not meant to be an exhaustive and comprehensive diagram – it is simply an illustration showing a few examples
  • Each of these methodologies can be used in a range of situations – for example, Scrum can be used in a range of situations that have varying levels of adaptivity; however, it would be difficult to make Scrum work in a heavily plan-driven approach
  • However, by putting a plan-driven “wrapper” around Scrum, you can create a hybrid approach that provides a plan-driven shell at the project level but retains most of the flexibility of Scrum at the team level
  • Kanban is generally more adaptive than Scrum because it is typically used in more reactive situations that are less planned (like a customer service process)

There is no “good” and “bad” judgment in characterizing a methodology as “adaptive” or “plan-driven”. Neither an adaptive methodology or a plan-driven methodology is inherently good or bad just because it is adaptive or plan-driven. The problem comes up when they are misused – for example, when you try to use a heavily plan-driven methodology like Waterfall for a situation that has a lot of uncertainty in it and calls for a more adaptive approach.

Why is this important? The traditional comparison of “Agile versus Waterfall” is almost meaningless and very misleading. It frequently is used judgmentally that “Waterfall” is bad and “Agile is good. That leads people to think of those two approaches as binary, mutually-exclusive choices; and, as a result, people many times tend to force-fit a project to one of those extremes. A much better approach, in my opinion, is to view these approaches from a more objective perspective and fit the approach to the nature of the problem based on the characteristics of the methodology and the problem.

What’s the Difference Between a Project and a Process?

What’s the difference between a project and a process? I have a very broad view of what “project management” is. but there is a danger of broadening the definition of a “project” and “project management” so far that almost anything could be a “project” and that would make it meaningless. For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”. I think it could be both because “projects” and “processes” are very inter-related. To eliminate potential confusion, I think we need clearly-defined and objective criteria for drawing a line between what is a “process” and what is a “project”.

I’ve summarized some distinctions below:

ProcessProject
A “process” has an objective that is typically defined around the ongoing operation of the process.
For example, “provide ongoing maintenance for GM vehicles”
A “project” has an objective or outcome to be accomplished and the project ends when that objective is accomplished. That objective might be broadly-defined and might change or be further elaborated as the project is in progress.
For example, “find a replacement ignition switch that will solve the problem with GM vehicles".
A “process” is generally ongoing and doesn’t normally have an end.A “project” has a beginning and an end (although the beginning and end may not be well-defined when the project starts and the end might be a long time in the future).
A “process” is a repetitive sequence of tasks and the tasks are known at the outset since it is repetitive.The sequence of tasks in a “project” is not normally repetitive and may not be known at the outset of the project.

Here’s a similar distinction between “process management” and “project management”:

Process ManagementProject Management
Process management is focused on managing a process such as a software development process. Such a process might be used across a variety of projects.
Process management might involve some project management to define and improve the process.
Project management is focused on managing a project typically using some process in achieving some kind of desired end result.
Every project follows some kind of process even though it may not be formally defined.
Process management has an emphasis on increasing "repeatability" of the tasks, improving efficiency (decreasing time needed, reducing cost), and improving quality of the work product produced by the process (including consistency in quality).Project management has an emphasis on achieving the end result that the project is intended to accomplish.
Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.

In simple, terms, “process management” is focused on managing existing business processes as efficiently and effectively as possible – it’s associated with managing the current way the business operates. “Project management” is associated with managing some kind of change in the way a business operates effectively such as introducing a new product, implementing new processes, etc.