Project Management (MBA module 6 of 8)

Introduction

Project

Projects are complex, one-time processes
Projects are limited by budget, schedule, and resources
Projects are developed to resolve a clear goal or set of goals
Projects are customer-focused
A project is a temporary endeavour undertaken to create a unique product, service, or result (PMBoK 5th edition)
Projects are ad hoc endeavours with a clear life cycle
Projects are building blocks in the design and execution of organisational strategies
Projects are responsible for the newest and most improved products, services, and organisational processes
Projects provide a philosophy and strategy for the management of change
Project management entails crossing functional and organisational boundaries
Traditional management functions of planning, organizing, motivation, directing, and control apply to project management
Principal outcomes of a project are the satisfaction of customer requirements within the constraints of technical, cost, and schedule objectives
Projects are terminated upon successful completion of performance objectives
New process or product
One objective
One-shot-limited life
More heterogeneous
Integrated system efforts
Greater uncertainty
Outside of line organization
Violates established practice
Upsets status quo

Process

Repeat process or product
Several objectives
Ongoing
People are homogenous
Well-established systems
Greater certainty
Part line organization
Established practices
Supports status quo

Success rate

Software & hardware projects fail at a 65% rate
Over half of all IT projects become runaways
Only 30% of technology-based projects and programs are a success
Ten major government contracts have over $16 billion in cost overruns and are a combined 38 years behind schedule
Only 2.5% of global businesses achieve 100% project success and over 50% of global business projects fail
More than $8 billion of $53 billion the Pentagon spent on Iraqi reconstruction projects was lost due to fraud, waste, and abuse

Importance of project

Shortened product life cycles
Narrow product launch windows
Increasingly complex and technical products
Emergence of global markets
An economic period marked by low inflation

Project life cycle: the stages in a project’s development and are divided into four distinct phases:

Conceptualisation: development of the initial goal and technical specifications of the project
Key stakeholders are identified and signed on at this phase
Planning: all detailed specifications, schedules, schematics, and plans are developed
Execution: the actual “work” of the project is performed
Termination: project is transferred to the customer, resources reassigned, project is closed out

Change during project lifecycle

Client interest
Project stake
Resources
Creativity
Uncertainty

Success criteria

Iron triangle

Cost
Quality
Time

Information system

Maintainability
Reliability
Validity
Information quality
Use

Benefits (organisation)

Improved efficiency
Improved effectiveness
Increased profits
Strategic goals
Organisation learning
Reduced wastes

Benefits (stakeholders)

Satisfied users
Social and environmental impact
Personal development
Professional learning, contractors' profits
Capital supplier, content
Project team, economic impact to surrounding community

Information technology

System quality
Information quality
Use
User satisfaction
Individual impact
Organisational impact

PM maturity

Project management maturity (PMM) models are used to allow organizations to benchmark the best practices of successful project management firms

Benchmarking is the practice of systematically managing the process improvements of project delivery by a single organization of a period of time

PM maturity generic model

High maturity: institutionalised, seeks continuous improvement
Moderate maturity: define practices, training programs, organisational support
Low maturity: Ad hoc process, no common language, little support

Project Management Maturity (PMM) Models

Center for Business Practice

Level 1: Initial Phase

Level 2: Structure, Process, and Standards

Level 3: Institutionalized Project Management

Level 4: Managed

Level 5: Optimising

Kerzner’s Project Management Maturity Model

Level 1: Common Language

Level 2: Common Processes

Level 3: Singular Methodology

Level 4: Benchmarking

Level 5: Continuous Improvement

ESI International’s Project Framework

Level 1: Ad Hoc

Level 2: Consistent

Level 3: Integrated

Level 4: Comprehensive

Level 5: Optimising

SEI’s Capability Maturity Model Integration (CMMI)

Level 1: Initial

Level 2: Managed

Level 3: Defined

Level 4: Quantitative Management

Level 5: Optimising

PM responsibilities

Selecting a team
Developing project objectives and a plan for execution
Performing risk management activities
Cost estimating and budgeting
Scheduling
Managing resources

Organisational

Project strategy

Technical or operating initiatives (such as new distribution strategies or decentralised plant operations): construction of new plants or modernisation of facilities
Development of products for greater market penetration and acceptance: new product development projects
New business processes for greater streamlining and efficiency: reengineering projects
Changes in strategic direction or product portfolio reconfiguration: new product lines
Creation of new strategic alliances: negotiation with supply chain members (including suppliers and distributors)
Matching or improving on competitors’ products and services: reverse engineering projects
Improvement of cross-organisational communication and efficiency in supply chain relationships: enterprise IT efforts
Promotion of cross-functional interaction, streamlining of new product or service introduction, and improvement of departmental coordination: concurrent engineering projects

Stakeholder management

Stakeholder analysis is a useful tool for demonstrating some of the seemingly irresolvable conflicts that occur through the planned creation and introduction of new projects
Project Stakeholders are defined as all individuals or groups who have an active stake in the project and can potentially impact, either positively or negatively, its development
Internal stakeholders

Top management
Accountant
Other functional managers
Project team members

External stakeholders

Clients
Competitors
Suppliers
Environmental, political, consumer, and other intervener groups

Managing stakeholders

Assess the environment
Identify the goals of the principal actors
Assess your own capabilities
Define the problem
Develop solutions
Test and refine the solutions

Organisational structure

Designates formal reporting relationships

Number of levels in the hierarchy
Span of control

Identifies groupings of

Individuals into departments
Departments into the total organization

Design of systems to ensure

Effective communication
Coordination
Integration across departments

Organisational culture

Unwritten
Rules of behavior
Held by some subset of the organization
Taught to all new members
Departmental interaction
Employee commitment to goals
Project planning
Performance evaluation
Key factors

Technology
Environment
Geographical location
Reward systems
Rules and procedures
Key organizational members
Critical incidents

Forms of organisational structure

Functional organisations: group people performing similar activities into departments
Project organisations: group people into project teams on temporary assignments
Matrix organisations: create a dual hierarchy in which functions and projects have equal prominence
Functional structure

Projects developed within basic functional structure require no disruption or change to firm’s design
Enables development of in-depth knowledge and intellectual capital
Allows for standard career paths
Functional siloing makes it difficult to achieve cross-functional cooperation
Lack of customer focus
Longer time to complete projects
Varying interest or commitment

Project structure

Project manager sole authority
Improved communication
Effective decision-making
Creation of project management experts
Rapid response to market opportunities
Expensive to set up and maintain teams
Chance of loyalty to the project rather than the firm
Difficult to maintain a pooled supply of intellectual capital
Team member concern about future once project ends

Matrix structure

Suited to dynamic environments
Equal emphasis on project management and functional efficiency
Promotes coordination across functional units
Maximises scarce resources
Dual hierarchies mean two bosses
Negotiation required in order to share resources
Workers caught between competing project & functional demands

Heavyweight project organisation

Organisations can sometimes gain tremendous benefit from creating a fully-dedicated project organisation.
Lockheed Corporation’s “Skunkworks”
Project manager authority expanded
Functional alignment abandoned in favor of market opportunism
Focus on external customer

PM offices

Centralized units that oversee or improve the management of projects
Resource centers for

Technical details
Expertise
Repository
Center for excellence

Weather station: monitoring and tracking
Control tower: project management is a skill to be protected and supported
Resource pool: maintain and provide a cadre of skilled project professionals
Control tower

Establishes standards for managing projects
Consults on how to follow these standards
Enforces the standards
Improves the standards

Project manager's leadership

The ability to inspire confidence and support among the people who are needed to achieve organisational goals
Project management is leader intensive
Leader versus manager

Exchange of purpose
A right to say no
Joint accountability
Absolute honesty
Leaders

Do the right thing
Develop new process
Innovate
Originate
Earn their position
Command respect
Focus on people
Inspire trust
Focused on potential
Have long-term goal

Managers

Do things right
Maintain the status quo
Administer
Imitate
State their position
Demand respect
Focus on systems
Strive on control
Focused on the bottom line
Short-term view

Project manager

Project managers function as mini-CEOs and manage both “hard” technical details and “soft” people issues
Acquire project resources

Vague goals
Lack of top management support
Requirements understated
Insufficient funds
Distrust between managers

Motivate and build teams
Have a vision and fight fires
Communicate

It is critical for a project manager to maintain strong contact with all stakeholders
Project meetings feature task-oriented and group maintenance behaviours
Structuring process: guide and sequence discussion
Stimulating communicationIncrease information exchange
Clarifying communication: increase comprehension
Summarising: check on understanding and assess progress
Testing consensus: check on agreement
Gatekeeping: increase and equalise participation
Harmonising: reduce tension and hostility
Supporting: prevent withdrawal, encourage exchange
Settings standards: regulate behaviour
Analysing process: discover and resolve process problems

Effective project manager

Leads by example
Visionary
Technically competent
Decisive
A good communicator
A good motivator
Stands up to top management when necessary
Supports team members
Encourages new ideas

Ineffective project manager

Sets bad example
Not self-assured
Lacks technical expertise
Poor communicator
Poor motivator
Lack of top management support
Resistance to change
Inconsistent reward system
A reactive organisation rather than a proactive, planning one
Lack of resources

Professionalism

Project work is becoming the standard for many organisations
There is a critical need to upgrade the skills of current project workers
Project managers and support personnel need dedicated career paths

Creation of PM

Match personalities with project work
Formalize commitment to project work with training programs
Develop a unique reward system
Identify a distinct career path

Meetings

Define project and team players
Provide an opportunity to revise, update, and add to knowledge base
Assist team members in understanding role in project as part of whole and how to contribute to project success
Help stakeholders increase commitment to project
Provide a collective opportunity to discuss project
Provide visibility for project manager’s role

Emotional intelligence refers to leaders’ ability to understand that effective leadership is part of the emotional and relational transaction between subordinates and themselves

Self-awareness
Self-regulation
Motivation
Empathy
Social skills

Effective project leader

Credibility
Creative problem-solver
Tolerance for ambiguity
Flexible management style
Effective communication skills

Essential management abilities

Organizing under conflict
Experience
Decision making
Productive creativity
Organizing with cooperation
Cooperative leadership
Integrative thinking

Project champions

Champions are “fanatics” in the single-minded pursuit of their pet ideas
Creative originator
Entrepreneur
“Godfather” or sponsor
Project manager
Traditional duties

Technical understanding
Leadership
Coordination & control
Obtaining resources
Administrative

Nontraditional duties

Cheerleader
Visionary
Politician
Risk taker
Ambassador

Identify and encourage their emergence
Encourage and reward risk takers
Remember the emotional connection
Free champions from traditional project management duties

New project leadership

Understand and practice the power of appreciation
Remind people what’s important
Generate and sustain trust
Align with the leader

International settings

Develop a detailed understanding of the environment
Do not stereotype
Be genuinely interested in cultural differences
Do not assume there is one way (yours) to communicate
Listen actively and empathetically

Project team

Assembling a team

Identify skills require from WBS
Identify personnel to match the skills
Talk to potential team members
Negotiate with the functional supervisor
Try to get partial assistance
Adjust project schedule, budget, and/or priorities
Notify top management of consequences
Assemble the team
Develop skills inventory matrix
Develop responsibility matrix
Clarify roles
Clarify methods and procedures

Effective team

Clear Sense of mission
Productive interdependency
Cohesiveness
Trust
Enthusiasm
Results orientation

Why team fail

Poorly developed or unclear goals
Poorly defined project team roles & interdependencies
Lack of project team motivation
Poor communication
Poor leadership
Turnover among project team members
Dysfunctional behaviour

Group development stages

Forming: members become acquainted
Storming: conflict begins
Norming: members reach agreement
Performing: members work together
Adjourning: group disbands

Punctuated Equilibrium is a different model

High performing team

Make the project team tangible

Publicity
Terminology & language

Reward good behaviour

Flexibility
Creativity
Pragmatism

Develop a personal touch

Lead by example
Positive feedback for good performance
Accessibility & consistency

Virtual project team

Use electronic media to link members of a geographically dispersed project team
Use face-to-face communication when possible
Don’t let team members disappear
Establish a code of conduct
Keep everyone in the communication loop
Create a process for addressing conflict

Conflict

Conflict is a process that begins when you perceive that someone has frustrated or is about to frustrate a major concern of yours
Conflict is often evidence of progress
Categories

Goal-oriented
Administrative
Interpersonal

Views

Traditional
Behavioural
Interactionist

Organisational

Reward systems
Scarce resources
Uncertainty
Differentiation

Interpersonal

Faulty attributions
Faulty communication
Personal grudges & prejudices

Conflict resolution

Mediate: diffusion/confrontation
Arbitrate: judgment
Control: cool down period
Accept: unmanageable
Eliminate: transfer

Negotiation

Negotiation is a process that is predicated on a manager’s ability to use influence productively
Negotiation questions

How much power do I have?
What sort of time pressures are there?
Do I trust my opponent?

Principled negotiation

Separate the people from the problem
Focus on interests, not positions
Invent options for mutual gain
Insist on using objective criteria

Planning and scheduling

Common delay reasons

Manufacturing obstacles
Shipping
Volume
Apple’s “curve ball”
Changing scope
Certifications
Kickstarter’s infrastructure
Overseas logistics

Critical chain project management (CCPM)

Developed by Dr. Eli Goldratt in mid-1990s
Alternative scheduling mechanism to speed up project delivery
Make better use of project resources
More efficiently allocate and discipline the process of implementing projects
Based on theory of constraints (TOC)
Represents both cultural shift and change in scheduling processes
Applies technical and behavioral elements of project management

Agile Project Management (Agile PM) reflects a new era in project planning that places a premium on flexibility and evolving customer requirements throughout the development process

Planning the work and then working the plan
Customer needs may evolve and change over course of project
Importance of evolving customer needs leads to incremental, iterative planning process
Agile PM, referred to as Scrum, recognizes mistakes of assuming once initial project conceptualization and planning are completed, project will be executed to original specifications.
Example, software projects are prone to constant changes.
Flexible, iterative system designed for the challenge of managing projects in midst of change and uncertainty
“Rolling wave” process of continuous plan-execute-evaluate cycle
Emphasis on adaptation, flexibility, and coordinated efforts of multiple disciplines
Agile key terms

Sprint: one iteration of the Agile planning and executing cycle
Scrum: the development strategy agreed to by all key members of the project
Time-box: the length of any particular sprint, fixed in advance, during the Scrum meeting
User stories: short explanation of the end user that captures what they do or what they need from the project under development
Scrum Master: person on the project team responsible for moving the project forward between iterations, removing impediments, or resolving differences of opinions between major stakeholders
Sprint backlog: the set of product backlog items selected for the Sprint, plus a plan for delivering the Sprint Goal
Burndown chart: remaining work in the Sprint backlog
Product owner: person representing the stakeholders and serving as the “voice of the customer.”
Development team: organisational unit responsible for delivering the product at the end of the iteration (Sprint)
Product backlog: a prioritised list of everything that might be needed in completed product and source of requirements for any changes.
Work backlog: evolving, prioritised queue of business and technical functionality that needs to be developed into a system

Agile steps

Sprint planning
Daily scrums
Development work
Sprint review
Sprint retrospective

Agile limitations

Active user involvement and close collaboration of the Scrum team are critical throughout the development cycle
Evolving requirements can lead to potential for scope creep
It is harder to predict at beginning of project what the end product will actually resemble
Agile requirements are kept to minimum, which can lead to confusion about the final outcomes
Testing is integrated throughout lifecycle, which can add cost to project
Frequent delivery of project features puts a burden on product owners
If it is misapplied to traditional projects, it can be an expensive approach without delivering benefits

Waterfall model

Stages

Gather requirements
Design system
Implement system
Test system
Full development
Maintenance

Requirements are very well understood and fixed at the outset of the project
Product definition is stable and not subject to changes
Technology is understood
Ample resources with required expertise are available freely
The project is of short duration

Extreme programming (XP)

A more aggressive form of Scrum; a software development methodology intended to improve software quality and responsiveness to changing customer requirements
Two guiding features of XP

Refactoring
Pair programming

Advantage of XP is whole process is visible and accountable
Agile PM and XP have grown out of need to combine the discipline of project management methodology with the needs of modern enterprise to respond quickly

Theory of Constraints (TOC)

Identify the constraint
Exploit the constraint
Subordinate the system constraint
Elevate the constraint
Repeat the process

Critical chain solutions

Central Limit Theorem
Activity durations estimated at 50% level
Buffer reapplied at project level

Goldratt rule of thumb (50%)
Newbold formula

Feeder buffers for non-critical paths
Activity network

Resource leveling is not required because resources are leveled within the project in the process of identifying the critical chain
CCPM advocates putting off all noncritical activities as late as possible, while providing each noncritical path in the network with its own buffer
Noncritical buffers are referred to as feeder buffers
Feeding buffer duration is calculated similarly to the process used to create the overall project buffer

Portfolio management

Capacity constraint buffer (CCP) refers to a safety margin separating different projects scheduled to use the same resource
Drum buffers are extra safety applied to a project immediately before the use of the constrained resource to ensure that the resource will not be starved for work

Steps

Identify company resource constraints or drum
Exploit resource constraints
Subordinate individual project schedules
Elevate the capacity of the constraint resource
Go back to step 2 and reiterate the sequence

CCPM limitations

No milestones used
Not significantly different from PERT
Unproven at the portfolio level
Anecdotal support only
Incomplete solution
Overestimation of activity duration padding
Cultural changes unattainable

Project management methodology

Sometimes called a project management ‘approach’ or ‘framework’, it is simply the systematic way in which projects are managed
Why adopt a certain approach for a project?

Make sure that everyone involved in the project is ‘singing from the same hymn sheet’: everybody has the same expectations
Everybody uses common terminology
The most appropriate methodology is used
Ultimately, the project is delivered on time, on budget and to scope

The traditional approach aka Waterfall

The traditional approach to project management uses orthodox methods and techniques in the management process, following a simple, logical sequence
These methods and techniques have been evolved over decades and are applicable for most of the domains
But for some domains, such as software development, traditional project management is not a 100% fit

PRINCE2

PRINCE2 (PRojects IN Controlled Environments) – similar in some ways to PMBOK methodology which is popular in the USA
Developed initially as a standard to be used for all UK-Government information systems projects
Can now be applied to all kinds of projects (small and large) and is widely used in Europe, although it has limitations (see separate slide)
‘PRINCE2 Practitioner’ qualified status needed for employment / participation in many / all UK Government- sponsored projects
Features

Follow a process model
Are managed by exception
Are delivered in stages
Are product-based (focus on what you produce, not on what you do)
Management products, e.g. Stage Plan, Project Initiation Document (PID)
Specialist products, e.g. Project deliverables

Not covered by PRINCE2

Soft skills of people management including motivation, leadership, etc.
Specific techniques for financial analysis, planning, risk management or control of progress, etc.
Use of project management tools (e.g. MS Project)

Terminology

Planning Process PL (Recipe)

The 8 processes that stipulates when to create a plan

Plans are a Component (Ingredients)

The 8 areas of the method that helps with what you do

Product Based Planning is a Technique (Skills)

3 techniques for how you do planning to define project deliverables

PRINCE2 project plan

Product descriptions
Activities to create products
Quality validation activities
Resources and skills needed
Explanatory text
Dependencies between activities
External dependencies
Dates and costs
Monitoring & control arrangements

PRINCE2 stage

Early outline
Detailed scoping & planning
An execution stage
Close

Business case

Justifying the project with the Business Case
Identifying benefits
Make sure the Business Case stays up to date.
Viable business case verified by project board before project begins
Project should be stopped if business case no longer viable

PRINCE2 limitations

PRINCE2 adds additional overhead and may not be viable for all size projects – lots of documentation at each stage consumes resource effort, increasing the cost and duration of the project, disproportionately increasing the cost for smaller projects
Accurate measurement of the project success is not possible unless tangible outcomes are achieved– PRINCE2 focuses on the process and business case justification throughout the project stages instead of the end goal.
PRINCE2 methodology is complex - and it cannot be carried out without experience or special training when compared with some other project management methods, so needs expensive and specialist resource.
PRINCE2 Flexibility is not realistic – although this methodology can theoretically be customised and applied to projects of all types and levels, it does contain some mandatory tasks which become limitations
Documentation requirement increases the size of the project – one of the major issues for small projects is it that it no longer remains a small project due to the additional work required to support PRINCE2 methodology
Not easy to accommodate change requests – it’s not easy to accommodate scope changes once the project has started as focus is always on business case justification by which the project started. PRINCE2 methodology contains very low level of change adaptation process
Some important processes are missing - when viewed holistically, there is no support or ongoing maintenance process. It also does not contain any people management techniques neither budget control mechanisms

Critical Chain Project Management
Event Chain Project Management
Agile Project Management

Agile includes a range of processes / methodologies / approaches include ‘Extreme Programming, Adaptive System Development, DSDM, Feature Driven Development, KanBan, Crystal and many more! Agile is highly customisable!
Agile is an iterative and incremental approach to design and build activities in engineering, IT, product and service development.
Based around the Agile Manifest which says:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left (in bold) more

Scrum Project Management

A kind of ‘Agile’ project management, usually used in software development
Rather than starting with a highly detailed plan of what is to be done on a project, much is left up to the Scrum software development team as they are best placed to solve the problem presented
Work is done in ‘sprints’ of 1 – 4 weeks starting with a sprint planning meeting which defines the desired outcomes
Scrum relies on a self-organising, cross functional team (no overall leader!) so ALL members of the team are essential
BUT, two important roles: ScrumMaster who is like a coach for the team, and Product Owner (PO) who represents the business, customers or users who guides the team towards building the right product

Lean Project Management
Extreme Project Management
Benefits Realisation Project Management

Costing

Cost management has been defined to encompass data collection, cost accounting, and cost control
Cost accounting and cost control serve as the chief mechanisms for identifying and maintaining control over project costs
Cost estimation processes create a reasonable budget baseline for the project
Common source of project cost

Labor
Materials
Subcontractors
Equipment & facilities
Travel

Types of costs

Direct versus indirect
Recurring versus nonrecurring
Fixed versus variable
Normal versus expedited

Cost estimation

Ballpark (order of magnitude) ±30%

Sometimes referred to as order of magnitude estimates, ballpark estimates are typically used when either information or time is scarce. Companies often use them as preliminary estimates for resource requirements or to determine if a competitive bid can be attempted for a project contract. For example, a client may file an RFQ (request for quote) for competitive bids on a project, stating a very short deadline. Managers would have little time to make a completely accurate assessment of the firm’s qualifications or requirements, but they could still request ballpark estimates from their personnel to determine if they should even attempt to bid the proposal through a more detailed analysis. The unofficial rule of thumb for ballpark estimates is to aim for an accuracy of ±30%. With such a wide variance plus or minus, it should be clear that ballpark estimates are not intended to substitute for more informed and detailed cost estimation.

Comparative ±15%

Comparative estimates are based on the assumption that historical data can be used as a frame of reference for current estimates on similar projects. For example, Boeing Corporation routinely employs a process known as parametric estimation , in which managers develop detailed estimates of current projects by taking older work and inserting a multiplier to account for the impact of inflation, labor and materials increases, and other reasonable direct costs. This parametric estimate, when carefully performed, allows Boeing to create highly accurate estimates when costing out the work and preparing detailed budgets for new aircraft development projects. Even in cases where the technology is new or represents a significant upgrade over old technologies, it is often possible to gain valuable insight into the probable costs of development, based on historical examples.

Feasibility ±10%

These estimates are based as a guideline on real numbers, or figures derived after the completion of the preliminary project design work. Following initial scope development, it is possible to request quotes from suppliers and other subcontractors with a greater degree of confidence, particularly as it is common to engage in some general scheduling processes to begin to determine the working project baseline. Feasibility estimates are routinely used for construction projects, where there are published materials cost tables that can give reasonably accurate cost estimates for a wide range of project activities based on an estimate of the quantities involved. Because they are developed farther down the life cycle, feasibility estimates are often expressed in terms of a degree of accuracy of ; 10%.

Definitive ±5%

These estimates can be given only upon the completion of most design work, at a point when the scope and capabilities of the project are quite well understood. At this point all major purchase orders have been submitted based on known prices and availabilities, there is little or no wiggle room in the project’s specifications, and the steps to project completion have been identified and a comprehensive project plan is in place.

Learning curve

Each doubling of output results in a reduction in time to perform the last iteration.

Software project estimation

Function Point Analysis is a system for estimating the size of software projects based on what the software does.
Function Points are a standard unit of measure that represents the functional size of a software application.

Cost estimation limitations

Low initial estimates
Unexpected technical difficulties
Lack of definition
Specification changes
External factors

Project budget

The budget is a plan that identifies the resources, goals, and schedule that allows a firm to achieve those goals.
Top-down
Bottom-up
Activity-based costing (ABC)

Assign costs to activities that use resources.
Identify cost drivers associated with this activity.
Compute a cost rate per cost driver unit or transaction.
Multiply the cost driver rate times the volume of cost driver units used by the project.

Budget contingency

The allocation of extra funds to cover uncertainties and improve the chance of finishing on time
Project scope may change
Murphy’s Law is present
Cost estimation must anticipate interaction costs
Normal conditions are rarely encountered
Recognizes future contains unknowns
Adds provision for company plans for an increase in project cost
Applies contingency fund as an early warning signal to potential overdrawn budget

Project scheduling

Project scheduling requires us to follow some carefully laid-out steps, in order, for the schedule to take shape. PMBoK states, “an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.”
Project planning, as it relates to the scheduling process, has been defined by the PMBoK as: The identification of the project objectives and the ordered activity necessary to complete the project including the identification of resource types and quantities required to carry out each activity or task.
Network diagram

Serial sequential logic
Nonserial sequential logic

Project scheduling term

Project Network Diagram: Any schematic display of the logical relationships of project activities.
Path: A sequence of activities defined by the project network logic.
Event: A point when an activity is either started or completed.
Node: One of the defining points of a network; a junction point joined to some or all of the other dependency lines (paths).
Predecessors: Those activities that must be completed prior to initiation of a later activity in the network.
Successors: Activities that cannot be started until previous activities have been completed. These activities follow predecessor tasks.
Early start (ES) date: The earliest possible date the uncompleted portions of an activity can start.
Late start (LS) date: The latest possible date that an activity may begin without delaying a specified milestone.
Forward pass: Network calculations to determine earliest start/earliest finish for an activity through working forward through each activity in network.
Backward pass: Network calculations to determine late start/late finish for uncompleted tasks through working backward through each activity in network.
Merge activity: An activity with two or more immediate predecessors.
Burst activity: An activity with two or more immediate successors.
Float: The amount of time an activity may be delayed from its early start without delaying the finish of the project.
Critical path: The path through project network with the longest duration.
Critical Path Method: A network analysis technique used to determine the amount of schedule flexibility on logical network paths in project schedule network and to determine minimum project duration.
Resource-limited schedule: Start and finish dates reflect expected resource availability.

Node

Activities on arc (AOA)
Activities on node (AON)

AON network with laddering effect

Early start
Identifier number
Early finish
Activity float
Activity descriptor
Late start
Activity duration
Late finish

Activities

Serial activities: are those that flow from one to the next, in sequence.
Concurrent activities: when the nature of the work allows for more than one activity to be accomplished at the same time, these activities are called concurrent, and parallel project paths are constructed through the network.
Merge activities
Burst activities
Complete activity network
Hammock activity

Duration estimation

Experience
Expert opinion
Mathematical derivation – Beta distribution

Most likely (m)
Most pessimistic (b)
Most optimistic (a)

Symmetrical (normal) distribution for activity duration estimation
Asymmetrical (beta) distribution for activity duration estimation

Critical path

Forward pass – an additive move through the network from start to finish
Backward pass – a subtractive move through the network from finish to start
Critical path – the longest path from end to end which determines the shortest project length
Options for reducing the critical path

Eliminate tasks on the critical path.
Replan serial paths to be in parallel.
Overlap sequential tasks.
Shorten the duration on critical path tasks.
Shorten early tasks.
Shorten longest tasks.
Shorten easiest tasks.
Shorten tasks that cost the least to speed up.

Risk management

Risk management: the art and science of identifying, analysing, and responding to risk factors throughout the life of a project and in the best interest of its objectives.

A dictionary definition of risk is “the possibility of loss or injury”
Project risk management involves understanding potential problems that might occur on the project, how they might impede project success and doing something about it
Risk management is like a form of insurance; it is an investment
Note: In project management an issue is a risk that has already happened

Risk planning: how do we structure the risk management activities?
Risk identification: which risks are likely to affect a project and what are their characteristics? (document them)
Qualitative risk analysis: characterise, analyse and prioritise risks
Quantitative risk analysis: define the probability and consequences of risks
Risk response planning: taking steps to enhance opportunities and reduce threats to meeting project objectives (mitigation and contingency)
Risk monitoring and control: monitor known risks, identify new risks, reducing risks, and evaluate the effectiveness of risk reduction

Project risk: an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality.
Risk = (Probability of Event) * (Consequences of Event)
Importance of risk management

“Project management equals risk management”, Richard Rosen, MDDI, August 2003
Project risk management is the art and science of identifying, assigning, and responding to risk throughout the life of a project and in the best interests of meeting project objectives
Risk management is often overlooked on projects, but it can help improve project success by helping select good projects, determining project scope, and developing realistic estimates
A Project Management Journal (March 2000) study by Ibbs and Kwak show how risk management is often neglected
A KPMG study found that 55 percent of ‘runaway’ projects did no risk management at all

Risk management questions

What is likely to happen (the probability and impact)?
What can be done to minimize the probability or impact of these events?
What cues will signal the need for such action (i.e., what clues should I actively look for)?
What are the likely outcomes of these problems and my anticipated reaction?

Risk management planning

The main output of risk management planning is a risk management plan
The project team should review project documents and understand the organization’s and the sponsor’s approach/attitude to risk
The level of detail will vary with the needs of the project
What might be the attitude to risk for the 2012 Olympics? Might this be different to a project for testing a new aircraft or a project for you and your friends to go on a charity trip to Rwanda?

Risk management plan

Methodology: How will risk management be performed on this project? What tools and data sources are available and applicable?
Roles and Responsibilities: Who are the individuals responsible for implementing specific tasks and providing deliverables related to risk management?
Budget and Schedule: What are the estimated costs and schedules for performing risk-related activities?
Risk Categories: What are the main categories of risks that should be addressed on this project? Is there a risk breakdown structure for the project?
Risk Probability and Impact: How will the probabilities and impacts of risk items be assessed? What scoring and interpretation methods will be used for the qualitative and quantitative analysis of risks?
Risk Documentation: What reporting formats and processes will be used for risk management activities?

Risk register

Major document within the Risk Management Plan
List of risks and their characteristics including (from earlier slide):

Qualitative risk analysis: characterise, analyse and prioritise risks
Quantitative risk analysis: define the probability and consequences of risks
Risk response planning: taking steps to enhance opportunities and reduce threats to meeting project objectives (mitigation and contingency)

Risk register contents

An identification number for each risk event
A rank for each risk event
The name of each risk event
A description of each risk event
The category under which each risk event falls
The root cause of each risk
Triggers for each risk; triggers are indicators or symptoms of actual risk events
Cost overruns on early activities, defective products
Potential responses to each risk
The risk owner or person who will own or take responsibility for each risk
The probability and impact of each risk occurring
The status of each risk (often colour-coded RAG)

Risk utility

Risk utility or risk tolerance is the amount of satisfaction or pleasure received from a potential payoff
Utility rises at a decreasing rate for a person who is risk-averse
Those who are risk-seeking have a higher tolerance for risk and their satisfaction increases when more payoff is at stake
The risk-neutral approach achieves a balance between risk and payoff
Risk takers accept bigger risks for the potential of bigger rewards – what are you?
David Hillson (www.risk-doctor.com) suggests allowing an appropriate level of risk to be taken intelligently with full awareness of the degree of uncertainty and its potential effects on objectives

4 stages of risk management

Risk identification
Analysis of probability and consequences
Risk mitigation strategies
Control and documentation

Risk clusters

Financial
Technical
Commercial
Execution
Contractual or legal risk

Common types of risks

Absenteeism
Resignation
Staff pulled away
Time overruns
Skills unavailable
Ineffective training
Specs incomplete
Change orders
Market risk: will the new service or product be useful to the organization or marketable to others? Will the users accept it? Will someone else create a better product?
Financial risk: can the organization afford to undertake the project? Will the project meet NPV, ROI and payback estimates?
Technology risk: is the project technically feasible? Is it leading edge or bleeding edge technology?
People risk: are people with appropriate skills available to help complete the project? Does senior management support the project?
Structure/process risk: what is the degree of change the new project will introduce into user areas and business procedures? With how many other systems does a new project/system need to interact?
Others: commercial, supply, time, etc.

Risk factor identification

Brainstorming meetings
Expert opinion
Past history
Multiple (or team based) assessments

Risk breakdown structure (RBS)
Risk impact matrix

A probability/impact matrix or chart lists the relative probability (or likelihood) of a risk occurring on one side of a matrix or axis on a chart and the relative impact (or consequence) of the risk occurring on the other
List the risks and then label each one as high, medium, or low in terms of its probability of occurrence and its impact if it did occur
Deal first with those risks in the high probability/high impact cell

Project risk scoring

Use project team’s consensus to determine the score for each Probability of Failure category: Maturity (Pm), Complexity (Pc), and Dependency (Pd).
Calculate overall probability.
Use project team’s consensus to determine the score for each Consequence of Failure category: Cost (Cc), Schedule (Cs), Reliability (Cr), and Performance (Cp).
Calculate Cf by adding the four categories and dividing by 4
Calculate Overall Risk factor for the project by using the formula

Rule of Thumb

Low Risk: RF < 0.30
Medium Risk: RF = 0.30 to 0.70
High Risk: RF > 0.70

Risk responding techniques

After identifying and quantifying risks, you must decide how to respond to them
Risk avoidance: change approach so risk disappears
Risk acceptance: prepare for risk with backup plan or contingency actions to reduce impact/consequence
Risk transference: make it someone else’s problem, e.g. agree it is a contractor’s legal responsibility
Risk mitigation: reduce probability/likelihood of occurrence e.g., use proven technology, employ understudy, etc.

Risk mitigation strategy

Accept
Minimize
Share
Transfer
Contingency Reserves

Task contingency
Managerial contingency
Insurance

Other Mitigation Strategies

Mentoring
Cross training

Control and Documentation

Change management

Project risk analysis and management (PRAM)

PRAM presents a generic methodology that can be applied to multiple project environments, and encompasses the key components of project risk management.
Risk management follows a life cycle.
Risk management strategy changes over the project life cycle.
Synthesised, coherent approach

Phases of risk assessment

Define
Focus
Identify
Structure
Clarify ownership of risks
Estimate
Evaluate
Plan
Manage

Monitoring and controlling

Large projects have a ‘risk’ committee or similar
The risk management plan will define how often they meet
Usually will review register and high risk items
Agree actions, changes and next steps
Review results of previous actions and change scores as appropriate
Goal is to seek to identify and minimise risks that would prevent project goals being achieved
Risk management NEVER stops!

Project control and evaluation

Control cycle

Setting a goal.
Measuring progress.
Comparing actual with planned performance.
Taking action.

Project Sierra's S-curve
Milestone analysis

Milestones are events or stages of the project that represent a significant accomplishment.

Signal completion of important steps
Motivate team and suppliers
Offer reevaluation points
Help coordinate schedules
Identify key review gates
Signal other team members when their participation begins
Delineate work packages

Gantt chart
Earned Value Management (EVM) recognizes that it is necessary to jointly consider the impact of time, cost, and project performance on any analysis of current project status.

Earned Value (EV) directly links all three primary project success Metrics (cost, schedule, and performance).
EV terms

Planned value (PV)
Earned value (EV)
Actual cost of work performed (AC)
Schedule variance (SV) and Schedule performance index (SPI)
Cost variance (CV) and Cost performance index (CPI)
Budgeted cost at completion (BAC)
Estimate at completion (EAC)

Steps of EV

Clearly define each activity including its resource needs and budget.
Create usage schedules for activities and resources.
Develop a time-phased budget (PV).
Total the actual costs of doing each task (AC).
Calculate both the budget variance (CV) and schedule variance (SV).

Accurate and up-to-date information is critical in the use of EVM.

0/100 Rule
50/50 Rule
Percentage Complete Rule

Human factors in project evaluation & control

Project coordination and relations among stakeholders
Adequacy of project structure and control
Project uniqueness, importance, and public exposure
Success criteria salience and consensus
Lack of budgetary pressure
Avoidance of initial overoptimism and conceptual difficulties

Critical success factors in project implementation profile

Project mission
Top management support
Project plans & schedules
Client consultation
Personnel
Technical tasks
Client acceptance
Monitoring & feedback
Communication channels
Troubleshooting

Project termination

Termination reasons

Extinction

Termination by extinction: This process occurs when the project is stopped due to either a successful or an unsuccessful conclusion. In the successful case, the project has been transferred to its intended users and all final phase-out activities are conducted. Whether successful or not, however, during termination the project’s final budget is audited, team members receive new work assignments, and any material assets the project employed are dispersed or transferred according to company policies or contractual terms.

Addition

Termination by addition: This approach concludes a project by institutionalizing it as a formal part of the parent organization. For example, suppose a new hardware design at Apple Computer has been so successful that the company, rather than disband the project team, turns the project organization into a new operating group. In effect, the project has been “promoted” to a formal, hierarchical status within the organization. The project has indeed been terminated, but its success has led to its addition to the organizational structure.

Integration

Termination by integration: Integration represents a common, but exceedingly complicated, method for dealing with successful projects. The project’s resources, including the project team, are reintegrated within the organization’s existing structure following the conclusion of the project. In both matrix and project organizations, personnel released from project assignments are reabsorbed within their functional departments to perform other duties or simply wait for new project assignments.

Starvation

Termination by starvation: Termination by starvation can happen for a number of reasons. There may be political reasons for keeping a project officially “on the books,” even though the organization does not intend it to succeed or anticipate it will ever be finished. The project may have a powerful sponsor who must be placated with the maintenance of his “pet project.” Sometimes projects cannot be continued because of general budget cuts, but an organization may keep a number of them on file so that when the economic situation improves, the projects can be reactivated. Meredith and Mantel 4 argue that termination by starvation is not an outright act of termination at all, but rather a willful form of neglect in which the project budget is slowly decreased to the point at which the project cannot possibly remain viable.

Natural termination-closeout process

Finishing the Work
Handing Over the Project

Private Finance Initiatives (PFIs)
Build, Operate, and Transfer (BOT)
Build, Own, Operate, and Transfer (BOOT)

Gaining Acceptance for the Project
Harvesting the Benefits
Reviewing How It All Went

Post project reviews

Objectivity and Issues

Outside reviewers are unfamiliar.
Project team may be suspicious.
Outside evaluators may be compelled to find problems.
Outside reviewers are not competent.

Internal Consistency
Replicability
Fairness

Post project meetings

Misidentifying systematic errors
Misapplying or misinterpreting lessons based on events
Failure to pass along conclusions
Establish clear rules of behaviour
Describe objectively what occurred
Fix the problem, not the blame

Closeout paperwork

Documentation
Legal
Cost
Personnel

Required review

General program and project management confidence
Commercial confidence
Market and sales confidence
Product quality confidence
Manufacturing confidence
Supply chain logistics confidence
Aftermarket confidence
Health, safety, and environment confidence

Closeout blockage

Project sign off discourages other closeout activities.
Urgency of all project pressures cause shortcuts on back-end.
Low priority given to closeout activities.
Lessons learned analysis seen as bookkeeping.
Unique view of projects.

Dynamic factors to monitor

Static
Task-team
Sponsorship
Economics
Environment
User

Early termination rules

Costs exceed business benefits.
Failure to meet strategic fit criteria.
Deadlines continue to be missed.
Technology evolves beyond the project’s scope.

Project termination issues

Emotional

Staff
Client

Intellectual

Internal
External

Concerns when shutting down a project

Emotional Issues of the Project Team

Fear of no future work
Loss of interest in remaining tasks
Loss of project-derived motivation
Loss of team identity
Selection of personnel to be reassigned
Diversion of effort

Emotional Issues of the Clients

Change in attitude
Loss of interest in project
Change in personnel dealing with project
Unavailability of key personnel

Intellectual Issues-Internal

Identification of remaining deliverables
Certification needs
Identification of outstanding commitments
Control of changes to project
Screening of partially completed tasks
Closure of work orders and work packages
Disposal of unused material

Intellectual Issues-External

Agreement with client on remaining deliverables
Agreement with suppliers on outstanding commitments
Communicating closure
Closing down facilities
Determination of requirements for audit trail data

Signs of IT project failure

Best practices and lessons learned are ignored.
Project lacks people with appropriate skills.
Sponsorship is lost.
Users are resistant.
Deadlines are unrealistic.
Business needs change.
Chosen technology changes.
Project changes are poorly managed.
Scope is ill-defined.
Project managers don’t understand users’ needs.

Claims and dispute

Two types of claims

Ex-gratia claims
Default by the project company

Resolved by

Arbitration

Binding
Non-binding

Protection against claims

Consider claims as part of the project plan.
Verify stakeholders know their risks.
Keep good records throughout the life cycle.
Keep clear details of change orders.
Archive all correspondence

Final report element

Project performance
Administrative performance
Organizational structure
Team performance
Project management techniques
Benefits to the organization and customer

Summary

PMBOK: Waterfall
PRINCE2: Agile
Project management: strategic level, tactical level, operational level
Belbin’s 9 team roles
https://www.hofstede-insights.com/product/compare-countries/
https://globeproject.com/
Link to the Project Management Institute (PMI) website https://www.pmi.org
Link to the Association of Project Managers (APM) website https://www.apm.org.uk
Link to Chartered Management Institute website https://www.managers.org.uk
Reference for project managers https://project-management.com
PM Network https://www.projectmanagement.com/PM-Network/

Search This Blog

Aloysius Chan's Blog

Project Management (MBA module 6 of 8)

Comments

Post a Comment

Popular posts from this blog

Kokology Questions & Answers

Neuro-Linguistic Programming Models Summary (02 of 14)

Neuro-Linguistic Programming Models Summary (11 of 14)