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.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 previous posts, I discussed the project life cycle and project phases.   In the last post, I discussed how the 49 processes of project management are divided into five process groups.    In this post, I will discuss how the 49 processes are also divided among ten knowledge areas.

The ten knowledge areas are:

1. Integration–processes that combine, unify and coordinate the various project management activities within the five process groups.
2. Scope–processes that ensure the project includes all the work required, and only the work required, to complete the project successfully
3. Schedule–processes that manage the timely completion of the project
4. Cost–processes that plan, estimate, fund, manage, and control costs so the project can be completed within the approved budget
5. Quality–processes for incorporating the organization’s quality policy regarding planning, managing and controlling project and product quality requirements in order to meet stakeholders’ expectations.
6. Resource–processes that identify, acquire, and manage the resources needed for the successfully completion of the project.
7. Communications–processes required to ensure the planning, creation, distribution, control and monitoring of project informations
8. Risk–processes for planning risk management, the identification, analysis, and monitoring of risks on a project, and the implementation of risk responses.
9. Procurement–processes necessary to purchase or acquire products, services, or results needed from outside the project team.
10. Stakeholder–processes required to identify stakeholders, to analyze their expectations and impact on the project, and to develop management strategies for effectively engaging stakeholders in decisions that affect the project.

Okay, those are the ten knowledge areas as defined in the PMBOK® Guide.   If I were ordering the knowledge areas, I would have put the tenth knowledge area, Project Stakeholder Management, right between Communications and Risk.   Why?   Let’s put the knowledge areas into groups

Group 1–Integration

The first knowledge area Integration ties together the processes from all the other nine knowledge areas.    It has some of the most important processes on a project, from its inception (4.1 Create Project Charter) to its conclusion (4.7 Close Project or Phase).

Group 2–Constraints

The main constraints you will be dealing with on a project are Scope, Schedule, Cost, and Quality, which represent knowledge areas #2 through #5.   Schedule and Cost are pretty self-explanatory, but what is the difference between Scope and Quality Management.  Scope management has as its goal the completeness of the work; Quality management has as its goal the correctness of the work.

Group 3–People

Knowledge areas #6 (Resources), #7 (Communications), and #10 (Stakeholders) deal with the people either on the project or related to the project.   Resources used to be called Human Resources in the previous edition of the Guide; Human Resources and material resources have been combined to create a knowledge area that covers them both.    But despite the trend of de-humanizing our vocabulary over the years from “staff” to “personnel” to “human resources” to “resources”, this knowledge area still deals in large part with people.   (This will be true even in the future when PMI starts referring to  “carbon-based production units”–in the end we’re still talking about people.)    #7 Communications deals with the communications of people within a project and the communications between people on the project and the group of people effected by the project, the stakeholders.  That is why #10 Stakeholders should be considered part of this group, because you are not just trying to communicate with stakeholders, you are trying to influence them to get them more positively engaged in the project.

Group 4–Resources

These are resources used on a project, so they can include #6 Resources and #9 Procurement, which obtains products, services or results from outside the organization.

NOTE:   #9 Procurement is the only knowledge area that is potentially optional on a project, in the sense that a project may be done solely based on the resources available within the organization itself, in which case procurement from outside the organization would not be needed.

Group 5–Risk

If I were ordering the knowledge areas, Stakeholder Management would be put in between #7 Communications and #8 Risk Management, rather than having it be stuck at the end as #10.   Why?

Stakeholder Management is related to Communications Management–in fact, it is an outgrowth of the latter knowledge area, because you have to communicate with stakeholders in order to influence them.

But it is also related in a less obvious way to Risk Management.   Why?

Risk are defined as events which can positively or negatively impact a project.   Stakeholders are people who are either impacted by a project, or who can positively or negatively impact a project.   You see the connection with risk?    In both cases, you are dealing with uncertainties that may impact your project.    They are different in that, with risks, since they are events, you can’t engage them or negotiate with them.   You can’t stick your head out the window and demand that it stop raining so you can make it to your car without getting wet.   However, you can mitigate the impact of that rain by the simple expedient of–taking an umbrella with to shield you from the rain.   That is an example of a risk response.

With people, there are ways of engaging them and hopefully being able to influence them in a way to make them more favorable to your project.

But those five groups are my take on how these ten knowledge areas are put together.
Here’s how they stack up in terms of the number of processes in each:

1. Integration (7 processes)
2. Scope (6 processes)
3. Schedule (6 processes)
4. Cost (4 processes)
5. Quality (3 processes)
6. Resource (6 processes)
7. Communications (3 processes)
8. Risk (7 processes)
9. Procurement (3 processes)
10. Stakeholder (4 processes)

For how each process fits in each category of process group and knowledge areas, check out the chart on page 25 of the Guide.

In the next post, I will discuss the processes themselves–their component parts (inputs, tools and techniques, outputs), and how they fit together on a project.

Filed under: Uncategorized | Leave a comment »

Toastmasters International has decided that many of the newer struggling districts around the world have trouble putting on two conferences a year, so they have said that starting in 2018, districts will put on only one conference a year in the Spring.   So that meant that the Fall Conference I went to today for District 103 is going to be the last one I ever go to!

The reason why this conference was special was not just because it was the last one.  Some notable events happened:

• Mike Rafferty, Past International Director and former Regional Advisor, announced that the new Toastmasters educational program called Pathways will be rolled out in our District in February of next year.   That’s only about three and a half months away!    He was recruiting Ambassadors and Guides for the new program and I volunteered to be both.
• Don Williams, our Club Growth Director, said in terms of adding new clubs, we are on track for becoming a President’s Distinguished District.   As the Club Retention Chair, a position that is essentially that of being an assistant to the Club Growth Director responsible for getting club coaches for struggling clubs, I hope to help out District become a President’s Distinguished District by making sure that clubs that are struggling stay above water in the 2017-2018.   In this way, there are least no more additional clubs required to make up for ones that close.
• The announcement was made that the International Conference will be held from August 22-25, 2018–right here in Chicago!   That’s another reason for working hard to become a President’s Distinguished District–because our district will then receive an award on the world stage!
• Jeff Stein, a Toastmasters acquaintance from the Windy City Professional Speakers Club (now in District 30) introduced me to Stephanie Kowalyk, the Club Retention Chair from District 30.   District 103, representing downtown Chicago and the South Suburbs, was split off from District 30, which now represents only the North Suburbs.   She and I realized we were in parallel positions in the District leadership in our respective districts, so we had a long talk about challenges we both faced.  We realized it would be a good idea to collaborate for that very reason.

I’m so glad I went to the conference, which was a lot more intimate that last year’s Fall Conference mainly because it was half the size.   After all, District 30 and District 103 were split last year, District 30 getting five out of the previous nine divisions and District 103 getting the remaining nine.   Being smaller has its advantages, not just because those who competing in contests have a greater chance, but because organizing on a district-wide basis is also a lot easier with four divisions rather than nine to worry about.   Although many grumbled about the split, it certainly was in retrospect a good idea!   Now with only a Spring Conference to worry about in the future, life will get even simpler in the District.

However, I will miss Fall Conferences because they were a part of the Toastmasters seasons of the year.   They were the finale of the first six months of the Toastmasters year, to be followed by the Winter Toastmasters Leadership Institute in December getting ready for the final six months.   I will miss the fun and fellowship–as I remarked to a fellow conference goer, the Fall Conference felt like a trip to the Toastmasters version of Disneyland!

Filed under: Uncategorized | 2 Comments »

The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.    In the 4.1 Develop Project Charter, the project manager is in contact with the project sponsor and the key stakeholders in order to develop the information in the project charter, the output of that process.

In the process 4.2 Develop Project Management Plan, the project manager is in contact with the project team and subject matter experts in order to develop the subsidiary management plans that end up being the main inputs to the process.   They are also the same people involved in the process of integrating them into the overall Project Management Plan.   Some of the subject matter experts the project manager can consult with may be key stakeholders.

The output of the process 4.2 Develop Project Management Plan is, not surprisingly, the Project Management Plan.   There are a total of 18 management plan components and 33 project documents.   Let’s organize these elements.

A.  Subsidiary management plans

These are the management plans that are the output of the planning processes for all of the other 9 knowledge areas:

• Scope management plan
• Schedule management plan
• Cost management plan
• Quality management plan
• Resource management plan
• Communications management plan
• Risk management plan
• Procurement management plan
• Stakeholder engagement plan

B.  Supplemental management plans

I list the knowledge area that these supplemental management plans are most closely connected with.

• Requirements management plan–establishes how the requirements will be analyzed, documented, and managed (Scope Management)
• Change management plan–describes how the change requests will be formally approved and incorporated into the project work (Integration Management)
• Configuration management plan–describes the version of the product, service or result that the project will create so that it will be produced consistently

C.  Baselines

• Scope baseline–consists of the scope statement, work breakdown structure (WBS), and its associated WBS dictionary
• Schedule baseline–approve version of the schedule model that is used as a basis for comparison to the actual results.
• Cost baseline–approved version of the time-phased project budget that is used as a basis for comparison to the actual results.
• Performance management baseline–an optional baseline that is an integrated scope-schedule-cost plan for the project work against which project execution is compared to in order to measure and manage performance (essentially a combination of the three baselines listed above)

D.  Additional components

• Product life cycle description–describes the series of phases that a project passes through from its initiation to its closure
• Development approach–describes the development approach, such as predictive, iterative/incremental, agile, or hybrid

E.   Project documents

They are usually the outputs of the planning process for each of the knowledge areas, and so they are listed below with the knowledge area they are related to.

• Integration–assumption log, change log, issue log, lessons learned register, milestone list
• Scope–project scope statement, requirements documentation, requirements traceability matrix
• Schedule–activity attributes, activity list, basis of estimates, duration estimates, project calendars, project schedule, project schedule network diagram, schedule data, schedule forecasts
• Cost–cost estimates, cost forecasts
• Quality–quality control measurements, quality metrics, quality report, test and evaluation documents
• Resources–physical resource assignments, project team assignments, resource breakdown structure, resource calendars, resource requirements, team charter
• Communications–project communications
• Risk–risk register, risk report
• Procurements
• Stakeholder–stakeholder register

As you can see, the only knowledge area that doesn’t have a project document associated with it is the procurements knowledge area, and that is because this is the only knowledge area that is optional:   if the project is done using only internal resources, then procurement of services and/or materials is not needed.

Most of these project management plan components, whether they are planning documents or are the repository of information such as the project documents listed above, will end up being inputs to the next process, which is 4.3 Direct and Manage Project Work.   This process will be the subject of the next post.

Filed under: Uncategorized | 1 Comment »

The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.    In the 4.1 Develop Project Charter, the project manager is in contact with the project sponsor and the key stakeholders in order to develop the information in the project charter, the output of that process.

In the process 4.2 Develop Project Management Plan, the project manager is in contact with the project team and subject matter experts in order to develop the subsidiary management plans that end up being the main inputs to the process.   They are also the same people involved in the process of integrating them into the overall Project Management Plan.   Some of the subject matter experts the project manager can consult with may be key stakeholders.

Here are the inputs to process 4.2 Develop Project Management Plan:

1. Project Charter
2. Outputs from other processes
3. Enterprise Environmental factors
4. Operational Process Assets

How do you approach the project team members and subject matter experts in order to  to create the subsidiary plans and then the overall project management plan?   That is where the tools & techniques come into play.   Here they are:

Expert judgment

Talk to stakeholders and/or subject matter experts who know about

• tailoring the project management process to meet the project needs
• developing additional components of the project management plan if needed
• determining which project documents will be used to apply to the project

Data gathering

• Brainstorming–two-part process consisting of a) idea generation and b) analysis, used to gather ideas and solutions about the project approach.
• Focus groups–discussion of project management approach and the integration of the different components of the project management plan.
• Interviews–used to obtain specific information from stakeholders to develop the project management plan.
• Checklists–the project manager can use these to verify that all the required information is included in the project management plan.

Interpersonal and team skills

• Conflict management–bringing stakeholders into alignment with the project management plan.
• Facilitation–Effective participation by all members of the project team ensures that the project management plan has full buy-in according to the decision making process established for the project.
• Meeting management–ensures that meetings are efficient and well-run in addition to being effective in developing the project management plan.

Meetings

Held with project team to discuss the project approach, how the work will be executed, and the way the project will be monitored and controlled.

The kick-off meeting is associated for larger projects with the end of planning and the start of executing; however, for smaller projects, the kick-off may occur after initiation at the start of planning.

The output of the process is (as the title Develop Project Management Plan suggests) the project management plan, and it contains many components.   I will go over these in the next post on the outputs of process 4.2 Develop Project Management Plan.

Filed under: Uncategorized | Leave a comment »

The process 4.2 Develop Project Management Plan is the first of the processes in the Integration Management knowledge area in the Planning process group.   The previous process 4.1 Develop Project Charter was in the Initiating process group.

Here are the inputs to process 4.2 Develop Project Management Plan:

1. Project Charter
2. Outputs from other processes
3. Enterprise Environmental factors
4. Operational Process Assets

The first input, Project Charter, is the output of process 4.1 Develop Project Charter.   The second input, the vaguely named “Outputs from other processes”, are essentially all of the outputs of the management plan processes from the other nine knowledge areas, what PMI calls subsidiary management plans.    These will be listed in detail in the post on the outputs of this process.   So this process is not one of the first planning processes to be done, but rather one of the last because it ties together the results of all of the other planning processes.

The other two inputs are what I call the generic inputs, because they are inputs to a great many processes.

The next post will cover what tools and techniques are used to put together the project management plan.   They are close to the tools and techniques used in putting together the project charter, but instead of mainly involving the stakeholders, for this process they will mainly involve the project team.

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 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.    Let’s assume that, as a project manager, you have been tasked by the sponsor to create the project charter.  What should you put in it?

Of course, the main purpose of the project charter is for the project sponsor to give the project manager authority to use the organization’s resources to do the project.   But the secondary purpose is for the project manager to go into the project with as much high-level information about the project as possible when he or she goes into the planning phase.   So what I’ve done is I’ve gone through the list of items that PMI recommends putting in the project charter, and I’ve divided them into the 10 knowledge areas covered by the PMBOK® Guide.

1. Integration–project purpose, project approval requirements, name and authority of the project sponsor, assigned project manager,
2. Scope–measurable project objectives
3. Schedule–summary milestone schedule
4. Cost–pre-approved financial resources
5. Quality–high-level requirements, project success/exit criteria
6. Resources–project manager responsibility and authority level
7. Communications (see Stakeholders)
8. Risk–overall project risk
9. Procurement (optional only if project is external)
10. Stakeholders–key stakeholder list

As you can see, most of the knowledge areas will have some element of high-level information included in the project charter.   As mentioned in a previous post, much of the information to be included in the project charter can be found in one particular input, that of the business case document.

And since much of the information required in the project charter will come from key stakeholders, this is why the one other process that is included in the Initiating Process Group is 13.1 Identify Stakeholders.

Note that the other output for the Develop Project Charter process is the assumptions log, which lists high-level strategic and operational assumptions and constraints.   The reason why these are put in a separate log is that these assumptions need to be revisited periodically during the project (in the Monitoring and Controlling Process Group) to make sure they are still true.    If the conditions listed in the assumption log change for whatever reason, they might directly impact the project and need to be paid immediately attention to.

Two items which PMI did not explicitly put in the PMBOK® Guide on p. 81 but which are important nonetheless are

Pre-assigned human resources–these are people whom the project sponsor wants to have working on the project.   These will then be highlighted in the Resource Management Plan so that these people can be included on the project if at all possible

Exclusions–besides giving a general description of the project objectives, a good tool for preventing unnecessary changes is to have exclusions, that is, listing those objectives which the project sponsor explicitly is wanting to have excluded from the product, service or result which the project will create.    If a key stakeholder suggests one of these excluded objectives, then the project manager will have additional authority to say no by virtue of the fact that the project sponsor has said “no” right in the project charter.

This concludes my discussion of the project charter.   The process of creating it is the first integration management process.   Once you as the project manager have the project charter in hand, it’s off to the races, right?   No, you have to do Process 4.2 Develop Project Management Plan, and that is the subject of the next series of posts.

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 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.    Let’s assume that, as a project manager, you have been tasked by the sponsor to create the project charter.  How would you go about doing it?

In the last posts, I discussed the inputs you need to develop the project charter, namely:

• Business documents
• Agreements
• Enterprise environmental factors
• Organizational process assets

The key document here is the business case document, one of the two business document inputs listed above.   It may contain the following key pieces of information that will help you put together the project charter.

• Project purpose (business need)
• Measurable project objectives and related success criteria
• Identification of scope
• Identification of known risks
• Recommended milestones
• Identification of key stakeholders

With the information on this business case document, you already are getting some of the information you need for the project charter, PLUS you are getting a list of key stakeholders whom will contact to get the rest of the information you need.

How do you approach the stakeholders to get that information?   That is where the tools & techniques come into play.   Here they are:

Expert judgment

Talk to stakeholders and/or subject matter experts who know about

• organizational strategy so the project is aligned with it
• technical knowledge of the industry
• benefits management (departments that will receive the results of the project)
• duration and budget estimation
• risk identification

Data gathering

• Brainstorming–two-part process consisting of a) idea generation and b) analysis.
• Focus groups–bring in groups of stakeholders and subject matter experts to learn about project risk and success criteria
• Interviews–rather than talking to groups of stakeholders, talking to them individually to find out about assumptions and/or constraints, high-level requirements, and approval criteria.

Interpersonal and team skills

• Conflict management–bringing stakeholders into alignment regarding objectives, success criteria, high-level requirements, project description, summary milestones.
• Facilitation–Effectively guiding a group event (such as a focus group) to a successful decision or conclusion.
• Meeting management–ensuring key stakeholders are invited to meetings, preparing an agenda, and then sending follow-up meeting minutes and action items.

Meetings

Held with key stakeholders to identify the project objectives, success criteria, key deliverables, high-level requirements, summary milestones.

These are used in conjunction with each other, so at the early stage, you would use data gathering tools & techniques and expert judgment, then follow up with meetings using interpersonal and team skills.

The result will be the project charter, the elements of which will be discussed in the next post on outputs.

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 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…

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 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…

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 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

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.

Filed under: Uncategorized | Leave a comment »