6th Edition PMBOK® Guide–Process 4.1 Develop Project Charter Inputs (3)


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.   This post starts a series of posts on the first project management process, process 4.1 Develop Project Charter.

In a previous post, I answered some general questions people have on the process itself.  Now I am going into the details of the inputs to this process.   Here are the four inputs to the process 4.1 Develop Project Charter

  1. Business documents
  2. Agreements
  3. Enterprise environmental factors
  4. Organizational process assets

The last two inputs are generic inputs you see with many project management processes; I won’t spend a lot of time on them.   The second input, Agreements, is for when you are doing a project for an external organization.   “Agreements” are the PMI term of art for legal contracts.   That input is the subject of today’s post.

Agreements are contracts which are mutually binding that obligate the seller to provide the specified products, service, or result (this is specified in the statement of work).   In exchange, the buyer will compensate the seller for the work done.

This input is optional, that is, it only exists if the project is being done for the external customer.   If the project is being done for the organization itself, then the statement of work will be supplied separately, usually in the business case document.

In the agreement, the following components may appear (the entire list is on p. 489 of the Guide):

  • Procurement statement of work (narrative description of the product, service, or result that needs to be produced by the project)
  • Time constraints (schedule deadlines)
  • Pricing and payment terms
  • Change request handling procedures
  • Inspection, quality, and acceptance criteria

These are the key components:   for example, the “inspection, quality, and acceptance criteria” will specify what the objective basis will be for the customer to finally accept the product the project is designed to produce.

The other two inputs, EEFs (environmental enterprise factors) and OPAs (organizational process assets), are more generic and will not be discussed in a separate post.

Next, we will discuss the tools & techniques used to carry out the process 4.1 Develop Project Charter once the inputs have been gathered…

 

Advertisements

6th Edition PMBOK® Guide–Process 4.1 Develop Project Charter Inputs (2)


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.   This post starts a series of posts on the first project management process, process 4.1 Develop Project Charter.

In a previous post, I answered some general questions people have on the process itself.  Now I am going into the details of the inputs to this process.   Here are the four inputs to the process 4.1 Develop Project Charter

  1. Business documents
  2. Agreements
  3. Enterprise environmental factors
  4. Organizational process assets

The last two inputs are generic inputs you see with many project management processes; I won’t spend a lot of time on them.   The second input, Agreements, is for when you are doing a project for an external organization.   “Agreements” are the PMI term of art for legal contracts.   That input is the subject of today’s post.

Agreements are contracts which are mutually binding that obligate the seller to provide the specified products, service, or result (this is specified in the statement of work).   In exchange, the buyer will compensate the seller for the work done.

This input is optional, that is, it only exists if the project is being done for the external customer.   If the project is being done for the organization itself, then the statement of work will be supplied separately, usually in the business case document.

In the agreement, the following components may appear (the entire list is on p. 489 of the Guide):

  • Procurement statement of work (narrative description of the product, service, or result that needs to be produced by the project)
  • Time constraints (schedule deadlines)
  • Pricing and payment terms
  • Change request handling procedures
  • Inspection, quality, and acceptance criteria

These are the key components:   for example, the “inspection, quality, and acceptance criteria” will specify what the objective basis will be for the customer to finally accept the product the project is designed to produce.

The other two inputs, EEFs (environmental enterprise factors) and OPAs (organizational process assets), are more generic and will not be discussed in a separate post.

Next, we will discuss the tools & techniques used to carry out the process 4.1 Develop Project Charter once the inputs have been gathered…

 

6th Edition PMBOK® Guide–Process 4.1 Develop Project Charter Inputs (1)


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.   This post starts a series of posts on the first project management process, process 4.1 Develop Project Charter.

In the last post, I answered some general questions people have on the process it.   Now I am going into the details of the inputs to this process.   Here are the four inputs to the process 4.1 Develop Project Charter

  1. Business documents
  2. Agreements
  3. Enterprise environmental factors
  4. Organizational process assets

The last two inputs are generic inputs you see with many project management processes; I won’t spend a lot of time on them.   The second input, Agreements, is for when you are doing a project for an external organization.   “Agreements” are the PMI term of art for legal contracts.   The first input, Business documents, has two components

  • Business case
  • Benefits management plan

The business case document has been around for a while; the benefits management plan, however, is a new document that PMI proposes be done in conjunction with the business case document.    The business case document shows how business value or benefits are going to be created by the project; the benefits management plan shows how those benefits, once created by the project, will be maintained by the organization that does the project.

Since both of these business documents are important for the creation of the project charter, let me do a post on each of them.   In this post, therefore, I’ll start with a description of the business case document.

Business case

The business case puts together three elements that answer three questions:

  • What is the product, service, or result to be delivered by the project?   This narrative description is sometimes referred to as the statement of work.   Consider it the “seed” of the project.   A seed contains the DNA of an organism, its genetic blueprint of what it will become once it germinates and comes to fruition.  Similarly, the statement of work contains the conceptual blueprint of what the project will create once it comes to fruition.
  • Why is the project being done?   This question is being asked from the standpoint of who is the recipient of the benefit of the project:   it could be the customer, or in the case of an internal project, a department or even an entire organization.    This is the business need, and the project could be being done inresponse to market demand, organizational need, customer request, technological advance, legal requirement, ecological impact, or social need.
  • Why is the project being done?   This question is being asked from the standpoint of the organization doing the project:   it answers a strategic objective of the company

030713_2143_3.png

You put these three together and you get:   the business case document!    Now, please make a distinction between the business need and the business case.   The business need is the reason why the project is being done.   The document that puts together the product scope description (aka the statement of work), the business need, and the strategic plan of the organization is the business case.

There may be also be a cost-benefit analysis, showing that the project is expected to achieve a certain objective measure of benefits in relationship to the costs of the project.  This is important!    For example, let’s say your project was picked because it had a higher benefit-cost ratio than other projects that could have been selected.   What happens if there are a lot of cost overruns on your project as it is being executed?   Then the benefit-cost ratio will go down, and perhaps become unfavorable to some of those other projects which will now be looking like good investments in comparison.   This could lead to your having the plug being pulled on your project.

Now, the business case document is not a project document, but a business document, and it is often created by business analysts.   One of the trends in project management is to have project managers involved in what normally is done by business analysts, like helping create the business case document.   This is also the case of the other business document, the benefits management plan, which will be the subject of the next post.

6th Edition PMBOK® Guide–Process 4.1 Develop Project Charter


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.   This post starts a series of posts on the first project management process, process 4.1 Develop Project Charter.

Before we get into the nitty-gritty of the inputs, tools & techniques, and outputs of this process, let’s have a post on a general description of the project charter and what it does.  Here are five questions answered with regards to the project charter…

What is the purpose of a project charter?

A project charter authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

Who writes the project charter?

The project charter is signed by the project sponsor, and is usually created by the sponsor as well.   In some cases, the project manager is brought on board after the project charter is created; however, PMI prefers that a project sponsor bring the project manager on board while the project charter is being developed.

What are the benefits of the project charter process for the organization?

  • It links the project with the strategic objectives of the organization
  • It creates a formal record of the project
  • It shows the organizational commitment of resources to the project

What is the relationship of a project charter to a contract?

The project charter itself is not a contract.   In the case of an external customer, a formal contract is typically the preferred way to establish an agreement.   This agreement is in fact one of the inputs to the process 4.1 Develop Project Charter.   What the project charter is an internal agreement within an organization to ensure proper delivery under the contract.

Why is it important for the project manager to study the project charter carefully?

It contains high-level information on practically all the knowledge areas that the project manager will encounter on the project.   Also, the business documents will demonstrate the larger context in which the project takes place and understanding them will allow the project manager to understand not just what the project will create, but why it is being done in the first place.

 

 

 

6th Edition PMBOK® Guide–Project Integration Management Overview


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter on the first of the 10 knowledge areas, that of Project Integration Management.

In the past two posts, I gave some preliminary information on what types of integration (vertical, horizontal) that integration management requires, and also what the major trends are in integration management.

Today I start on the general overview of integration management and the 7 project management processes it encompasses.

Integration management

This is the knowledge area which is used to unity and coordinate the various processes and activities within the five project management processes and the other 9 knowledge areas.   This means more specifically that there is a lot of connection between these 7 integration management processes and the other 42 processes.   To give you an example, the monitoring and controlling process group for all of the other 9 knowledge areas produces the output of change requests related to each area, and these change requests are then input into process 4.6 Perform Integrated Change Control.   As another example, the planning process group for all of the other 9 knowledge areas produces the output of management plans for each area, and these individual management plans are then inputs into 4.2 Develop Project Management Plan.

For those teaching courses to prepare students for the PMP exam, it is often a legitimate question as to whether teach material in chapter 4 Integration Management first (because it’s the first chapter out of 10 covering knowledge areas) or last (because understanding its contents are so dependent on understanding the contents of the other knowledge areas which it integrates).   I’m going to follow the order they are presented in the PMBOK® Guide and present them first.

7 processes

Initiating Process Group

4.1 Develop Project Charter–formally authorizes the existence of a project and provides the project manager with authority to apply organizational resources to project activities

Planning Process Group

4.2 Develop Project Management Plan–coordinates all individual project management plan components derived from other knowledge areas and consolidates them into the overall Project Management Plan

Executing Process Group

4.3 Direct and Manage Project Work–leads the performance of all work defined in the project management plan and to implement any approved changes to that plan in order to achieve the project objectives.

4.4 Manage Project Knowledge–uses existing knowledge and creating new knowledge (lessons learned) to achieve the project’s objectives and to contribute to organizational learning.

Monitoring and Controlling Process Group

4.5 Monitor and Control Project Work–tracks, reviews, and reports on overall progress to meet the performance objectives defined in the project management plan.

4.6 Perform Integrated Change Control–reviews all change requests, approves and manages changes to the deliverables or to the project management plan.

Closing Process Group

4.7 Close Project or Phase–finalizes all activities in the project relating to the completion of deliverables, the resources used on the project, or the documentation of the project.

These are THE key activities on any project, which is why Integration Management processes are vital to learn and to deeply understand.   So we’ll start with the first process, 4.1 Develop Project Charter, in the next post.

 

6th Edition PMBOK® Guide–Project Integration Management (2)


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter today on the first of the 10 knowledge areas, that of Project Integration Management.

Before going through the 7 processes that are included in this knowledge area, I wanted to state some preliminary ideas presented by PMI in their 6th Edition of the PMBOK® Guide.   In the last post, I discussed the various types of integration that a project manager must master in order to master the profession.   In this post, I talk about some trends and emerging practices in project integration management.

  • Automated tools-it is necessary to use a Project Management Information System nowadays (such as Microsoft Project or Primavera) in order to manage the amount of data and information necessary to run a project successfully.   However, they are only useful if you are well versed in the processes which use these data, so that you can understand their context and what they mean for your project and its success.
  • Visual management tools–this is an influence from agile, that uses kanban and other visual methods to make process flow more transparent to all members of the team.
  • Project knowledge management–this means storing knowledge gained during the project and using it to prevent repeating mistakes.   Lessons learned is not an exercise at the end of a project anymore like it used to be; again as an influence from agile, it is a “continuous improvement” effort during the lifecycle of the project.
  • Expanding the project manager’s responsibilities–sometimes project managers are not just tasked with taking an existing project charter written by a sponsor and understanding its key elements, but sometimes they are also asked by a sponsor to create it themselves.   Also, the business case development and a plan for the management of the business value created by the project, traditionally done by business analysts, is sometimes also being asked of project managers.
  • Hybrid methodologies–project managers are expected to be fluent not only in traditional waterfall methodologies, the main focus of the PMBOK Guide, but are also needed to be conversant (if not fluent) in agile methodologies, which are the main focus of the Agile Practice Guide that accompanies the 6th edition of the PMBOK Guide.

It is because we live in an increasingly connected world that project managers are expected to carry out additional roles that they weren’t expected to before.   So there is one solution:   EVOLVE!

6th Edition PMBOK® Guide–Project Integration Management


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 now that I am done reviewing the first three chapters on projects, the environment in which they are done, and the role of the project manager, I am excited to start the fourth chapter today on the first of the 10 knowledge areas, that of Project Integration Management.

Before going through the 7 processes that are included in this knowledge area, I wanted to state some preliminary ideas presented by PMI in their 6th Edition of the PMBOK® Guide.

Project managers integrate both horizontally and vertically

This point is described on p. 66 of the Guide.

Horizontal integration:  A project manager integrates the team to work together on the project, and integration here also means integrating the various processes from the 10 knowledge areas.   For example, each knowledge area produces its own management plan which is then integrated into the all-encompassing Project Management Plan in one of the key Integration Management processes, 4.2 Develop Project management Plan.

Vertical integration:   A project manager works with the project sponsor to understand the strategic objectives and business case of the project to ensure that the project objectives and the deliverables that are the outcome of the project remain aligned with those of the program, portfolio, and business operations of the organization.

Project managers integrate at three levels:  cognitive, process, and context

This point is described on p. 67 of the Guide.

 

Cognitive level:   project managers needs to be proficient in all Project Management knowledge areas, in business management skills, and in leadership skills.   These are the components of the PMI Talent Triangle® which a project manager needs to integrate in order to have “full-spectrum competence” (my term).

Process level:   project managers need to integrate the various processes in all knowledge areas and process groups.   That is why integration management is so important a knowledge area for project managers because that is exactly what it does.

Context level:   as mentioned in the previous comment on vertical integration, a project manager needs to be aware of the project context (the strategic objectives and business case that are the basis of the project being done), and the organizational context (the various departments of the organization, the various business units in the organization based in different locations, or even multiple organizations for projects being done in partnership).

If this all this seems daunting, don’t worry:   take it one step at a time and master Integration Management!   Before we get into the weeds by discussing the various processes in Integration Management, lets discuss some of the trends and emerging practices in Integration Management.   That will be the subject of the next post…