This consists of six processes:
• Develop project charter
• Develop project management plan
• Direct and manage project work
• Monitor and control project work
• Perform Integrated change control
• Close project or phase
This knowledge area is concerned with identifying defining the work of the project and then combining and integrating with the appropriate processes
It also includes managing issues and change, and re-planning if required.
There are two tools which fall with this process.
They are earned Value management and the use of project management software such as Microsoft Project.
I will go into detail of each process, but first here are two summary diagrams of the Integration Management Knowledge Area:
The project charter officially recognizes and acknowledges that the project exists, it is created during the develop project charter process and it explains the business need of the project.
It names and authorizes the project manager and is signed off by the performing organizations senior management.
It contains the high-level project requirements, and a milestone view of the project schedule, and will also have a summary level preliminary project budget.
The main input is the project charter itself, as it will detail the goals and objectives of the project, a description of the scope, and any constraints and assumptions.
It is used as a key input for the development of the project management plan.
This is the time-frame it will take the organization to recoup its investment from the product of the project. The calculation involves the sum of the expected cash inflows, compared against the original investment, and to calculate how many time periods (typically years), before the cash inflows equal the initial investment.
These are the project statement of work, the contract (if this is appropriate), the project Business Case explaining why the project is being undertaken, the problem that it will solve the Benefit Cost Analysis, the enterprise environmental factors and the organizational process assets.
This explains why the project is needed, what opportunity or problem it will solve, what the benefits are and what risks need to be managed:
The project may be started for many reasons, and these are the historic drivers:
These measure the value of the product or service that the project will produce and compare this against the benefits realized by the organization, and they fall into two categories; benefit measurement methods and mathematical models.
You may find these also describes as decision models, which compares different criteria, and calculation methods which calculate the value of the project. Both are used to aid project selection decision making.
Mathematical models are complex formulas and algorithms, also known as constrained optimization methods. Benefit measurement methods which you must understand and calculate include benefit cost ratio (BCR), internal rate of return (IRR), economic value add (EVA), present value (PV), net present value (NPV), payback period, return on investment (ROI), opportunity cost, and return on invested capital (ROIC). I shall go into more detail on these in this chapter.
The statement of work should contain the following information:
• The business need
• The product scope description (writing product descriptions). These can serve as the S. O. W. (if the project is contracting to a vendor)
• The strategic plan (This is the organisations strategic plan, and the project manager will need to make reference to it). This merely ensures that the project is in line with the organization’s strategic direction)
These other factors that are outside of the project, and hence the project must make sure that it is aligned with them within the project charter. They include:
• Organisational culture and structure
• governmental or industry standards
• human resources
• personnel administration
• organisations work authorization system
• marketplace conditions
• stakeholder risk tolerance
• commercial databases
• project management information systems
All of these aspects can influence the way that the project is managed.
These are, as the name suggests, valuable information that can be used on each project within the project charter, and are updated and added to if appropriate on each project, thus increasing these assets for future projects. They can be such aspects as:
• Approaches or standards.
Other aspects include:
• project management policies
• safety policies
• performance measurement criteria
• financial controls
• communication requirements
• issue and defect management procedures
• change control procedures
• risk control procedures
• procedures used for authorizing work
• historical information (these should be examined when starting a project)
• lessons learned reports
• Tools and techniques for the project charter
Most organisations are “opportunity rich and resource limited”. This normally means that not all projects can be done — due to resource constraints. There needs to be some method which will prioritize possible projects.
Often projects are selected as a preference by those with power and authority within an organisation.
There are two categories of selection method for the Project Charter:
• Benefit measurement methods
These methods are known as decision models and calculation methods — these will now be discussed:
• Mathematical models
Mathematical modelling uses advanced techniques that are beyond the scope of PMP. For the record, they include linear, dynamic, integer, non-linear, and/or multi objective programming.
There are many methods used to select a project, but many qualify the monetary benefits plus expected costs against the project result, and compare these to other potential projects. Such a method is usually called ‘benefit measurement methods’.
Discounted cash flow
You remember the time value of money? If I was a bank, I would charge interest to borrowers. This is because for every dollar I loan them, it will be worth less for every year by wait for the loan to be repaid.
This extra amount that I should charge for the loan can be calculated by a well-known formula:
PV = Mt/ (1+r) t
Mt is the amount of payment‘t’ years from today; r is the interest or discount rate.
This formula would be applied to several projects to see which of them provides the best investment.
Projects will involve some form of funding at initiation, and the payback period is simply the length of time then it takes all the company to recoup these initial costs. For example, if the initial project funding is $100,000 and the revenue stream is $20,000 a month, then the payback period is five months
As you can see, this method does not consider revenue streams of the payback, and is therefore the least accurate of all these techniques.
Return On Investment (ROI)
Cost Benefit Analysis.
Net present value
Internal rate of return (IRR)
This is the most complicated of all the cash flow techniques. It will normally require a financial calculator such as a spreadsheet to determine the best investment. It will not be discussed in detail here, but it is determined by calculating the discount rate when the present value of the cash inflows equals the original investment.
• IRR is the discount rate when NPV equals zero
• IRR assumes that cash inflows are reinvested at the IRR value
• the project with the highest IRR should be chosen
Any project with an NPV greater than zero should be accepted, and any NPV less than zero should be rejected.
When comparing two or more projects, the project with the highest IRR should be chosen. IRR is the discount rate at the point when NPV is equal to zero, and therefore assumes reinvestment at the IRR rate.
The inputs to the charter are normally documented decisions, and can include the following:
• Contract (where applicable)
• project statement of work
• enterprise environmental factors
• organisational process assets
• The project statement of work (S. O. W.)
This is normally written by the project sponsor or whoever initiated the project. If the project is external then it will be written normally by the buyer’
A scoring system is determined by management based on key business aspects. For example profit margin, profit potential, marketability, ease of creation, competitors, business area dynamics, etc.
Each of these criteria is assigned a weighting depending upon its importance to the organisation. Assuming that there are say, five projects under consideration for funding, then each project would be assigned a number, again, say 1 – 10.
A simple matrix or table is produced with each row showing the different criteria and each column showing the project scoring number. These are multiplied together and shown as a total at the bottom of each column. The highest score shows the best project choice.
The project charter is the official and formal written agreement and recognition that a project exists. The charter is normally created by senior management and given to the project manager along with the authority to assigned resources.
It is worth considering the key stakeholders that are required for any project:
• The project manager
• the project sponsor
• the project champion
• functional managers
The project charter should include the following information:
• Purpose or justification for the project
• business needs of the project
• business justification for the project, including return on investment analysis
• high-level project description product description
• objectives and success criteria that must be completed satisfactorily according to stakeholders, sponsor, and customer expectations
• stakeholder influences
• involvement of other departments
• constraints and assumptions
• initial summary milestone schedule
• the initial budget summary
• name of the project manager and their authority levels
The project charter should be signed off from the project sponsor, senior management, and key stakeholders.
This indicates that they agree and support the project. Remember, like all documents, the project charter may change during the life of the project.
This process defines, coordinates, and integrates all of the subsidiary plans, and specifies the who, what, when, where, and how of the project.
The project management plan is progressively elaborated which means that it is developed in the first place and then refined, revisited, and updated.
Project Management Plan
The project management plan consists of the 15 component plans integrated together, and so will need to be assembled after these component plans have been created.
It describes how the project is to be executed, what is to be monitored and controlled, and how it is to be closed.
It therefore documents the outputs of the planning group processes, and the level of detail contained here will reflect the size and complexity of the project.
This is a very important document that has been created to guide the project execution and control, and is a much more than just a Gantt chart or a project schedule.
Like any undertaking, the project and guidance your work on the project by specifying who will do what, when they will do it, where they will do it and most importantly how all they will do it.
You can see that this is a key document whose content and use must be understood completely.
The project management plan is progressively collaborated, this means that throughout the project is constantly developed, refined, replant and updated.
The project management plan represents the aggregation of all the other planning outputs, and so it cannot be completed in the first place until after all of the component plans that make up its constitution had been created.
This process, and hence the project management plan itself, is first created within the planning process group and its contents baselined after approval. The term ‘progressive elaboration’ means that the approved plan is constantly updated and refined but in a controlled manner.
It is also a mistake to assume that the project plan is developed at one point in time. In truth, although it is an output within the executing process group, and forms part of the integration knowledge area, it relies on outputs from the quality, human resource, communications, risk, and procurement knowledge areas to be fully assembled for the first time.
Since the project management plan consists of many other major planning outputs it can only be assembled after such component plans have been created.
The project management plan represents 15 component plans which are aggregated together to become the project plan itself.
The inputs reference information needed to develop the project management plan are the project charter, the other 15 component plans as mentioned above, the enterprise environmental factors and organisational process assets.
Develop Project Management Plan tools
A realistic and achievable project management plan will need the knowledge skills and experience of those that have developed such a plan before, or have knowledge of what constitutes the creation of an effective plan.
PMBOK describes the project plan as “a formal, approve document that defines how the project is managed, executed, and controlled.”
Project constraints and assumptions
Project constraints often restrict or dictate future actions and they limit the options available to the project team.
Classic constraints that the project must work within are time, cost, and scope, although there may be others for example the amount of risk that is acceptable or maybe quality or benefits constraints.
Assumptions are merely some future condition that at the present are presumed to be real or true. Assumptions may be the underlying cause leading to risks and as such should be continually monitored and checked.
The project management plan is the only outputs of this process, and it may be in summary form or detailed, and may consist of one or more subsidiary management plans and other planning documents.
PMBOK describes the project manager plan as a formal written piece of communication and it is a single document – not 15 separate plans, because once approved, it becomes a single approved document.
Who approves the project management plan will vary based of the organisation and other factors, but would typically be the project sponsor, functional managers who are providing resources for the project, or the project manager.
It is NOT normally the customer or senior management who approves the project plan, as the customer will often sign a contract but leave the planning and delivery of the project to the performing organization.
It is very often the case that senior management should not or cannot review every document within a project and this includes approving the project plan particularly when the organisation has multiple projects.
The project management plan may be in summary form or very detailed and for the exam the latter is to be preferred.
The project management plan describes exactly how the project is to be managed, executed, and control and therefore controls the baseline information of how the project will be executed.
Although the project management plan consists of 15 component plans, the importance, size and complexity of a given project within an organization will depend how formally detailed the project management plan will be.
However the various 15 components are detailed, all of them must be contained or combined in some way within the project management plan.
It is important to note that the only parts of the project management plan that are created within the develop project management plan process are the scope management plan, the schedule management plan and the cost management plan.
Other sections are developed in other knowledge areas even though they are integrated via this process.
Remember that the project management plan is progressively elaborated; this is also true in assembling it for the first time as well as later revisions all baseline versions.
This is where the project work is performed, where the team is executing the work packages, and the project products or deliverables are being created. For this reason, most of the budget is spent during this process.
Note that ALL of the project deliverables are created here and are hence a very important output of this process!
This is the process where approved change requests come in and are implemented, and also, because this is where the work is carried out and the deliverables created, is often where new change requests are made.
As the work is carried out, the various sections of the project management plan are updated.
The work performance data details how the deliverables are being produced, and these details will be analyzed/processed, and then converted into work performance information.
Direct and Manage Project Work inputs
Project Management Plan
The project management plan is the main input because of course; it is used to guide the management, execution and control of the project.
Approved Change Requests
Because this process is where all the work gets done, then approved change request are used as an input here to implement these changes.
Enterprise environmental Factors
The environment of the project will have a large influence on how the work is carried out.
Organizational Process Assets
These will be a rich supply of techniques, procedures logs and registers to assist in carrying out the work.
Direct and Manage Project Work tools
This will come from both management and specialists to help manage the project work.
Project Management Information System
These are often an effective technique to gather data and opinions and determine actions.
This compares actual work results to the plan and then makes appropriate adjustments to ensure that the two match.
It make sure that both the products, and the way in which they are being produced, fall in line with the plan, it also looks at how the overall project is progressing and takes any corrective action if needed via change requests.
This takes place as part of the executing process group.
This is the process of tracking, reviewing, and regulating the progressed in order to meet the performance objectives defined in the project management plan.
In addition to reviewing the work that is being performed, this process also makes sure that the deliverables themselves, plus the way in which they are being delivered according to the project management plan.
This is a macro integration process and looks at the progress of the overall project taking corrective action as and when needed via change requests.
The focus here is on identifying any variances from the project management plan, to carry out problem-solving in order to determine appropriate corrective and preventative action, perform root cause analysis of such variances, and to manage the time and cost reserve allocations.
For this reason the schedule and cost forecasts are an input so that any variance from the plan is noted and suitable corrective actions can be taken.
The corrective action that the project manager should be making here is based on how the project has been progressing and from this how things are forecast to continue.
The results of the work being undertaken are compared to the baseline is within the plan and appropriate adjustments made to ensure that the two are harmonized. Such adjustments and changes to the work are both identified and implemented within this process.
Another key aspect here is to ensure that risks are being managed properly, new risks identified, and that the overall project performance remains on track.
This particular process is aligned closely with the Direct and Manage Project Work process and they are used together throughout the project as long as there is remaining work to be carried out.
Monitor and Control Project Work inputs
Project management plan
This is one of the many common inputs and is an obvious choice as it summarizes all of the planning processes, the various plans, strategies and baselines. Since monitoring and controlling project work is ensuring that the results are in line with the plan, this is a key input.
These provide information on the status of the progress of the project work and represent actual performance so that it can be compared to the plan. Such evaluation can then be used to take any need necessary corrective action.
These reports give valuable information of progress against the scope, time, cost, and quality baselines.
An important part of the project manager’s job is not just to capture actual information but also to look ahead based on current performance.
This information will allow the project manager to make informed choices about implementing preventative actions and therefore resolve problems before they arise in the first place.
Enterprise environmental factors
The manner in which monitoring and controlling of the project work takes place will depend upon factors such as laws and regulations, your organisation infrastructure, and elements such as the organizations appetite for risk.
Organisational process assets
In a similar way to the above, an organization may have monitoring and reporting documentation templates, or policies procedures or guidelines for reporting, in addition there may be lessons learned from previous similar projects recommending the type and frequency of such monitoring and controlling.
As work is performed, it is quite natural for changes to be requested. Such changes may for example request the scope of the project to change, timescales to change, budgets to change, or functionality to change.
All such change requests need to be brought into the process for impact evaluation on the project, where they will either be approved or rejected.
Such change requests normally emanate from the need for corrective action which is to bring future results in line with the plan or from preventative actions which were raised to avoid the occurrence of a future problem, or possibly changes may be because of the need for defect repair.
Project management plan updates
As a result of taking corrective action as well as capturing work progress, then changes to the various documents within the project management plan need to be updated to reflect current progress and future forecast.
Project document updates.
Other documents that may need to be changed should also be updated. Examples here could be logs or registers.
Since of is the project manager that is responsible for monitoring and controlling the project work, then it is their judgment than is needed to weigh the evidence of project performance so that this can be evaluated and if necessary take appropriate corrective action.
In making these decisions, the project manager may also need to consult with other knowledge or experience specialists such as the project team or consultants.
One topic which causes the most confusion, particularly in PMP exam questions, is that of the Integration Knowledge area.
So first, let’s compare and contrast the two processes, Monitor and Control Project Work, and Perform Integrated Change Control.
This process is where you assess the change’s impact on the project, because whenever a change occurs in one area, it must be evaluated for its impact across the entire project. This process is focused on managing change to the project’s scope.
Every single change that is requested will be processed through the Perform Integrated Change Control process.
Integrated change control is where the impact of any change is assessed against the project, and this is the reason why this is called ‘integrated’. It is because if a change were to occur in one part of a project, it needs to be assessed across the whole of the project.
The main difference between integrated change control and Monitor and Control Project Work, is that whereas Perform Integrated Change Control focuses on managing any change to project scope – Monitor and Control Project Work focuses on managing the way that such scope is executed.
For example, if a new application is requested to be added to an IT solution project, then such a change request would need to be re-evaluated via the Perform Integrated Change Control process to ensure that the impact to the rest of the system is known and understood before or such a change is approved or otherwise.
Perform Integrated Change Control inputs
The main inputs here in the above situation would be the change request itself, and the main tool/technique used where the change control board used to make a decision.
Project Management Plan
When considering any change requests, the Project Management Plan should be used as an input as it contains the baselines against which any change should be considered.
Work Performance Reports
These document how the work is being conducted and as such help in making proposed change request decisions.
All change requests must come through this process as an input.
Enterprise Environmental Factors
The project environment must always be considered when making decisions about potential changes.
Organizational Process Assets
These may be guidelines or procedures when carrying out change requests.
Perform Integrated Change Control outputs
The main outputs will be the change requests status update, which is a decision on what to do next. Changes can either be approved or rejected.
In the case of the former, they will be fed back into the Direct and Manage Project Work process within the Executing process group.
Approved Change Requests
All change requests must be either approved or rejected, and if they are approved then these become an input into the Direct and Manage Project Work process.
This is the central control reference for all changes and is used to keep track of all changes.
Project Management Plan Updates
As changes are agreed then plans must be updated to reflect approved changes.
Project Document Updates
Similar to above, such approved changes must be reflected in other documentation.
Change Control Tools
This is normally a system that is in place to track the information flow to and from those responsible for approving changes.
These are formal meetings used to evaluate changes and is normally carried out by the change control board.
This would normally be provided by specialist knowledge and those who sit on the change control board.
Integration Management and Change Control
The following diagram summarizes how the Direct and Manage Project Work, Monitor and Control Project Work, and Perform Integrated Change Control processes work with other processes (to be covered later) to control quality, scope, costs and schedule:
The focus here is to ensure that the project or phase comes to a controlled shut down. This will typically create any appropriate documentation and archive it, capture the lessons learned, and ensure the contract (if any), is closed properly.
The purpose of lessons learned is to document the project successes and failures, make recommendations, and these are used as lessons learned for future pr
Every project is a temporary undertaking and therefore has a start date and a finish date, meaning that every project will eventually come to an end and that is where the close project or phase process is used.
The Close project or phase process can be thought of as the process that performs a controlled shut down at the end of the project.
As is normal within a project, there is documentation to be archived, capturing any lessons learned to be passed on for future projects, ensuring that any contracts are properly shut down, and updating any organizational process assets.
Most projects are also split into a series of phases or stages, and therefore the close project or phase process may be used at the end of each phase or stage as well as at the end of the project.
The purpose here is to gather project records and disseminate information in order to gain project product acceptance, and to perform project closure
Many projects fail because they are allowed to drift on, often for several weeks or months because they have not been officially closed.
Not only will such a situation cause delays in handing over the end-product into the life business area, but also will incur additional labor costs because the project team will continue to book their time against the project.
The aim therefore, is to use this process to execute a timely and controlled project shutdown.
If this process is also being used to close a particular phase of stage within the project, then again, it will assist in providing the latest information so that the project board or sponsor can make an informed choice as to whether or not to proceed to the next phase or stage.
Clearly some of the activities may not be needed when this process is used to close a phase of stage, so a degree of common sense is needed here.
As mentioned above, part of this process ensures that adequate documentation and records are updated to support the decisions made, and also to provide a valuable source of lessons for future projects as well as a concise audit trail should it be necessary.
Such records and documentation will become new or modified organizational process assets for use on future projects.
Key activities typically include:
• Review project documents, and update if required
• Update your resource assignments (advising/letting go)
• Document the project outcomes
• Request formal acceptance from stakeholders/customer
• Analyze the project management processes to determine their effectiveness
• Document the Lessons Learned
• Archive all project documentation for future historical reference/audits
Project management plan
This single document guides the executing, monitoring and control, and closure of the project, even though this document is actually made up of several documents.
The project management plan therefore is a major and important input as a source of reference to make decisions about whether the project or phase is indeed complete.
The project management plan contains many plans within it, and these include scope, requirements, cost and schedule, quality, communications, risk management, procurement and stakeholder information.
You can see therefore that this document is used as a major source of reference as part of closing a project or phase.
As the name suggests, the deliverables are the whole purpose that the project was undertaken in the first place. These deliverables must be acceptable to the appropriate stakeholders before they can be deployed into the live business area.
Such deliverables will have already passed through the control quality and validate scope process is to ensure that they meet specifications for completeness and correctness.
Organizational Process Assets
Notice that this is both an input and an output. The reason is fairly obvious in that such original process assets will need to be updated as a result of the knowledge and any changes made during the project.
The formal sign-off of the acceptance of the product is documented and archives for future reference. The Warranty period may start from this point in time. In this way, value is added to the organization in the light of experience as such assets are refined and updated.
Organizational process assets may take the form of information, tools, documentation or organizational knowledge. It is part of your job as a member of the project to contribute to these assets wherever and whenever possible.
Some examples of organizational process assets may include:
• Templates such as plans or strategies
• Policies procedures and guidelines
• Tools used in the creation of the specialist products
• Knowledge bases
• Competences and skill sets
• Lessons learned
Final product, service, or result transition
This refers to the accepted deliverable’s acceptance and hand over of responsibility to the appropriate users and owners of the end-product.
Such users and owners may include the customer, the end users, operational management, a support or sustaining group, in fact any individual or group who is responsible for life business use of the end-product.
For this transition to be successful, it implies that the product has already been accepted and is ready for deployment within the life business area.
Organizational process assets updates
Here at the end of the project or one of its phases, information will have been obtained, tools will have been provided, purchased or bout, and additional knowledge and experience will have been gained.
Project records and files are archived such as:
• project planning documents
• project scope statement
• budget information
• schedule information
• risk responses
• quality plan
• baseline information
• change records and other logs
• project closure documentation
• product transfer information
• handover to operations and support organizations
• details of optional post-implementation audits
In addition, new documentation may also have been created.
All of the above should be updated as an organizational process asset and passed on to the appropriate group or individuals who will be responsible for maintaining them. Such a group may often be a project office or a central project support group.
This can be used whenever the project team and the project manager do not have sufficient knowledge or expertise. Therefore such experts may come from within the organization or external to it, they may be paid consultants or simply individuals offering free advice and guidance.
Such techniques are used to understand root causes or to generate potential forecast options. Such analysis can be done in either a structured or unstructured manner.
Using the fishbone or Ishikawa diagram is one type of analytical tool that may be used here.
Such a tool may be used to generate recommendations for lessons learned.
These may be used by inviting appropriate stakeholders or experts to work on one or more of the inputs and outputs of the close project or phase process.