Redefining Project Management -...

Redefining Project Management

PMBOK® Guide Process Groups vs. Project Life SpanThis document is a substantive discussion of a common confusion in project management today. The objective is to explain the concept of project life span (cycle), phases, stages, process groups, and at the end map the process groups to a project life span methodology.

2013

SUKAD Group

Mounir A. Ajam

© 2008-2013 SUKAD Group and Mounir Ajam

Table of ContentsList of Figures........................................................................................................................................................2

I. Introduction to Redefining Project Management.........................................................................................3

A. Basis and Disclaimer..................................................................................................................................3

B. Why Redefining.........................................................................................................................................3

C. Contributing Factors to Redefining...........................................................................................................3

D. Our Action and Response..........................................................................................................................4

II. Setting the Scene...........................................................................................................................................5

A. Questions..................................................................................................................................................5

B. What Are We Redefining?.........................................................................................................................5

III. Project Life Cycle or Project Life Span.......................................................................................................6

A. Project Life Cycle.......................................................................................................................................6

B. Project Life Span........................................................................................................................................6

IV. Project Phases and Stages.........................................................................................................................7

A. Phase or Stage...........................................................................................................................................7

B. Phases.......................................................................................................................................................7

C. Stages........................................................................................................................................................7

D. CAM2P™ Closing Comment........................................................................................................................8

V. PMBOK® Guide Process Groups....................................................................................................................9

A. PMBOK® Brief............................................................................................................................................9

B. How to Use the Process Groups..............................................................................................................10

VI. The Confusion between Process Groups vs. Project Phases...................................................................11

A. Expanding On the Confusion...................................................................................................................11

B. Opinion or Fact........................................................................................................................................11

C. So Why the Confusion.............................................................................................................................12

D. Re-Listing the Questions for Ready Reference........................................................................................12

VII. Mapping Process Groups to Project Life Span.........................................................................................14

A. Mapping Process Groups to CAM2P™......................................................................................................14

B. Project Perspective..................................................................................................................................14

C. Phase Perspective...................................................................................................................................14

D. Project and Phases Together...................................................................................................................15

VIII. Closing.....................................................................................................................................................16

A. The Impact/Threat..................................................................................................................................16

© 2013 SUKAD – Redefining Project Management – Updated: 17 May 2013 Page 1


B. Conclusion...............................................................................................................................................16

Appendices.........................................................................................................................................................17

Appendix A - About the Author.......................................................................................................................17

Appendix B - Copyright Guidelines..................................................................................................................17

List of Figures

Figure 1: A Typical Graphical Representation of a Project Life Span.....................................................................6

Figure 2: Project Phases per the CAM2P™ Model..................................................................................................7

Figure 3: Project Phases and Stages per the CAM2P™ Model...............................................................................7

Figure 4: The PMBOK® Guide Process Groups Interactions..................................................................................9

Figure 5: Common Views on Names of Project Stages........................................................................................11

Figure 6: PMBOK® Guide Process Groups Mapped to CAM2P™ Project Life Span Model...................................14

Figure 7: The Process Groups Repeating with Every Phase.................................................................................15

Figure 8: The Process Groups as they Apply for the Project and Each Project Phase..........................................15



I. Introduction to Redefining Project Management

A. Basis and Disclaimer

We base our observations in this paper on interactions with project management practitioners, online discussion groups, as well as surveys and polls that we have conducted in the past. It has been quite clear to us that a large number of project management practitioners do not understand (or at least misunderstand) some of the key concepts in project management.

We do not claim to be THE authority on this subject. We also know that what we share with you here, will be in line with what you already know (for some), but will challenge the conventional wisdom for others, even may change your paradigm in regard to project management and the PMBOK® Guide1.

B. Why Redefining

Our first action in this paper is to explain the title, why Redefining?

The quick and simple answer is the following:

Many professional associations, subject matter experts, and thought leaders have already defined project management. Their definitions might have subtle differences but in general, they do converge along certain processes, methods, or approaches.

However, we think that some of the common project management terms used in the field of project management are not well defined, or there are different definitions depend on the source of the information. Consequently, the outcome of this lack of clarity is starting to damage the field of project management2.

We do realize that many would not agree with these statements, which is why, in this series of articles, we want to challenge the conventional wisdom and trigger some reflection on what we are presenting.

C. Contributing Factors to Redefining

Expanding on the above, in our humble opinion, project management thought leaders and professional associations have done a great job in defining project management and by 'redefining' we have no wish to undermine their work or disrespect what the wealth of information they had put forward. Nevertheless, the challenges we have observed are many and these have led us to use this term, Redefining. We single out two specific factors leading us to such a term.

1. Many of those thought leaders have moved on to the higher levels of project management and are working on topics related to organizational project management, strategic project management, project management maturity, program management, and various other ‘advanced topics’. They seem to be forgetting, or are moving away from re-assessing basic project management. Perhaps they feel that basic project management is already sufficiently mature. Alternatively, perhaps this level of detail lacks sufficient interest. On the other hand, perhaps what we have (the lack of understanding) is now too entrenched to be changed?

1 The PMBOK® Guide is “A Guide to the Project Management Body of Knowledge®”, published by the Project Management Institute; all rights reserved to PMI®. Typically, any reference to the PMBOK® Guide in this paper would be to the 4 th edition of the standard.2 We do not mean all the terms since in some situations the differences are minor and have negligible impact. However, the lack of understanding of some terms and practices, have an effect on projects’ results, as we will discuss in this paper.



2. The second main contributing factor is the widespread and popularity of project management certifications, such as the Project Management Institute's (PMI3) Project Management Professional4 (PMP®) certification, although the issues are not limited to the PMP alone.

We are not criticizing the PMP® certification here but we do critique the organizations that administer, award, and promote the PMP, including PMI, some of its chapters, and some training providers who depend on the PMP as the main source of income for themselves or their organizations. With their eagerness to promote the most popular project management credential today, their focus is on teaching people to pass a multiple-choice exam rather than on facilitating the learning of proper project management, or enhancing projects success and organizational performance.

Why is the second point above a factor, a contributor, to the title of this paper?

Because, many technical/functional professionals without real project management experience, and many with limited project management experience, are becoming PMP. In general, this is not an issue if we all agree that the PMP is a basic level certification5. However, the challenge is that these organizations and individuals promote the PMP as an expert level certified project manager. Expertise requires years of REAL experience and not fresh graduates working in a university computer lab or as teacher's assistant.

Further, the way training provider 'teach' a large percentage of PMP preparation classes; their focus is on the process groups and processes, with inputs, tools and techniques, and outputs; or the so famous ITTO6. These are leading to numerous points of confusion around project management, project management terminology, and most importantly, the practice of project management. In short, the dominant confusion is around the process groups and the project life cycle. The PMBOK® Guide addresses project life cycle and project phases in chapter 2 but briefly and most do not stop and reflect on what this truly means on a project.

D. Our Action and Response

Because of these past observations and experiences, we had decided to tackle these issues by developing a project management methodology, publishing a series of books, and launching a blog with the title Redefining Project Management. This paper reflects our views on the confusions, and our attempt to clarify using the SUKAD approach for managing projects.

3 PMI is largest not-for-profit association promoting project management, with over 400,000 members at the time of writing.4 The Project Management Professional (PMP) is the most popular project management credential with over 500,000 holders5 Some ‘sell’ the PMP as an expert level project manager certification. However, the PMP requirements did not require a project manager experience, so it is not a project manager certification. Further, some would debate whether 4500 hours of experience working on projects would justify the ‘expert’ label.6 The focus on input – tools & techniques – output is so dominant that people label it ITTO in online groups.



II. Setting the Scene

A. Questions

We realize that some readers may well question our motive and discredit this paper/series of articles7. Before you rush to judgment, please read the next few lines and answer the following questions.

If you are not a PMP or not familiar with the PMBOK® Guide you can scan this section or skip it, since it will not be applicable to you.

1. On any given project (not a large task or tiny project), how often do you perform PMI's initiation processes described in PMI's A Guide to the Project Management Body of Knowledge8?

2. How about the planning processes; or the closing processes; or the other processes, how often do you perform them?

3. During a project, how many ‘project’ management plans do you have? (Notice the apostrophes around the word project)

4. Does the statement ‘perform the executing processes during the project initiation phase’ make sense to you?

5. How about ‘plan the planning phase’, does that make sense?

6. Is there only one "charter" on a "project"?

If you answer

"once" to questions 1 and 2;

"one" to question 6;

"one project management plan" to question 3;

and questions 4 and 5 do not make sense to you ...

read on. This paper is for you!

B. What Are We Redefining?

The ultimate goal of this paper is to clear confusion concerning the ‘project life cycle’ versus the PMBOK® Guide ‘process groups’. To reach the ultimate goal, we do so in steps and each step would be a section in this paper.

1. We will start by explaining the terms project life cycle / project life span

2. We will explain project phases and stages

3. We will highlight the PMBOK® process groups

4. Finally, we will clear the confusion between process groups and project life cycle

7 Please note the author had been a PMI volunteer for many years; has been a PMP since 1998; has served in numerous regional and global PMI volunteer leadership roles, and is a PMI Leadership Institute Master Class graduate (2007). Therefore, as a long-term volunteer leader, who has contributed to PMI standards, we do this critique for the betterment of the field of project management. Also, note that the author is the co-founder and CEO of an organization that offer and promote the PMP with clarifications8 If you are not familiar with the PMBOK® Guide, you can skip these questions



III. Project Life Cycle or Project Life Span

Which is the correct term: Project Life Cycle or Project Life Span?

We really do not know, with certainty!

In a recent LinkedIn group, we debated these terms and at the end of the day we decided to agree to disagree, which is often common in these groups since it is not easy to have a unified language, and maybe we should not.

A. Project Life Cycle

Some argued that the word project life cycle is more appropriate. Their basis: “since the project processes repeat from one project to another and once we finish a project we could start another ...” The same group also presented that the dictionary defines life cycle as “all stages of development”. Here are some references:

Encarta presents us with “the complete process of change and development during somebody's lifetime or during the useful life of something such as an organization, institution, or manufactured product.”

Another definition also from Encarta provides “stages of development of living organism”. Oxford Online9 presents “the series of changes in the life of an organism including

reproduction”. Webster Online10 explains “a series of stages through which something (as an individual,

culture, or manufactured product) passes during its lifetime”. This is quite similar to Encarta.

In summary, the main argument for project life cycle is the comparison to organism life since, we use this term in that context.

B. Project Life Span

The other debaters agreed that project management processes do repeat therefore, the term ‘project management life cycle’ might be appropriate. On the other hand, a project does not repeat. Further, a project, from idea to closure, spans a period of time that could be weeks or years. Therefore, the project life span is the more appropriate term.

The dictionary provides us with “length, duration, period, time …” for the word span. More from Webster Online11: “an extent, stretch, reach, or spread between two limits … as … a

limited space (as of time) … especially: an individual's lifetime … the spread or extent between abutments or supports (as of a bridge)…”

The author prefers the second term and that is what we used in our project life span model, the SUKAD Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™).

So which is correct? You decide and use the term that you prefer.

9 http://oxforddictionaries.com/definition/life+cycle10 http://www.merriam-webster.com/dictionary/life%20cycle11 http://www.merriam-webster.com/dictionary/span


Figure 1: A Typical Graphical Representation of a Project Life Span

http://www.merriam-webster.com/dictionary/span

http://www.merriam-webster.com/dictionary/life%20cycle

http://oxforddictionaries.com/definition/life+cycle


IV. Project Phases and Stages

In this section, we address project phases and stages. We will also touch on the methodology that we have developed since it touches on both terms and this is relevant to the later part of the paper since we can have a specific example to discuss.

A. Phase or Stage

For better control, we divide the project life span into time (or work) segments that we commonly graphically represent per Figure 1.

While we typically refer to these time segments as phases, others refer to these time segments as stages. North American English speakers prefer phase, with a stage as a subset of phase. However, UK English speakers prefer stage at this level.

B. Phases

In the SUKAD project management methodology12, we actually use phase and stage as two independent items. In CAM2P™ we use the term phase to refer to three major segments that span the project from

start to finish. We believe these phases are universal (although some might use different names) and apply for many industries and application areas.

These CAM2P™ phases are:

The Project Concept Phase (from idea and business case to authorizing the project) The Project Development Phase (from authorization to detailed plan; final commitment) The Project Delivery Phase (from final commitment to closure; and beyond)

C. Stages

In the CAM2P™ Model we also use the term stage to refer to six segments that span the project from start to finish and can significantly overlap; these are sub-phases and directly link to the three phases. These stages could be adjusted (merged, expanded, etc.) to better reflect the specific industry or application area that is developing the project. In other words, they can be adjusted through ‘customizing and adapting the model’.

The CAM2P™ stages are:

The Project Pre-Launch Stage (this is matching and align to the concept phase and span from idea statement13/business case to project authorization)

The Project Launch Stage (from authorization to project management plan)

12 We call the methodology as “The Customizable and Adaptable Methodology for Managing Projects™”; CAM2P™13 The idea statement, project authorization, project detailed plan, are examples of the major deliverables of the stages


Figure 2: Project Phases per the CAM2P™ Model

Figure 3: Project Phases and Stages per the CAM2P™ Model


The Project Definition Stage (from project management plan to final commitment) The Project Implementation Stage (from final commitment to handover) The Project Operation Readiness Stage (in parallel to implementation and expand to project

acceptance; could start before implementation) The Project Close Stage (from handover to closure)

D. CAM2P™ Closing Comment

The CAM2P™ Model is not unique; many other organizations have their own internal project management methodologies that are similar to the above but they use different terms.

With this section and the previous one, we have defined a project life span model, including phases and stages, that we will use in comparison to the PMBOK® process groups.



V. PMBOK® Guide Process Groups

In the minds of many PMBOK® Guide students, and project management professionals (PMP) for that matter, the process groups are a dominant part of the PMBOK® Guide. Therefore, in this section, we will continue to build and discuss the various pieces of our basic project management puzzle.

A. PMBOK® Brief

The following are the main points related to process groups:

The term “process group“‘ is made popular by the PMI® since it is a foundational element in the PMI Project Management Framework, as is described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

“Process groups” refers to a specific group of processes, each consisting of two or more (sub) processes that practitioners can use to manage a project or a phase of a project.

These process groups are Initiation, Planning, Executing, Monitoring & Controlling, and Closing.

They are derived from the well-known quality cycle of plan-do-check-act.

Together, these process groups encompass 42 processes14.

If we are not mistaken, the five process groups have been around since the original PMBOK® Guide was published in 1996.

However, the number of processes within these groups has changed over time; the 4th edition has 42 processes; earlier versions had more, or less; the 5th edition has 47.

It is also possible that some specific processes have shifted from one process group to another in subsequent editions.

Figure 415 is from the PMBOK® Guide and represents the interaction of the process groups within a project or phase.

B. How to Use the Process Groups

The processes of these groups repeat in every stage of the project.

We apply stage initiation, stage planning, stage execution, stage closing, and stage monitoring and controlling (throughout each stage). Once we conclude a stage, we move to the next stage and we repeat the applicable processes.

The unfortunate situation is: many practitioners do not understand, or have forgotten, the above ritual. These practitioners think, “We initiate the project, plan the project, execute the project,

14 Per the 4th edition, published in 2008 by the Project Management Institute (PMI) and all copyrights reserved to PMI. The upcoming 5th edition has 47 processes.15 The figure is copyright to PMI


Figure 4: The PMBOK® Guide Process Groups Interactions


monitor and control the project, and close the project”. This practice indirectly lead to practitioners (individuals and organizations) treating the process groups as phases and they become the de-facto project phases.

In other words, practitioners forget that the process groups apply at the project level and phase/stage level and therefore, it is important to separate process groups from project phases.



VI. The Confusion between Process Groups vs. Project Phases

In the earlier sections, we mentioned but did not emphasize the main confusion on project life span (phases) versus process groups. We will do so next.

A. Expanding On the Confusion

Many practitioners and students of project management misunderstand the PMBOK® Guide; when we ask them to name the stages of the project life span they provide the name of the process groups as stages; per the figures below.

The difference between the top and bottom part of the above figure is the addition of “Monitoring & Controlling”. In the top part, we do not show it since the monitoring and controlling processes are active across the whole project life span. However, some practitioners even refer to Monitoring & Controlling as an independent stage as well, and they add it, per the bottom part of the picture.

What they do not recognize is that the process groups ARE NOT project phases or stages. The situation is not limited to individuals since some organizations are starting to name their project phases after the process groups. It is not a problem with whatever name individuals and organizations use for their project phases … as long as … they understand that a planning phase is different from the planning processes and the execution phase is not the same as execution processes. The reality though, is that we find the use of the process groups as project phases, and this is critical. In other words, the confusion is not limited to terminology but it is even in the practice and organizations/individuals do believe that planning processes are the same as the planning phase and closing processes are the same as the closing phase.

B. Opinion or FactIn case there is still some doubt {that the process groups are not phases} what we present here is not an opinion, it is a fact. The PMBOK® Guide clearly states this fact and here are references to prove it:

1. The PMBOK® Guide is clear that the project life cycle consists of phases (not process groups); chapter 2, pages 15, 18, 21, and others sections.

2. The guide is also clear that the process groups repeat in every phase; chapter 2, page 21, Figures 2-4 and 2-5; and chapter 3, page 39, section 3.1.

3. Figure 4, earlier section, shows (left side of image) that we go into initiation when we need to start a new project or enter the next phase. The right side of the image shows an arrow reflecting the end of the project or exiting a phase to go into another.

C. So Why the ConfusionIf the PMBOK® is clear on this, then why do so many practitioners and PMP miss this point? Why, even organizations, are confusing project phases with process groups?


Figure 5: Common Views on Names of Project Stages


We suggest that the following as possible explanations:

1. Many do not really (carefully) read the PMBOK® Guide and if they do, they focus on processes, inputs, tools & techniques, and outputs, which repeat in the guide 42 times, with every process.

2. The focus on the processes, process groups, and knowledge areas often lead a person away from the first chapters of the guide where the PMBOK presents the project life cycle.

3. The guide also presents us with the Project Charter as the document that authorizes the project or a phase; this means that there could be a project charter and a charter for every phase! In other words, even when the guide uses the term Project Charter — it could be a phase/stage charter … or what some would prefer to call a “stage initiation document“. However, when the practitioners read “project” charter … they only think project and forget about “project or phase“

4. The same is true for the project management plan, project close, etc. Here again, although we use the word project in all of these documents it actually means a project or a phase.

5. Planning is a continuous process that goes almost all the way to the end of a project, so what is the planning phase? See PMBOK® Guide, chapter 3, page 41, Figure 3-2.

6. Same thing for monitoring and controlling.

D. Re-Listing the Questions for Ready Reference

This might be a good time to revisit the questions in Setting the Scene section and see if you have different answers than what you had earlier. Below, we list the questions again with our answers – please do not read until you have revisited the earlier section.

1. On any given project (not a task or tiny project), how often do you perform PMI’s initiation processes described in PMI’s A Guide to the Project Management Body of Knowledge?

The answer should be: “every time we initiate a new phase or stage”

2. How about the planning processes … or closing processes … or the other processes?

Answer: “with every phase or stage”

3. During a project, how many “project” management plans do you have? (Notice the apostrophes around the word project)

One project management plan for the project … but … every phase or stage would have its own plan expanded from the project plan or even independent in some cases.

4. Does the statement perform the executing processes during the project “initiation phase” make sense?

It should make sense since “executing initiation phase” means perform the various activities to deliver the feasibility study, initiation document, or whatever else you do in initiation.

5. How about plan the planning phase, does that make sense?

First, we do not advocate the use of “planning phase” call it project planning — with emphasis on project that would be fine.

In this case, if you have a planning phase, then yes, you have to initiate it, plan it (plan the plan), execute it (produce the plan), and close it when done while you monitor and control throughout the process.



6. Is there only one “charter” on a “project“?

There is only one project charter but here again, every phase should have a charter – although we do not call it charter. If we remember, a charter is to authorize the project or phase, so every time we are ready to start a new phase we should have authorization.



VII. Mapping Process Groups to Project Life Span

In our effort to clarify the above, and the need for a project management methodology, we will map the PMBOK® Guide process groups to the stages of the CAM2P™ model. You can do the same for your internal methodology or any other project management methodology that you use.

A. Mapping Process Groups to CAM2P™

As noted earlier, the PMBOK® Guide offers us five process groups. They are Initiating, Planning, Executing, Monitoring and Controlling, and Closing, which we abbreviate as I, P, E, M&C, and C. The PMBOK® Guide also provides an explanation that we need to Initiate, Plan, Execute, Monitor and Control, and Close the project ... OR ... phase ... therefore, we use I, P, E, M&C, and C for the project as well as a phase.

B. Project Perspective

In the next graphic, Figure 6, we focus on mapping the process groups to the project. We show that we do indeed:

Initiate every project; represented with the "I" in the green oval,

Plan the project; represented with the "P" in the green oval and the green arch,

Execute the project; represented with the "E" in the elongated green oval,

Monitor & control the project; represented with the "M&C" in the elongated green oval, and

Close the project; represented with the "C" in the green oval at the right side.

C. Phase Perspective

As the PMBOK® Guide clearly explains, we do also I, P, E, M&C, and C each project phase (or stage), which we show in Figure 7.

We know some readers might be surprised, even shocked, at the details we show in Figure 7. Here we


Figure 6: PMBOK® Guide Process Groups Mapped to CAM2P™ Project Life Span Model

http://sukad.com/cam2p.php/introduction


need to remind you that from the beginning we said we will challenge the conventional wisdom and here we are doing it.

We have personally interviewed many project management professionals and even professionals conducting PMP classes that did not know the above and only know how to teach people to memorize the ‘I, P, E, M&C, and C’ processes. We know that some might even feel insulted by my statement here and we are sorry if that is the case, but the fact is they may well have memorized the PMBOK® Guide contents yet still do not understand its basics.

Yes - we do initiate the pre-launch stage (pre-project - including feasibility study) and we plan for it and we execute it (doing the work of the pre-project is execution), and we do monitor and control and ultimately close the stage. We do the same for the next stage, and the next, and the next, until we reach the end of the project life span.

Thus, the process groups repeat, as many times as there are stages. Maybe not every single process applies every time and maybe in small/simple projects, we do not need to do this if we can treat the whole project as a single phase. However, as projects grow in size or complexity, what we present here could mean the difference between project success and project failure.

D. Project and Phases TogetherIn this last graphic, Figure 8, we present the CAM2P™ Model as we map the PMBOK Guide process groups at the project level and the phase level.


Figure 7: The Process Groups Repeating with Every Phase

Figure 8: The Process Groups as they Apply for the Project and Each Project Phase


VIII. Closing

A. The Impact/Threat

Some might argue that this whole series is discussing the obvious and not value added. For those who truly understand what we present, then obviously this paper will not add much to their knowledge and it would not be of benefit. However, this paper is not for this group of professionals, rather it is for those who do not fully understand the issues that we are discussing. In our humble opinion, there are many issues with this confusion or misunderstanding, which could lead to major problems in managing projects, hence the need for this series.

Unfortunately, there are no researches that validate what we are presenting or calculate the impact of this issue on projects’ performance. We can only speculate that on small/simple projects it might be safe to treat the project as a single stage project; for these projects, we expect no significant negative impact. However, we are willing to state a controversial opinion here – in most moderate, large, or complex projects --- this confusion is leading to “challenged” if not “failed” projects. As we said, there are no studies specific to this point although there are numerous studies and literature that address project failure rates and states that a good percent of projects still fail. Failure, have many causes and contributing factors; we are of the opinion and stress that lack of “proper” project management is a common cause and confusing the process groups is “lack of proper project management application”.

B. Conclusion

Confusing is not it?

It should not be - once we truly and correctly understand the PMBOK® Guide. What is important to recognize is that to effectively manage a project:

We need a methodology that can be developed internally, or you can use something like the SUKAD CAM2P™ project management methodology, or any other methodology

We need the processes, such as what the PMBOK® Guide offers, and We need project management competence ... such as what IPMA16 advocates.

We suggest that the above three points are core elements of project management maturity.

Our recommendation is that you read, read and read again, and compare what we have presented with what you currently practice. Read chapter 1 and 2 in the PMBOK Guide. Then make some adjustments, at least on a trial basis, and see if that makes a difference to your project outcomes. There might be the normal learning curve but we know organizations are capable of judging whether what we propose adds value or not.

16 IPMA: The International Project Management Association; their focus include project manager comeptence



Appendices

Appendix A - About the Author

Mounir AjamMounir is an executive, entrepreneur, author, global speaker, social activist, and project management thought leader with more than 25 years of global professional project management experience. He has been working on capital projects and with various business sectors.

Mounir professional experience is global and earned in the United States, United Kingdom, South East Asia and West Asia. He has been involved with projects worth billions of dollars while working with global leaders such as Exxon, Shell, BASF, Total, and Saudi Aramco.

Mounir is an active volunteer leaders and he has held numerous global roles. These include PMI® Congress Project Action Team, PMI® Advisory Group for Registered Education Provider program, judging panel on PMI providers and educational awards. Other than PMI, Mounir is a co-founder of the Global Project and Process Management Association (GPPMA) and served as Board of Director Chairperson for 3 years.

Mounir has a Master Degree in Engineering & Construction Management from the top ranked University of California Berkeley, 1990. He is a graduate of PMI Leadership Institute Master Class, 2007. He earned his Project Management Professional (PMP®) certification in 1998.

Appendix B - Copyright Guidelines

This article is part of the SUKAD Knowledge sharing library and will be part of the upcoming Project Management Knowledge Portal, http://knowledge.sukad.com.

As part of SUKAD Vision, Project Management for All Aspects of Life, and Mission, For Project Management to Be an Agent of Change and Catalyst for Development, we want to share information with the general professional community and our clients on an open access basis, as much as it is feasible without sacrificing our competitive advantage. We will do so through Creative Commons.

Creative Commons is a system that allows us to share and accomplish our objectives with some restrictions. Therefore, unless otherwise noted, all of the work published through this portal (including this paper) is the intellectual property of SUKAD and Mounir Ajam. We license it under the Creative Commons Guidelines, as we list here.

Redefining Project Management by Mounir A. Ajam is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.Based on a work at http://blog.sukad.com/.Permissions beyond the scope of this license may be available at http://www.sukad.com/.

For this specific article, the copyright guidelines are per the following:

You can modify this work, as long as you share alike, You clearly show SUKAD and Mounir Ajam as the original owner of the content, and You cannot sell any of the materials included here; you cannot use for commercial gain. The license jurisdiction is International


http://www.sukad.com/

http://blog.sukad.com/

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.en_US

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.en_US

http://www.sukad.com/

http://knowledge.sukad.com/


For more details on Creative Commons, visit their website at: http://creativecommons.org/.


http://creativecommons.org/

Redefining Project Management -...

Documents

Transcript of Redefining Project Management -...