4squareviews

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.3 The Relationship of Project, Program, Portfolio and Operations Management.    In the last post, I discussed the relationships of projects to programs, which include them as a component, and portfolios, which include both projects and programs as components.   Let’s now discuss the relationship of projects to operations which is covered in sub-sections 1.2.3.4 Operations Management and 1.2.3.5 Operations and Project Management.

Remember the definition of a project that was given at the beginning of the Guide?

A project is a temporary endeavor undertaken to create a unique product, service, or result.

Operations, on the other hand are the ongoing production of goods and/or services.   So you can see that behind the definition of a project is the distinction between it and the ongoing nature of operations of an organization.

However, if you look more closely at how organizations actually create and maintain business value, this distinction isn’t as clear-cut as it would first seem to be.    Here’s why:  many projects have as their objective the creation of a new product or a system for delivering a new service.    However, many projects have as their objection the upgrade of an existing product or service or the improvement of business operations.

In the 5th Edition of the PMBOK® Guide, although the definition of a project is the same as above, in the explanation below the definition it was made clear that a project could indeed include improvements to existing products as well as the creation of new ones. This means Six Sigma projects, which are designed to improve the processes of existing operations in order to reduce defects in their end results, are to be considered as included in the definition of a project.

This is made even more clear in the 6th Edition PMBOK® Guide with an even fuller explanation of projects which exist to improve existing operations.   But what if those improvements to existing operations are made on a continuous basis, which is the basis for kaizen?    If this is the case, then the distinction between projects and operations is a little fuzzier, because projects are then continuously being launched to improve those operations.    Can they be considered “temporary” endeavors any more if they are constantly being done?    Can they be considered producing a “unique” product, service, or result if they are done to simply create a new, improved version of the same?

Because the distinction between projects and operations is not as clear-cut in some organizations as in others, it is even more important that a project manager consider operations managers as stakeholders in the projects they are doing, especially if those managers are heading departments which will be the direct recipient of a new business service or result, or if they are affected in any way by it.    Also resources from those departments will often be used in carrying out the project, for the very reason that they will be eventually impacted by it.

The next section 1.2.3.6 ties together organizational project management, which is the integration of projects, programs and portfolios.

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.3 The Relationship of Project, Program, Portfolio and Operations Management.    Let’s take the relationship of projects to programs and portfolios first.   Then in the next post I’ll discuss the relationship of programs and portfolios.

Programs

Remember the definition of a project is “a temporary endeavor undertaken to create a unique product, service or result.”   Projects may be grouped together into a program which is “a group of related projects … managed in a coordinated manner.”    The reason for this is so that the projects can achieve a common objective (whether it is a product, service, or result) and managing them together as a project focuses on doing them in an efficient manner.   This can be done not only by planning, executing, and controlling the various projects in a program as a group, but also by sharing resources between those projects.

Portfolios

Program management focuses on doing programs and the projects they contain in the right way; portfolio management focuses on doing the right programs and projects in order to achieve strategic objectives of the organization.    This is done by selecting the right programs, prioritizing the work, and then providing the needed resources.

There is a lot more detail about the internal structure of a portfolio and a program contained on page 12 of the Guide, and a detailed Table 1.2 on page 13 that compares the various characteristics of project, program, and portfolio management.    However, the above overview contains enough information for the project manager to understand why he or she should pay attention to the program and/or portfolio of which their project is a part.

The next post will discuss the relationship between projects and operational management.

Filed under: Uncategorized | Leave a comment »

I received the 6th Edition PMBOK® Guide and am starting a project of going through it and blogging about its contents.   But before I go any further, I wanted to add a blog post about the Agile Practice Guide that comes with the PMBOK® Guide.    I was excited to see this as a harbinger of two trends, one which is the recognition of PMI of the importance of agile methodology as it spreads beyond the world of IT, and the second of which is the growing collaboration of PMI with other professional associations that handle change management, business analysis, and in the case of the Agile Alliance, agile methodologies.

This was why I was excited to get the post from Anthony Mersino’s VitalityChicago blog which reviews the agile practice guide.    Anthony Mersino is an expert in the field of agile methodologies.   I know him from the Chicagoland chapter of the Project Management Institute.   Anthony coaches and trains Agile Leaders to help them understand Agile and Scrum and how to create an environment where people come first, productivity is high, and teamwork is effective and enjoyable.   Anthony has  authored numerous articles and two books:  “Agile Project Management for Teams” and “Emotional Intelligence for Project Managers”.    For those who have been following my blog, I wanted to relate some of his thoughts on the guide, but I encourage you to read the entire post at the following site:

http://vitalitychicago.com/blog/agile-practice-guide?utm_source=newsletter&utm_medium=email&utm_campaign=2017_11_01_blog_agile_practice_guide&utm_content=Blog%20-%20Agile%20Practice%20Guide

First, what does Anthony like about the Guide?    It is broad in its coverage of agile methodologies:   it includes not only Scrum, but XP, Kanban, Lean and other frameworks.   It is deep in its exploration of agile principles, the agile mindset, and the topic of servant leadership.   He also mentions the general point I made above, which is that it is in general a good development that PMI has partnered with the Agile Alliance to produce this document and make it available to all project managers.   Also, the fact that there is a single guide means that those who are studying for PMI’s agile certification, the PMI-ACP® (Agile Certified Practitioner), can use one book rather than the current twelve that they currently have to study from!

Now let’s move onto Anthony Mersino’s warnings about using the Agile Practice Guide.  This advice is invaluable to those project managers like me who are relatively new to agile and want to learn about its contents but also want to absorb the mindset of those who actually work with agile on a daily basis.

5 Warnings about using The Agile Practice Guide

1. Focus on products, not projects

Anthony Mersino says that organizations that use agile are often product-centric, and not necessarily project-centric.    Projects are useful, but only if they help build and maintain valuable solutions and products.    This is why it is important to look at the new business document which PMI has added called the project benefits management plan.    The project business case demonstrates the business value or benefit that the project is supposed to create.   But it is also important that the business value which is created is then maintained so that the efforts of the project are not wasted, and that is what the project benefits management plan does.   Project managers should always be connecting to stakeholders who will be the beneficiaries of their project so that the impact of a project lasts long after the project has ended.

2.  Be careful with “hybrid” approaches

This was a surprising warning, given that I’ve read so many predictions about how more and more projects will be attempting a hybrid approach using both agile and traditional project management methodologies.   Anthony Mersino says that traditional project managers come to agile sometimes with the idea that they can simply utilize an agile “template” and be able to interact with agile teams.    This is like someone who wants to lose weight, and asks the doctor to give him or her a pill to help lose weight, rather than doing what is guaranteed to work (i.e., exercise), but which will require a lot more effort.

However, one thing is certain, even if a project manager engages with agile teams, he or she may still have to TRANSLATE for upper management who may NOT be conversant with agile methods.    What I mean here is that a project management should reassure management with some of the information they are used to getting (milestone charts, tools which show current status and predict future performance) from more traditional methodologies, but in a format that may be at first unfamiliar to them (i.e., based on requirements rather than earned value measurement).   This gets me to Anthony’s next point.

3.   De-emphasize Earned Value Management

One of the concepts from traditional project management that doesn’t translate well into agile projects is the concept of earned value management.   Although he doesn’t go into details of why this is so, I suspect it is because earned value management matured in an application space devoted in large part to engineering or construction projects, where such precise measurements are possible and have meaning.    In the more protean world of IT projects, such precision is not only impossible, but more importantly, trying to impose it on such projects may be meaningless at best and misleading at worst.    Agile, which has been maturing in an application space devoted in large part to IT, is just not a good fit for this type of performance metric.   These are my words, not Anthony’s, but this is my guess at the reasoning behind his comment.

4.  Don’t be mean to Lean

Let me quote Anthony on this one:   “This is a minor point, but, there is a diagram in this book that shows Agile as being a subset of Lean, with Scrum as a subset of Agile – I always thought of Agile as as the child or offspring of Lean, not necessarily a subset.”  This is important because the person who is learning about Agile and Lean at the same time should have a clearer picture of their relationship so that they are not confused by differing terminology and can instead focus on the commonality of the mindset behind these approaches.

5.   Speaking of Lean … this Guide sure isn’t!

Anthony rants (his words) about the size of the 6th Edition PMBOK® Guide.   Actually the Guide itself comprises the first 536 pages; the rest of the book (a total of 754 pages) is the actual ANSI standard for project management which is a reference for the Guide.   The Agile Practice Guide is 165 pages, which he compares unfavorably to the Guide put out by the Scrum Alliance which contains only 17 pages!

He does have a point; if I go into a fitness center to meet my potential trainer and see that he is overweight, that doesn’t give me a lot of confidence that he will make me lean!

These are points to take into consideration, but with those caveats, I recommend all project managers to read the Agile Practice Guide, but also to read the blogs of experts in the field like Anthony Mersino’s VitalityChicago blog to get how agile it actually used by organizations!

Filed under: Uncategorized | 2 Comments »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

In section 1.2.2, PMI discusses the importance of project management.

As you might suspect, the Project Management Institute does indeed think that project management is important to an organization.    There are three reasons:

1.  It helps organizations execute projects effectively (getting the right things done)
2.  It helps organizations execute projects efficiently (getting things done right)
3.  It helps organizations achieve strategic objectives.

This last reason is important to emphasize, because there is a tendency to think of projects as simply on the level of tactics, i.e., the actual means of achieving an objective.  However, the project manager should consider himself or herself as a strategic ambassador, by learning from the sponsor what the strategic objectives of the organization are that the project will be tied to.   This is important in motivating team members who may not be aware of the larger impact their efforts on the project may have after the project has been completed.   But it also has a pragmatic component, because the project manager can take an active role in preventing changes that would jeopardize that strategic objective from being realized!

It is possible to overemphasize the importance of projects?   There are some in the agile community who feel that there is too much focus on projects and too little on products.   In the next post, I will discuss a post by Anthony Mersino in his review of the Agile Practice Guide on his blog Vitality Chicago which tries to put projects in the larger context of product development.

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

In section 1.2.1, PMI introduces the definition of projects (discussed in the previous two posts) and it is then immediately followed by the relationship between project management and change management (this was covered in the previous post).   Then it goes on to show the relationship between project management and

• business analysis (determination of the business value created by a project)
• business strategy (the context in which a project is initiated by an organization)

When you ask the question of why a project is being created, there are two answers to the question.   One reason is because the entity requesting the project to be done wants to derive some business value or benefit from it.   The determination of what business value is created by a project is called the business analysis.    This was discussed in the previous post.

Business strategy

But the other reason is that project will align with the strategic objectives of the organization doing the project.

There are four general categories PMI gives for the context in which a project may be initiated:

1. Meet regulatory, legal, or social requirements
2. Satisfy stakeholder requests or needs
3. Create, improve, or fix products, processes, or services
4. Implement or change business or technological strategies

There are several examples of specific factors that correspond to these four categories listed in Table 1-1 on page 9 of the Guide.   Some of them, such as “legal requirements”, fit one category (“meet regulatory, legal, or social requirements”), while others, such as “market demand”, fit several categories (all of the categories above except the first one).

Because the business strategy of an organization is central to the reason for the project being created in the first place, it is important for the project manager to understand what that strategy is for a very pragmatic reason:   if conditions arise that prevent the project from aligning with the business strategy of an organization, or if that business strategy changes, then that project may be terminated by the sponsor!

The next section 1.2.2 of the Guide, discusses the importance of project management from the standpoint of effectiveness and efficiency.   That is the subject of the next post.

Filed under: Uncategorized | 1 Comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

In section 1.2.1, PMI introduces the definition of projects (discussed in the previous two posts) and it is then immediately followed by the relationship between project management and change management (this was covered in the previous post).   Then it goes on to show the relationship between project management and business analysis, which determines the business value that the project is designed to create.

This relationship between project management and business analysis is made explicit in PMI’s new publication “Business Analysis for Practitioners:  A Practice Guide.”   But for the purpose of this introductory section on project management, PMI defines business value as

“the benefit that the results of a specific project provides to its stakeholders”

and it can take the following forms:

“the return, in the form of time, money, goods or intangibles in return for something exchanged.”

Here are some important points to consider regarding this statement.

1.  When people think of “business value”, they might think of money, which is normally thought of when you hear the phrase “bottom line”.   But there are intangible benefits that a company could create a project for, such as brand recognition, reputation, or even goodwill.
2. The description of business value as a benefit for stakeholders is reflected in the name for one of the two project business documents that are inputs to the creation of the project charter:  the “project benefits management plan.”   The “project business case” shows how the project will create business value for the stakeholders, but the “project benefits management plan” shows how this business value, once created, will be maximized and sustained over time.

Because the creation of business value is central to the reason for the project being created in the first place, it is important for the project manager to understand what that value is for a very pragmatic reason:   if conditions arise that prevent the project from creating business value for the stakeholders, then that project may be terminated by the sponsor!

When you ask the question of why a project is being created, there are two answers to the question.    One reason is because the entity requesting the project to be done wants to derive some business value or benefit from it.    But the other reason is that project will align with the strategic objectives of the entity doing the project.   That topic is the subject of the next section in the Guide and will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

In section 1.2.1, PMI introduces the definition of projects (discussed in the previous two posts) and it is then immediately followed by this bold statement:

“Projects drive change”

This is a declaration that a project manager is, almost by the very nature of what he or she is doing, also a change agent!

The reason why this statement leaped out of the page for me was that I had just been just recently discussing the subject with Elizabeth Allen, a project manager in the PMO at Nemours Children’s Health System for 12 years who has been leading change efforts for +25 years.  She is preparing a presentation for the PMI Global Conference to be held in Chicago in late October 2017 (next month).    The title of her talk is “Becoming a Holistic Agent of Change.”  In it she describes some of the theoretical models of how organizations process change, but she also recounts some of the personal experiences she had on a recent project involving change of a hospital system.   The statement she made that struck me was that every project manager is automatically a change agent, and managing the resistance to change is part of what makes a project manager effective in his or her job.

Although what she said I thought was intuitively true, I didn’t realize that PMI would be stating it at the very beginning of the new PMBOK® Guide!   In the section describing the relationship between project and change management, PMI announced that it has published its own guide to change management called “Managing Change in Organizations:  A Practice Guide.”   In terms of knowledge areas in the PMBOK® Guide, the biggest impact a greater understanding of change management would have for a project manager is probably in the area of Stakeholder Management (Chapter 13).  This is because many stakeholders within the organization will be the source of resistance to a project for the simple reason that is does represent change to that organization.   This is probably more true for internal projects whose objectives are to change the business processes of the organization rather than external projects that are done for customers.

So in this section, PMI makes explicit the relationship between project management and change management, and it puts “skin in the game” by announcing its own change management guide.    It also put the fire of ambition into me, as I now want to study change management after I finish studying for and passing the Project Management Professional exam!

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide which was released last week by the Project Management Institute and blogging about the contents.   The first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).    This section starts with the definition of a project, a good place as any to start:

“A project is a temporary endeavor undertaken to create a unique product, service, or result.”

As I mentioned in yesterday’s post, the key words in this definition are “temporary” and “unique.”   I discussed the “unique” aspect of projects in yesterday’s post; I wanted to focus on the other key word today and that is “temporary.”   In an organization, a project stands in contrast to its regular operations, which if not permanent, are at least continuous (ongoing) or continual (happening repeatedly at regular intervals).

But the PMBOK® Guide, in discussing on page 6 the fact that a project is a temporary endeavor, mentions another important aspect of a project.   When exactly does it end?    Well, since the definition of a project is an endeavor to create a unique product, service, or result, it makes sense that a project ends when its objectives have been achieved.

But a project can also end when the objectives will not or cannot be achieved for the following reasons:

• funding for the project is exhausted, or the human and/or physical resources are no longer available
• the business need for the project no longer exists
• legal cause or regulatory change

All of these reasons are discussed in an upcoming section on why a project is initiated in the first place.   When those reasons go away, so can the project!

Besides being a general point that is important to understand, knowing that a project can be terminated when it can no longer achieve its objective will help you when you study for the Project Management Professional (PMP).

Here are some examples of questions that illustrate the point described above.

Question:   You are the project manager on a project and your sponsor gives you the news that upper management is terminating your project because it can no longer serve the business need for which it was started in the first place.    What process are you now in?

Answer:   Close Project or Phase (process 4.7).

When the project is terminated by the sponsor, all work on the project itself will cease, but you as a project manager will still have to complete the final process, which is Close Project or Phase.    Although the product, service or result of the project will not be realized, that doesn’t mean that the project was a total “waste of time.”   However, it will be unless you do this process.   The people working on your project team will be released to pursue new projects, but before they go, it is important for you and your team to document the knowledge gained by you and your team while you were doing the project by creating a final register of the lessons learned so that other projects may benefit from your efforts.   That knowledge will help other project managers in getting their projects to the finish line!

Here’s a more technical question involving earned value measurement, but related to the same topic.

Question:    during the Close Project or Phase process, what will the SPI be?

A) greater than one

B) equal to one

C) less than one

D) all of the above are possible

Answer:  the correct answer is d).   In order to understand this, let’s review what the SPI is.   It stands for the Schedule Performance Index, and is taken to be the cumulative Earned Value or EV (the value of the actual work done on the project) divided by the Planned Value or PV (the value of the work that was planned to be done on the project).

If your project has achieved the objectives, then the actual work done (EV) should equal what was planned to be done (PV), and therefore EV/PV = 1.0.   However, if your project was terminated because the project was not able to achieve the project objectives, then the actual work done (EV) will be LESS than what was planned to be done (PV), in which case EV/PV < 1.

Can the SPI be greater than one at the end of a project?    If SPI is greater than one at the end of a project, then that implies that the actual work done (EV) is GREATER than what was planned to be done, which means that in order to achieve the objectives, you had to do more work than you had planned on doing.   So it is possible, although obviously not an ideal situation.

As a side note, you can end up having more project scope than you planned for, as in this scenario when you had to do more work than you planned to get to the finish line, but about the product scope?   Can you have more product scope than you planned for, i.e., more features and requirements in your final product than were called for in your original requirement?   The answer to this according to PMI is a resounding “NO!”, because this would be doing something called “gold plating,” which is giving the customer something that he or she did NOT ask for, and may not be something that the customer even wants.

So in conclusion, a project is a temporary endeavor, which means it will end, but it can end either because it does or does not meet its objectives.   The next post introduces a very important concept about projects, which is that they drive change.   So any project manager therefore is automatically a change agent!

Filed under: Uncategorized | Leave a comment »

Today I am starting a project of going through the 6th Edition of the PMBOK® Guide which was released last week by the Project Management Institute and blogging about the contents.    I blogged about the contents of the 4th Edition in order to prepare for the Certified Associated in Project Management (CAPM) certification exam; I blogged about the contents of the 5th Edition in order to lead a study group of PMI members who were studying for the Project Management Professional (PMP) certification exam, and now I am blogging about the 6th Edition to take the exam myself when it becomes available in the first quarter of 2018.

The first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).    My first question on cracking open the new 6th Edition was “has the definition of a project changed?”   The answer is no; it is as follows

“A project is a temporary endeavor undertaken to create a unique product, service, or result.”

The key words here, I believe, are “temporary” and “unique.”  What you should be doing in thinking of this definition is not just what a project is, but what it is not:   it contrasts with the regular operations of a business or organization which are activities that are “ongoing” and often “repetitive.”   Also important is the fact that the project is done for a specific purpose, although that purpose may be tangible (a product), intangible (a result), or something in between (a service).

Let’s think about an example to clarify one’s understanding of the definition, one that I take from my professional experience.

Scenario A–The Reserve Project

Company A is an insurance company which is required by insurance regulations to calculate the reserves it is holding for its insurance claims.   The reserves represent the amount of money set aside for the insurance company to meet future payments associated with claims incurred but not yet settled.    The reserves have to be calculated by the ending of each fiscal year, and so three months before that date, Company A initiates the “Reserve Project,” which has as its goal the calculation of the reserves to be reported to the insurance regulatory agencies.    To achieve this result, a project manager is chosen to lead the claims adjusters, who act as the project team members carrying out the project.    A budget and a schedule are created, usually copied from the previous year when the same project was done last time.

Question:   Is this a project according to PMI’s definition?

Answer:    Although the company calls it a project, it is really more along the lines of a business operation.    Yes, it may have some surface singularities to a project, in that it is done for a specific purpose, a manager is assigned to manage the activities, there is a schedule and budget, etc., but the key words in the scenario are “the same project was done last time.”   It is not a unique result, but the same result that has to be done in the same way at the same time every year.    It is an operational activity, albeit one that is done not continuously throughout the year, but continually (i.e., done at regular intervals at a specific time of the year).

Scenario B–A Six Sigma Project

Company B creates a unique product, but then discovers that there is a defect in the product.    They decide to do what is called a “Six Sigma project” which will go and correct this defect.

Question:  Is this a project according to PMI’s definition?

Answer:   Although the answer might not be clear in the basic definition, in the explanatory paragraphs below the definition, PMI goes into more detail and says that a “unique product” can be any of the following:

• a component of another item
• an enhancement or correction to an item, or
• a new end item in itself (e.g. the correction of a defect in an end item).

A Six-Sigma project would definitely fall into the last of these definitions, since it is correcting a defect in an end item which had been created in a previous project.

This post covers the portion of the definition which contains the word “unique”; the next post will cover the portion of the definition which contains the word “temporary.”   Additional posts in this series will cover the relationship between project management and change management, the creation of business value, and the factors which cause organizations to initiate projects in the first place.

Filed under: Uncategorized | 2 Comments »

On Friday, September 22nd, I received my copy of the 6th Edition of the Guide to the Project Management Body of Knowledge (or PMBOK® Guide for short).

I did a brief review of the individual changes from the 5th to the 6th edition with yesterday’s post on September 23rd.   Before I start going through the new PMBOK® Guide from cover to cover, I wanted to say that my first macro-impression was that this new Guide truly represents not just the current state-of-the-art of project management, but also of future of project management as well.

This is because, as I mentioned in yesterday’s post, not only does the new PMBOK® Guide come with an Agile Practice Guide companion, but each knowledge area comes with a section that explain how to adapt the contents to an agile project management environment.    This is why I feel it represents the future of project management, which is not a mindset that thinks of “agile vs. traditional” methodologies, but a hybrid “agile + traditional” mindset.  I have watched several presentations by thought leaders describing what project management will look like 10 to 15 years from now, and they concur with this prediction.

The other positive development I see in an institutional one, because the Agile Practice Guide that accompanies the PMBOK® Guide is written by the Project Management Institute (PMI) in collaboration with the Agile Alliance®.   There is a tendency with institutions like PMI that are setting standards to want to build their “brand” as being the authoritative one, and this goal, understandable as it is, could have led PMI to decrease, rather than increase, their cooperation with those other institutions.    I’m relieved to see evidence of this cooperation because in my opinion that focuses on the needs of the members.   Many of those members are going to be either members of other standard-setting groups and/or alliances or they are going to interact with those members, and the Agile Practice Guide will encourage those interactions.

What does this mean for MY particular future?    I got the Certified Associate in Project Management (CAPM) back in October 2012, and this certification has a five-year lifespan.    In the meanwhile, I have been volunteering on projects for my local PMI chapter here in Chicago and more recently with PMI Global in preparation for their Project Management Global conference that will take place next month (October) in Chicago.   I have been using this volunteer experience towards the experience requirement for getting the top-level certification, the Project Management Professional or PMP certification.

But as October 2017 came closer and closer this year, I heard the rumor that the new 6th Edition PMBOK® Guide had a lot more content related to agile methodologies and I decided that rather than taking the PMP based on the 5th Edition, I would wait until the 6th Edition came out in late September so that when I passed the test, I could tell prospective employers that my PMP certification was “state-of-the-art” because it was based on the latest edition of that PMBOK® Guide.

However, there is still no certain date of when you can go and take the PMP exam based on the new 6th Edition of the PMBOK® Guide, although rumors have it that it will sometime in the first quarter of 2018.    So I decided to do the following:

• Retake the CAPM exam now, so that in case my first attempt at taking the PMP doesn’t work out, I’ll still have a project management certification to fall back on.  (This is basic risk management…)
• Blog on the contents of the 6th Edition, not only to understand them for myself but also to help those in my local PMI chapter and elsewhere who aim like to me to take the PMP exam based on the new material.
• Wait until PMI announces an official date for the exam.   If it’s in the first quarter of 2018, then three to six months time would be enough to cover the contents of the new 6th Edition in my blog, and then to look to one of the exam prep companies (Velociteach, RMC, etc.) to see when they come out with their preparation materials.

If PMI decides to put out the PMP certification exam material in the second quarter or later, then I may have to rethink this strategy, perhaps by going ahead with the PMP exam based on the 5th Edition material which I know backwards and forwards (not just because of my blog, but because I ran a PMP exam study group for my local PMI chapter when I was the Director of Certification there).    I would in that case have the certification but still be able to tell prospective employers that I’m aware of the new 6th Edition contents as well because of my work in the next few months to blog about them.

So as you can see, the new 6th Edition of the PMBOK® Guide has helped me map out my future in my deepening relationship with the world of project management, and I hope that you can use it to do the same!

Filed under: Uncategorized | Leave a comment »