Lesson 1: Introduction to Project Management: LINK

Project Integration Management (PIM)

2.1 Intro to PIM

2.2. Org culture and PM

2.3 Characteristics of project charter

2.4 Project charter development

2.5 Preliminary project scope statement

2.6 Development of PM plan

2.7 Integrated change control

2.8 Monitor and control project work

2.9 Close project

2.1 Introduction to PIM

The processes & activities needed to integrate various elements of PM, which are identified, defined, combined, unified and coordinated within the PM process groups is called PIM.

  • There is no single way to manage a project
  • PM is an iterative process
  • The most imp thing in any project is to satisfy the stakeholder’s needs and expectations
  • PIM should help identify and define the project expectations set by SHs.

6 STEPS OF SUCCESSFUL PIM:

1. Develop a project charter

2. Develop a PM plan

3. Direct and manage execution

4. Monitor + control project work

5. Perform integrated change control

6. Close project (or phase)

The purpose of developing a project charter in PIM, is to develop a doc which authorises a project or phase documenting the initial requirements meeting the SHs needs and expectations.

2.2 Org culture and PIM

  • Culture = ‘how we do things around in a given set up’
  • Org culture influences the PM directly – as it affects how projects are executed
  • Until the culture fosters successful projects, PMs will struggle to deliver.

Role of culture:

1. Process Orientation:

  • The single biggest factor in overall project success / good PM process = successful projects.
  • Set standards, make sure the team knows how to create + follow project plans

2. Governance:

  • To make sure processes are being followed.
  • It is the management function to make sure people are doing what they’re supposed to do.

3. Training:

  • If PMs are trained poorly, they will manage poorly.
  • PMs need to have the right skills and training

4. Org structure:

  • Structure might get into the way of projects
  • Structure can be easily changed compared to changing the entire culture
  • Example: If the project delivery team is also doing support work, the support issues will pop-up and take the focus away from the project.
  • In this case, it will be difficult to prepare good estimates and meet scheduling commitments.
  • An org may be forced into this structure if the staff is small.
  • Organisational structure may prevent the ability to share resources, and some projects might need resources from a different functional area.

Overall, attacking broader cultural problems will have a positive impact on removing organisational level barriers to overall project success.

2.3 The characteristics of project charter

  • Deals with the regulatory and admin aspects of PM
  • Authorising the project and tracking the info required by decision makers to approve the project for funding
  • Size+time spent into project charter should be proportional to size and complexity of the project

2.4 Project Charter Development

The project charter (directly or with ref to other docs) needs the address:

PROJECT / PRODUCT OVERVIEW:

  • Self-sufficient section to explain the project in a nutshell.
  • It should answer who, what, when and where questions in a concise manner.
  • It should also mention estimated cost and time.
  • Business need, business impact, and strategic alignment should also be included

SCOPE:

  • Objectives – what it intends to achieve
  • High-level requirements
  • Major Deliverables
  • Boundaries

PROJECT ORGANISATION:

  • Summarise roles and responsibilities of the business sponsor, technical and SMEs, other roles.
  • Identify internal and external stakeholders of the project

DURATION:

  • High level timeline and executive milestones because they act as performance indicators
  • Also helps the project sponsor track the progress

BUDGET ESTIMATE:

  • Summarises the various sources of funding and also the estimated budget at the beginning of the project

HIGH LEVEL ALTERNATIVE ANALYSIS:

  • To assure the authorities that appropriate risk identification is done before the project starts and the best alternative is chosen in case the original project fails

ASSUMPTIONS, CONSTRAINTS, AND RISKS:

  • Any kind of visible limitation that may affect the project
  • Identified risks to build readiness among the stakeholders

APPROVAL:

  • Should be approved by all imp stakeholders who are directly involved in kick-off, execution and closure.

2.5 Preliminary Project Scope Statement

  • States what the project will & will not accomplish
  • Any reader of the scope statement should understand what the project is expected to deliver and when (without having any previous knowledge)
  • The scope statement also defines the actual boundaries of the project

THE PROJECT SCOPE STATEMENT should contain (MUST HAVES):

  • Project name
  • Project charter
  • Project owner, sponsors, and stakeholders
  • Project statement
  • Project goals and objectives
  • Project requirements
  • Project deliverables
  • Project non-goals (Out of the scope)
  • Milestones
  • Cost estimates

Can also include (GOOD TO HAVES):

  • Project scope management plan
  • Approved change requests
  • Project assumptions and risks
  • Project acceptance criteria

PRELIMINARY SCOPE STATEMENT should contain:

  • Approval and acceptance requirements
  • Assumptions
  • Constraints
  • Deliverables
  • Estimated Budget
  • Milestones
  • Objectives
  • Preliminary WBS (work breakdown structure)
  • Project boundaries
  • Project risks
  • Quality requirements

Difference between preliminary scope statement and project charter:

The charter’s purpose is to formally authorise the project, the preliminary scope statement’s purpose is to provide the overall project intent. Audience of scope statement = anyone who wants to know about the project, internal or external.

Project Management Plan Process:

  • The project plan is a formal, approved doc used to guide both project execution + control.
  • Primary use: document planning assumptions & decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines
  • It’s a statement of how and when a project’s objectives are to be achieved, by showing major deliverables, milestones, activities, and resources required on the project.
  • Created by PM with inputs from project team and key SHs.
  • Project plan process: DEFINE > PREPARE > INTEGRATE > COORDINATE
  • Project execution is to lead the team to perform the work mentioned in the project plan.
  • The work done should be tracked, reviewed, and progress regulated so the deadlines are met along with the performance standard and quality.
  • Changes might occur in any project, and the process of revisiting all change request, approving and managing changes to deliverables, project docs, and the PM plan are done under the Planned Integrated Change Control.

2.6 Development of Project Management Plan

Should cover:

  • Scope management
  • Requirement management
  • Schedule management
  • Financial management
  • Quality management
  • Resource management
  • Communications management
  • Project change management
  • Risk management
  • Procurement management

Basic questions which should be answered:

  • Why is the project undertaken? (why is it being sponsored?)
  • What are the major deliverables? (what work will be done?)
  • When will the various milestones be achieved? (timelines)
  • Who will be given what responsibilities? (team and team organisation)

The initial effort of the project goes into project planning, which is the responsibility of a PM. To plan a project, a PM must visualise it in motion – like a movie director envisioning the movie in his head before he plans out the theatre screen.

Contents of a PM plan:

  • Project schedule: key milestones
  • Cost plan: estimates along with degree of variation from plan to reality
  • Resources: People + material needed. For people, list roles and responsibilities.
  • Risks: Assessing risk before the kick off is an art of experience
  • Quality: Output should be in compliance with quality requirements of stakeholders. The quality required is agreed in initial stages and put in writing in the plan
  • Communications: Consists of 70% of the project and a specific plan is needed to address communications – the regular communications + the medium of these communications is planned too.
  • Example: Weekly email on FRIDAY / Monthly video con call / etc
  • Changes: A plan to address change and how it will alter other aspects. If a project manager can control changes effectively, a project will succeed more often than not.

2.7 Integrated Change Control

  • It is one of the 6 integration knowledge areas and one of the 10 monitor+control processes.
  • Purpose is to review change requests > determine whether to approve them > manage the effects of the changes on deliverables + project docs + project plan.
  • There are 15 processes which have change request as an output. These change requests then become inputs to perform INTEGRATED CHANGE CONTROL process.
  • HOW TO determine which changes to approve:
  • Basis of the PM plan + Work Performance info
  • The CCB is the change control board, which has change control meetings to approve / reject change requests.

OUTPUT of the Integrated Change Control process:

  • Change request status updates
  • Approve / reject changes
  • If approved, the change request may be an input on 3 processes: Direct + manage project execution, perform Quality Control and Administer Procurements.

How a PM deals with changes throughout a project determines whether a project succeeds or fails.

  • The integrated change control is the “process of reviewing all change requests, approving changes, managing changes to the deliverables, organisational process assets, project documents, and the project management plan.
  • Process changes = owned by team & Product changes = owned by customer
  • These changes are documented in the ordered product catalog. During release and iteration planning, these higher ordered items move from backlog to actually being coded, tested, and accepted by the customer at the end of each iteration.
  • The customer feedback at the end of this iteration becomes the integrated change process that enable the team to make the necessary adjustments.

WHY INTEGRATE change management and project management:

  • Enables a shared objective: efforts of both focused toward a single objective that is delivering the intended results.
  • Enables proactive steps: Efforts to manage the people side of change can proactively identify and mitigate risks, address anticipated obstacles and resistance, and build commitment and buy-in for the change.
  • Enables sequencing and alignment: Right steps can be taken at the right time in the project lifecycle to help employees embrace the change and produce the right outcomes for the project.
  • Enables exchange of info: improves the flow of info – to ensure project team is receiving effective feedback on the change

DIMENSIONS OF INTEGRATION:

  • People dimension (who is doing the work) level integration
  • Process dimension (what work is being done) level
  • Tool dimension (what tools are being used) level
  • Methodology dimension (moves beyond “in project” integration to creation of common set of steps applied to any project to make a common methodology though a one-size-fits-all approach has it’s own potential risks

CONFIGURATION MANAGEMENT:

To identify, track, and protect the project deliverables from UNAUTHORISED CHANGE.

It gives control over the project’s assets allowing managers to:

  • Specify the versions of products in use and hold info on their status, who owns them and relationships between them
  • Maintain up-to-date records of the above info
  • Control changes ensuring changes are made only with the agreement of appropriate named authorities.
  • Audit the records to ensure they contain only authorised products

Within the project, the job of config management is to provide:

  • Mechanisms of tracking and keeping control – keep files and libraries once they have been quality controlled
  • Safe and secure storage of each product
  • Ability to select and package the various components that comprise the final working product
  • A system for logging, tracking and filing all project issues

CONFIGURATION MANAGEMENT PLAN

Outlines the details of the roles and responsibilities of config management.

2.8 Monitor and control project work

Monitoring and controlling take place as part of the executing process group

Tracking, reviewing and regulating to meet performance objectives defined in 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.

  • Identifying variances from the project plan is key
  • Carry out problem-solving to determine corrective and preventive action
  • Perform root cause analysis of such variances
  • To manage time and cost reserve allocations
  • The corrective action the PM should be making is based on how the project has been progressing and from this how things are forecast to continue
  • The results of the work being done are to be compared with baseline as per the Project plan and appropriate adjustments to be made to make sure the two are harmonised.
  • Risks to be managed properly, new risks to be identifies, to make sure overall project performance is on track.

Inputs to the monitor and control project work process:

  • Project management plan: Ensuring work is in line with the project plan.
  • Performance reports: Reports give valuable info of progress against the scope, time, cost and quality baselines. PM should not just capture info but also have the ability to LOOK AHEAD based on current performance. This info will allow the PM to make informed choices about preventable actions and resolve problems before they arise in the first place.
  • Enterprise environmental factors: Laws, regulations, infrastructure, also elements such as the organisation’s appetite for risk will also affect the monitor+control.
  • Organisation’s process assets: Like reporting templates, policies, guidelines, lessons learned from previous projects, guidelines on type and frequency of monitoring and controlling*

Outputs from the monitor+control project work process:

  • Change requests: Request for scope, time, budget, functionality change. All such change requests need to brought into the process for impact evaluation on the project, where they will be EITHER APPROVED OR REJECTED.
  • Project management plan updates: As a result of taking corrective action and capturing work progress, changes to various documents within the PM plan need to be updated
  • Project document updates: other docs like logs or registers will also need to be updated

There is ONLY ONE tool within the monitor and control project work process, which is EXPERT JUDGEMENT. Expert judgement is needed to weigh the evidence of project performance so that it can be evaluated and, if necessary, take the appropriate corrective action.

2.9 Close Project

  • The purpose of this process is to execute a controlled close to the project.
  • It is one of the 42 PM processes as per PMBOK and one of the 6 integration knowledge areas, and one of the two closing processes.
  • The primary purpose of this process is to finalise activities in order to complete the project or phase of the project.
  • The process covers the PMs wrapping up of the project either at the end or in case of a premature close.

OBJECTIVES:

  • Check the extent to which the objectives set out in the project initiation document (PID) have been met
  • Confirm the extent of fulfilment of the PID and customer’s satisfaction with the deliverables
  • Obtain formal acceptance of the deliverables
  • Ensure to what extent all expected products have been handed over and accepted by the customer
  • Confirm the maintenance and operation arrangements are in place
  • Make recommendations for follow-up actions
  • Capture lessons resulting from the project and complete the LESSONS LEARNED REPORT
  • Prepare an end project report
  • Notify the host organisation to the intention to disband project resources

The ACCEPTED deliverables are an input to this process and the outputs are final product/service or result transition and KT.