6th Edition PMBOK® Guide–Organizational Governnance Frameworks


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 second chapter is a general introduction to the framework in which project management exists, starting with section 2.1 Project Influences.

Looking back on the first chapter, it contained the foundational elements of project management, showing in many cases the internal structure of a project.   The second chapter concentrates more on the exterior of a project, to the environments in which projects operate.  These environments can influence a project either favorably or negatively, and that is why a project manager needs to be aware of them.

In the past two posts, I discussed the two categories of project influences:

  • Environmental Enterprise Factors (EEFs)–conditions not under control of the project team that influence the project; these can be internal and/or external to the organization
  • Operational Process Assets (OPAs)–processes, policies, procedures, and knowledge bases that are specific to the organization

There is another form of influence on a project, and that is the governance framework of an organization.   Is an organization focused on operations, on projects, or something in between?    The type of organizational structure will influence many things on a project, such as

  • project manager’s authority
  • project manager’s role
  • availability of resources
  • management of the project budget
  • administrative staff on the project (the project management team)

I think the Table on p. 47 of the various types of organizational structure is a bit confusing, so I’m going to go through the types of organizational structure type in a series of posts to make sure the person studying for the test understands the strengths and weaknesses of each type, at least from the standpoint of a project manager.

In the next posts, I will discuss functional (focused on operations), project-oriented (focused on projects), matrix (focused somewhere in between operations and projects), and some other additional types (hybrid, composite).

6th Edition PMBOK® Guide–Organizational Process Assets


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 second chapter is a general introduction to the framework in which project management exists, starting with section 2.1 Project Influences.

Looking back on the first chapter, it contained the foundational elements of project management, showing in many cases the internal structure of a project.   The second chapter concentrates more on the exterior of a project, to the environments in which projects operate.  These environments can influence a project either favorably or negatively, and that is why a project manager needs to be aware of them.

Figure 2.1 on page 37 show the two categories of project influencers:

  • Enterprise environmental factors–these are conditions which are not under control of the project team, that influence, constrain, or direct the project.  They can be either internal to the organization (such as organization culture) or external to the organization (such as legal restrictions).
  • Organizational process assets–these are the business practices or knowledge bases  specific to an organization which can influence the management of the project.  Examples include processes, policies and procedures.

This post will go into more detail into operational process assets.  Operational process assets are the plans, processes, policies. procedures, and knowledge bases specific to an organization.

In an earlier post on the concept of tailoring, the idea was discussed where the PMBOK® Guide was likened to a hardware store that has tools and materials to serve all types of customers, from the casual DIY homeowner to a corporation that builds skyscrapers.    The tools the customer needs will vary based on the type of project that is needed to be done.

In a similar way, the PMBOK® Guide contains all of the project management tools you could possibly use on a project, but the organization must then choose from that giant toolbox those tools that are useful to that organization.   It is that collection of processes, in addition to business policies and procedures, that make up one category of Operational Process Assets or OPAs.   The other category of OPAs would be organizational knowledge bases, especially those pertaining to previous projects done by the organization.    Although the first category are not updated as part of the project work, the knowledge bases are updated as a result of the compiling of lessons learned during the project.

This is why operational process assets are often generic inputs to many processes, whereas operational process assets updates are often outputs of those very processes.

Examples of OPAs in either category of a) processes, policies, and procedures and b) organizational knowledge bases are contained on pages 40 and 41 of the Guide.

The next post starts a review of the next section 2.4 on Organizational Systems.

6th Edition PMBOK® Guide–Enterprise Environmental Factors


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 second chapter is a general introduction to the framework in which project management exists, starting with section 2.1 Project Influences.

Looking back on the first chapter, it contained the foundational elements of project management, showing in many cases the internal structure of a project.   The second chapter concentrates more on the exterior of a project, to the environments in which projects operate.  These environments can influence a project either favorably or negatively, and that is why a project manager needs to be aware of them.

Figure 2.1 on page 37 show the two categories of project influencers:

  • Enterprise environmental factors–these are conditions which are not under control of the project team, that influence, constrain, or direct the project.  They can be either internal to the organization (such as organization culture) or external to the organization (such as legal restrictions).
  • Organizational process assets–these are the business practices or knowledge bases  specific to an organization which can influence the management of the project.  Examples include processes, policies and procedures.

This post will go into more detail into enterprise environmental factors.

There are certain categories of events or people that can influence a project.   Events that can influence a project are called risks, and there is a whole knowledge area devoted to identifying them, classifying them, and preparing risk responses to them.    People that can influence a project are called stakeholders, and there is a whole knowledge area devoted to identifying them, creating a strategy for engaging them and then carrying it out.

Enterprise environmental factors are more nebulous than either risks or people; they are conditions which can influence a project.   As such, they are out of control of the project team in a way that risks and shareholders are not, because they can at least be influenced.    It is important for project managers to be aware of the environmental enterprise factors or EEFs that may affect their project.   On a practical note for those studying for the PMP® exam, EEFs are what I call a “generic” input into project management processes, meaning that they are inputs to a great number of those processes.   Why?  Because that process will be influenced or shaped by one or more of those EEFs.

Okay, now what are some of the EEFs?   They are outside of the control of the project team, but they may be either internal to the organization or external to it.

Here are some of the internal EEFs.

  • Organizational culture–the values, code of ethics, and leadership style of management
  • Information technology software–this includes scheduling tools such as Microsoft Project or Primavera.
  • Infrastructure–information technology hardware and telecommunications channels.

There are additional ones listed on page 38 of the Guide, but this gives you an idea of what kind of EEFs are internal to an organization.   NOTE:   Please remember that the software you use on a project is considered an environmental factor or EEF and NOT an organizational process asset or OPA.   This is a mistake that many make on the exam.

What are some of the external EEFs?

  • Social and cultural influences–the culture of a country you are doing business with will influence how you interact with the team members, stakeholders, or customers from that country (see Erin Meyer’s book The Culture Map for a rich resource that goes into this topic in depth)
  • Legal restrictions–national, state and/or local laws and regulations
  • Physical environment–weather and working conditions

There are other examples on p. 39, but you can see from the above list that some EEFs such as legal restrictions will  more directly affect specific projects that deal with the products or services that are covered by those laws and regulations.   Others such as the physical environment will more generally affect the project, not to mention the operations of a particular organization.

The other category of project influences are organizational process assets or OPAs.   They are the processes, policies, and procedures of an organization, as well as their knowledge bases.   They will be the subject of the next post.

6th Edition PMBOK® Guide–Project Influences


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 second chapter is a general introduction to the framework in which project management exists, starting with section 2.1 Project Influences.

Looking back on the first chapter, it contained the foundational elements of project management, showing in many cases the internal structure of a project.   The second chapter concentrates more on the exterior of a project, to the environments in which projects operate.  These environments can influence a project either favorably or negatively, and that is why a project manager needs to be aware of them.

Figure 2.1 on page 37 show the two categories of project influencers:

  • Enterprise environmental factors–these are conditions which are not under control of the project team, that influence, constrain, or direct the project.  They can be either internal to the organization (such as organization culture) or external to the organization (such as legal restrictions).
  • Organizational process assets–these are the business practices or knowledge bases  specific to an organization which can influence the management of the project.  Examples include processes, policies and procedures.

From a practical standpoint for someone who is studying for the Project Management Professional (PMP®) exam, you should know that environmental environmental factors are often abbreviated as EEFs and organization process assets are often abbreviated as OPAs.   Because they influence how a project is done, they are “generic” inputs to many of the project management processes you will need to learn.

The next two posts go into some detail about the various kinds of EEFs and OPAs.

6th Edition PMBOK® Guide–Project Success Criteria


On reviewing the 6th Edition PMBOK® Guide–I’m taking on the last section of the first chapter, namely, the section on project success criteria.

Stakeholders may differ on makes a project successful, so it is important to state the project objectives that are clear and measurable.

They may link up to the business need fulfilled by the project or to the organizational strategy.   The more they do so, the higher chance the project has to succeed.

6th Edition PMBOK® Guide–Project Management Benefits Plan


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.6 Project Management Business Documents.   These are two documents which are inputs into the first project management process 4.1 Project Charter.   If these are inputs into the first project management process that are created even before the project is initiated, then where do they come from?   They are actually outputs of Business Analysis, and so they are essentially the intersection between Business Analysis and Project Management.

The two project management business documents are:

  • Project business case–this is an economic feasibility study which demonstrates the benefits or business value to be created as a result of the project
  • Project benefits management plan–describes how the benefits created as a result of the project will be maintained after the project is done

In the last post, I discussed the project business case, which is a document that has been recommended by PMI before in previous editions of the Guide.   The new document for the 6th Edition is the project benefits management plan.    What is this document for?   What elements should be in it?   This post will answer those questions.

What is this document for?

The project business case is a document which demonstrates the benefits or business value that the project is designed to create.    The word “benefits” is a good one, but it may confuse people, because it sounds like the project management benefits plan is something that has to do with HR, like “how many days of sick leave do I get when I’m on the project?”

The project management benefits plan takes those benefits or business value that the project is designed to create and shows how it will be maintained after the project is done and the results of the project become part of the organization’s ongoing operations.  In other words, it is designed to make sure that the benefits of the project are made permanent, even though the project itself is a temporary one.

Here are the elements PMI proposes should be in the project management benefits plan:

  • Target benefits–what is the expected tangible and intangible value of the benefits
  • Strategic alignment–how do the benefits align with the business strategies of the organization
  • Timeframe for realizing benefits–short-term, long-term, ongoing, etc.
  • Benefits owner–who is assigned to monitor the realized benefits throughout the timeframe
  • Metrics–direct and indirect measures to show benefits realized
  • Assumptions–factors expected to be in place in order for benefits to be realized
  • Risks–what are the risks to the realization of benefits

Now, these documents which are created through the process of business analysis are then passed on to the project as inputs to the first project management process Develop Project Charter.

The last topic in this section on foundational elements of project management is that of project success measures, and that is the topic of the next post.

6th Edition PMBOK® Guide–Project Business Case


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.6 Project Management Business Documents.   These are two documents which are inputs into the first project management process 4.1 Project Charter.   If these are inputs into the first project management process that are created even before the project is initiated, then where do they come from?   They are actually outputs of Business Analysis, and so they are essentially the intersection between Business Analysis and Project Management.

The two project management business documents are:

  • Project business case–this is an economic feasibility study which demonstrates the benefits or business value to be created as a result of the project
  • Project benefits management plan–describes how the benefits created as a result of the project will be maintained after the project is done

The project business case should be a familiar document to PMPs, because it was  described back in the previous edition of the PMBOK® Guide.   However, the document that is new for the 6th Edition of the Guide is the project benefits management plan.   In this post I will cover the project business case.

021413_0424_2.png

Here are the main elements of the business case.

  • Product scope description–There is a description of the product, service, or result that is being proposed to be produced by the project.   This answers the question “What” objective is the project going to create.
  • Business need–what is the benefit or business value that is going to be created as a result of the project.   This answers the question “Why” is the project going to create its objective–from the standpoint of the stakeholder who will receive the benefit of the project.
  • Strategic plan–what strategic goal or objective that will be achieved by doing the project?   This answers the question “Why” is the project going to create its objective–from the standpoint of the organization doing the project.

These elements are combined in the project business case document as indicated in the graphic above.   (Please note that the downward motion of the elements as they get processed together in the business case is NOT indicative of any editorial comment on my part that the project is going down the drain, or any other similar conclusion.)

It is important to distinguish the business need and the business case, because the terms are similar.   The former is the reason for the project to be done; the latter is the document that explains why it should be done.

There are additional details that can be included in the project business case, and these are listed on p. 31.   These are much more elaborate than those listed in the previous edition of the Guide, which shows the increasing importance PMI is placing on this document.

The question that the project business case answers is “what benefit or business value will be created by the project?”  However, how does an organization make sure those benefits are not as temporary as the project?   That is the purpose of the project management benefits plan, the other business document that is an input to the Develop Project Charter project, and it is the subject of the next post.

 

6th Edition PMBOK® Guide–Tailoring PMBOK to Your Project


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.5 Tailoring.   After the components of a project were presented in the previous section, this short section focuses on the following simple but important truth:   not every tool, technique, input or output identified in the PMBOK® Guide is required on every project.    The PMBOK® Guide was not created in a vacuum; it is the sum total of knowledge from experience on projects that is generally recognized as good practice.

What this means in practical terms is that each organization has to decide what elements of project management from the PMBOK® Guide will be used; PMI cannot give specific recommendations for what to include.

A good analogy to explain this is to think of the PMBOK® Guide as a hardware store that is visited by people with various needs for tools.    A homeowner who wants to fix a kitchen sink is doing a project that will require a very limited range of tools and materials.   On the other hand, a building contractor who is going to remodel a kitchen is going to require a lot more extensive set of tools and materials.   The hardware store caters to all, and includes all of the tools and materials you would need on any type of project, no matter what the scope.    Similarly, the PMBOK® Guide contains tools and techniques to be used on projects with budget anywhere from a few hundred dollars to several million dollars.    It is up the person doing the project to know what tools and techniques will be needed.

This shows the importance of the project management plan, because this will describe, out of the entire arsenal of project management tools and techniques that are described in the PMBOK® Guide, which ones the organization plans to use for any given knowledge area.

Now for the test taker, the practical import of this is that, no matter what tools and techniques you have used in the past, you will have to learn the tools and techniques available in the entirety of the PMBOK® Guide, no matter whether you ever plan to use them on a project or not.    Because some day, you may need to use them, and this knowledge will become practical.

The next post will talk about project management business documents.   In reality, these documents are artifacts from the field of business analysis, which intersects with project management at the very beginning of the project.   This has been a very fruitful area of growth for PMI since the last edition of the PMBOK® Guide, so make sure to look at it!

 

6th Edition PMBOK® Guide–Project Management Data and Information


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.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).   In the section I am covering today, 1.2.4.7 Project Management Data and Information, it discusses some of the common outputs of project management processes, namely, work data, work information, and work reports.    Let’s answer some questions on these three categories.

How are they different?

Here’s how they relate to each other:   data → information → reports.   More specifically,

  • Work performance data are raw observations and measurements identified during activities that carry out the project work.   They are produced as outputs of Executing processes.   (Examples:  percent work completed, start and finish dates of schedule activities, actual costs, actual durations of activities)
  • The work performance data are then inputs into Controlling Processes, which are then analyzed and integrated based on relationships across knowledge areas to become work performance information that can be used by the project team.    They are produced as outputs of Controlling Processes of the various knowledge areas.  (Examples:   status of deliverables or change requests, earned value estimates of project status and forecasts for project completion).
  • The work performance information is input into the Overall Project Control process (4.5 Monitor and Control Project Work) in the Integration knowledge area, where it is compiled and then represented in documents called work performance reports which are then distributed not just to the project team but to stakeholders.   (Examples:  status reports, electronic dashboards, memos, recommendations.)

For more details, see Figure 1-7 Project Data, Information and Report Flow on page 27 of the Guide.

Example of data and information flow

Here’s an example.   Let’s say I am working as a project manager and I want to find out how things went on the project yesterday and then report the status to my stakeholders.  I find out how much time the project team members spent on the various activities they were supposed to do yesterday.    John worked 4 hours and Mary worked 4 hours.   Great.   This is an example of work performance data, which in this case is focused on the actual work done.

Now, I take a look at the project plan and compare the actual work done with the work that was planned to be done yesterday.    Well, John was supposed to work 4 hours on the project, so that’s okay, but Mary was supposed to work 6 hours but only worked 4 hours.  Oops!   Using earned value management, I can say that the SPI is 0.80.   The schedule performance index is derived by taking the actual hours worked (8) and dividing this number by the number of hours that were planned to be worked (10).   By using the work performance data and comparing it to the project plan, I have now created work performance information that can be used by the project team.   We not only know that we are behind schedule, but by precisely how much (2 hours).   In our project team meetings, we can then go into the reason why.   Let’s suppose it turns out that Mary’s functional manager wouldn’t let her work six hours on the project because of some urgent work she had to do for her department.    After talking to the functional manager, you find out that the urgent work is done, and she can work an extra two hours on the project tomorrow to make up for the time lost today.

You then prepare a work performance report, which informs the stakeholders that the project is behind schedule, but that the reason for this has been ascertained and the project is forecast to be on schedule again at the end of the next day.   You then promise to update them tomorrow after you make sure that this delay has been corrected.

So to recap, the work performance data takes the actuals, and compares them with the plan to produce the work performance information, and this is further analyzed and compiled into a work performance report which tells the stakeholders what they need to know:   the work is temporarily behind schedule, but corrective action is in the process of being taken.

This concludes the section 1.2.4 on Components of the Project.

The next section 1.2.5 talks about tailoring the standard for project management described in the 6th Edition of the PMBOK® Guide to fit a given project.   That will be the subject of my next post…

 

 

 

 

6th Edition PMBOK® Guide–Project Management Processes


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.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In the last posts, I discussed the project life cycle, project phases, and the five process groups and ten knowledge areas that project management processes are divided into.   In this post, I will discuss the project management processes themselves:  what they consist of, how they fit together, and how to study them for the exam.

Processes–what do they consist of?

In section 1.2.4.4 on Project Management Processes, processes are defined as a series of activities that take inputs,  and utilize tools & techniques to produce outputs .   

How do they fit together?

In most cases, the outputs of one process with then become the inputs to other processes, and this is how they are connected together.

How many processes are there in project management?

There are 49 processes, which are distributed between the five process groups and ten knowledge areas.   See page 25 of the Guide for Table 1-4 which shows how they are distributed.

How do I study them for the exam?

You should take a blank sheet of paper, and draw the table on p. 25 or create your own template grid that you can print out.    If you can do it on ledger size (11 x 17) paper it will be the easiest to use, but use letter or even better yet, legal size paper to do the exercise.    You should find some index cards and put the name of the process on one side, and then on the other side put the name plus the numerical designation of the process based on the Table 1-4 on page 25.   For example, the first process in Integration is 4.1 Develop Project Charter.   You would put “Project Charter” on one side, and then “4.1 Develop Project Charter on the other.”

  • Try to memorize the position that the process would take on the grid, namely, in the Initiating Process Group under the Integration Knowledge Area.
  • Do this for all of the 7 processes in the Integration Knowledge Area, then shuffle the cards, and then looking at the side of the card with just the name of the process, try to guess where it goes.    It should only take a couple of tries, probably 5 at the most, to be able to master this knowledge area.
  • Then take the next knowledge area of Scope, memorize the location of those processes, and then combine the two sets of index cards and see if you can remember all of the locations for the two knowledge areas.
  • Keep adding knowledge areas until you have memorized the locations of all of the 49 processes in all of the knowledge areas.
  • Next:   now you have to remember the name of the processes, and do this by taking a blank card and thinking of the first process in Integration Management.    Put it on the grid and when you are done with filling in index cards and putting them on the grid, check your results with the grid on p. 25.
  • Continue this for all of the knowledge areas until you can recreate the chart within 15 minutes from scratch.

The ultimate goal should be to recreate the chart from scratch in 15 minutes because that’s how much time it takes to go through the tutorial at the beginning of the PMP exam.    You can multitask and recreate the chart in the time it takes to go through the tutorial which contains information about how to take the test, most of which is self-explanatory anyway.

As far as memorizing the inputs, tools & techniques, and outputs, it is good to study them, but trying to memorize all of those would be a monumental task, and the most important thing is not to memorize, but to understand them.   If you understand what it is that the process does, then figuring out which of 4 possible choices could be inputs for that process is a matter of logic and understanding, rather than one of memorization.

That being said, there are some patterns that show up with inputs and outputs, and I will create posts at a later time for how to deal with exam questions dealing with them.

The next post covers the topic of how data is created during a project, how it is turned into information that is usable by the project team, and how this information is packaged into reports that are usable by the stakeholders.