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

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.

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.

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.

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

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

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the third chapter discusses the role of the project manager.

This is a continuation of yesterday’s post, which discussed ways in which a project manager can increase his or her sphere of influence when it comes to vertical relationships, that is, relationships to subordinates (project team members) or to those you directly report to in the organization (sponsor, upper management).   In this post, I wanted to talk about interacting in horizontal relationships, that is, with other project managers.

PMOs

One way to increase one’s sphere of influence is to advance the efficacy of the PMO in one’s organization.   This will have one interacting with other peers and trying to see things from their viewpoint.   For example, if you have a Cost Performance Index or CPI of 2.0 on your project, this means that for every dollar you were given, you got twice as much work out of that dollar that was planned for.   You may think that makes you a hero for using only half the resources you were given, but from a program manager’s standpoint, this presents a problem:   somehow your project took twice as many resources as you actually needed that have been allocated to your project and may be needed for others that are in the same program.    So understanding the project from the program manager’s viewpoint in terms of how resources are shared between projects will help your relationship that with individual tremendously.

PMI

Of course, the way to get to network with other project managers who are not in your organization is to join the local chapter of the Project Management Institute.   Your monthly chapter meetings will usually have a guest speaker who has been chosen to present a topic on the cutting edge of the profession.   This plus the opportunities to get to know your peers on a professional and even a personal level makes it a great opportunity to expand your sphere of influence outside of your company.

Volunteers

Now this option was not mentioned by PMI at all, but I wanted to include it because it has been helpful for me.   I came to Chicago in 2013 after having decided to become a project manager.   When I joined the local Chicagoland chapter of PMI, I went to a local chapter dinner meeting where I met the VP of Education, Ravi Avasarala.   He was looking for someone to take on the role as Director of Certification and I told him I had assisted the Director back in Orange County, California, to put on the PMP exam prep class sponsored by the chapter.   This led to my not only becoming a Director, but assisting on special projects for the chapter such as putting on the PM Symposium in 2013 and 2014, in the first year as a project manager handling speakers, and then a program manager overseeing the entire event.   That got me the attention of Amy Martin, the VP of Business Outreach, who was looking for a volunteer to be the Director of the Executive Council, and to assist with the annual Leadership Forum in 2016 and 2017.   All of these projects have given me enough experience hours to apply for the PMP exam when the new one becomes available next April!

Another opportunity I was given by Amy Martin was to put me in contact with PMI Global, who asked me to help coordinate volunteers from our local PMI chapter for the PMI Global Conference which takes place in Chicago this year.   Since I was also a Distinguished Toastmaster, they also asked me to get volunteers who were in both the PMI Chicagoland chapter and the local PMI Toastmasters Club to assist at the global conference to help speakers who were doing their first speech on the global stage.   In fact, in about 15 minutes, after I finish this post, I will going to the PMI Global Conference  here in Chicago as a volunteer–an opportunity I never would have had if I hadn’t been so eager to volunteer way back when I first started as a PMI local chapter member a few years back.  So if you REALLY want to increase your influence as a project manager, give to your local chapter not just by paying a membership fee, but by donating your time as a volunteer.  You will get back paid many times over in terms of the opportunities for your career that will open up!

Filed under: Uncategorized | Leave a comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the third chapter discusses the role of the project manager.

This topic is an interesting one, because it dovetails nicely with the concept of stakeholders.    There is a graphic I created for my blog on the 5th edition of the PMBOK® Guide that illustrated the concept of the various levels of stakeholders better than the diagram contained in the Guide itself.

If you look at the Figure 3-1 Example of Project Manager’s Sphere of Influence on p. 58 of the 6th Edition of the PMBOK® Guide, you’ll see a diagram that looks similar.    Whether or not the folks at PMI were influenced by the graphic on my earlier blog or not, I’m pleased that they put it in the 6th Edition because it shows the various levels of a project manager’s sphere of influence.

Remember that a stakeholder is someone who can influence a project or who will be influenced by the outcome of a project.    The important concept in this chapter is that the project manager can influence back, meaning that it is the role of the project manager to project his or her influence to various levels of people in order to achieve success on a project.

Project Team

The most immediate impact will be internal to the project itself, meaning the members of the project team.   The project manager may have a project management team, which means those who are assisting in his or her role as a project manager, such as a project coordinator (with limited decision-making authority), a project expediter or project scheduler (with no decision-making authority).   Those not assisting in this role and who are doing the work of the project are simply the project team.   A project manager should treat team members with respect and adjust his or her style of leadership to fit the experience level and, if possible, the personality type of the team member.

Resource Managers

The book has the term “resource managers”, which is a stand-in for the concepts of physical resource managers (including procurement managers) and human resource managers.   Of course this also includes functional managers, because in a matrix organization, the people that will be staffing a project will be those who are already in a functional department, and they are being released by the functional manager from their regular work to do work on a temporary basis for the project.   As such, it is important for the project manager to not abuse the privilege and use the resources for more time than they have been allotted for the project.   You need to motivate the resource to work on your project, and you should show gratitude to the functional manager for being able to use the resource by not abusing the privilege and making that person work more hours than they were scheduled.   If more work needs to be done than was planned for, it’s best to change the plan.

Sponsors

Of course, this is the most important relationship outside of the project, and a project manager can influence a sponsor by not simply taking problems to be solved to him or her, but by taking problems with a menu of options for solutions to be chosen.   That makes the sponsor’s life easier and will boost your influence when the sponsor needs to champion your project with upper management.

PMOs

The project management office has been tasked by upper management to direct and possibly even control project manager activities.    There is no point in resenting their “interference” in your project because they are just doing their job, at least the way that they interpret it.    Don’t be afraid to ask for advice–a good PMO is not going to be made nervous by a project manager asking questions.   They are made nervous when they don’t hear anything at all, because they don’t know if there is a problem or not.    And if they do an audit, take their suggestions on improvement in the spirit that was intended, to help make you a better project manager.

Stakeholders

This could be the customers or end users if it is a product you are creating; it could be  upper management in the case of a internal project where you are creating a service or result for your own organization.    If there are dissenting voices that are opposing the project, at least listen to their point of view.   The fact that you have listened to them, even if you are forced to override their opinions, will make them respect you more than if you had simply ignored them.

These are just some examples of how to use relationships skills to improve the influence you have as a project manager.   This post focused primarily on vertical relationships, relationships with those who are either in superior or in subordinate positions to you within the organization.   The next post will talk about horizontal relationships, that is interactions with other project managers:   those within the organization, those outside the organization within the same industry, and/or project managers in general.

Filed under: Uncategorized | 1 Comment »

I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the third chapter discusses the role of the project manager.

In the first section 3.1 Overview, a useful analogy is made between a project manager and an orchestra conductor in the following areas:

• Membership and roles–a project and an orchestra are both made up of many members, each playing a different role, and the project manager, like the orchestra conductor is the leader of the team.
• Responsibility for team–both the project manager and orchestra conductor are responsible for the outcome of what their teams produce, and they need to take a  holistic view of their team and the product of their work in order to make sure the objectives (a project on the one hand, and a concern on the other) are successfully achieved.
• Knowledge and skills–a project manager needs to know enough about project management to lead the team, but does not need to know enough to do every role on the project.  He or she will be relying to an extent on the technical expertise of the members of the team, just in the same way that an orchestra conductor may lead the violin players as part of the orchestra without being able to play the violin.

The second section 3.2 is the subject of the next post.

Filed under: Uncategorized | Leave a comment »