Project Management 3377 - Final

Lecture 1

What is a project?

• A project is not a process. A project is a collection of tasks organized to have defined start and finish with the purpose of creating a product or service.

• It is an undertaking that is unique, and temporary

• Has a beginning and an end

definition:

• A temporary endeavor undertaken to create a unique product, service or result.

• Has a start and end date.

• Consumes time and resources

The Triple Constraint

• Time = amount of time to complete project, cost = budgeted amount available, scope = must must be done to produce end product

• Three constraints are competing, if one changes something else will as well

Importance of Project Management

• 1. The product life cycle shortens with improved efficiencies. Constant innovation is therefore required. Ad hoc efforts fail in the face of organized competition (e.g. electronics, automotive)

• 2. Product launch windows are narrow. (The concept of selling product A while developing product B) Product life cycle

• 3. Increasingly complex and technical products. (Consumer demand)

Watwerfal (plan driven)

• Start, focus, end

• Customer can’t make changes

Agile Development

• Agile = quick

• Show customer every 2-4 weeks

• Don't need to know whole scope or have entire end point

Henry Gantt

• Forefather of project management in USA, 1910-1920

• Development of Gantt chart and contributed to early development of work breakdown structure tools

Frederick Winslow Taylor

• Paper, The Principles of Scientific Management, argued that decisions based on tradition and rules of thumb should be replaced by procedures developed

• Scientific Management

• is a method in management theory which determines changes to improve labor productivity and its detailed application in the workplace led to - for the first time - application of charts to plan and track projects as workers efforts became standardize

Henry Ford

Mass production of large numbers of inexpensive automobiles using assembly line + high wages = Fordism

Cybernetics, Six SIgma, Lean Manufacturing

• Cybernetics is focused on how anything (digital, mechanical or biological) processes information, reacts to information, and changes or can be changed to better accomplish the first two task

• Six Sigma is a set of practices originally developed by Motorola to systematically improve processes by eliminating defects. It asserts that:

• 1) Continuous efforts to reduce variation in process outputs is key to business success.

• 2) Manufacturing and business processes can be measured, analyzed, improved and controlled.

• 3) Succeeding at achieving sustained quality improvement requires commitment from the entire organization, particularly from top-level management

• Lean Manufacturing, derived from Toyota’s best practices, is dedicated to reducing waste by now famous methods such as Kanban, Kaizen, Poke-Yoke, usage of just in time automation

• Waste as in time waste, walking waste

Work Breakdown Structure (WBS)

• A Work Breakdown Structure (WBS) is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure.

• The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope.

• A well-designed WBS describes planned outcomes instead of planned actions and makes it easy to assign any project activity to one and only one terminal element of the WBS

• The WBS is a tool for managing the scope of a project

• What is project scope? The work required to complete a project

Initiating, Planning, Executing, Controlling, and Closing - Where do you spend the most effort on a project?

• Where do you spend the most effort on a project? -> execution & control

Project Manager vs Manager

• PM’s generally are entry level management positions.

• Except in highly projectized organizations, PM’s typically do not have “ownership” of the employees they apply.

• Again except in functional organizations PM’s do not do salary reviews, schedule vacation, or dole out discipline. This is the job of the functional manager.

• Project Managers are typically privy to significant amounts of confidential information, both human resource and financial related.

• The project manager does more than 90% of the day to day management of the employee typically. This includes setting priorities for the group and following up on them

Project Stakeholders

• All suppliers, customers, colleagues, sponsors, experts, interested outside influences are project stakeholders and it is the PM’s job to manage all of them.

• Without total stakeholder satisfaction, the project is measured as a failure. This is an important distinction, and it explains why the Project Management Institute generally quotes a figure of only 26% of projects being classified as successes. Certainly in the great majority of cases the good or service was delivered as expected, but due to stakeholder dissatisfaction success cannot be claimed

• Organization Stakeholders - EXAM

• Organizational stakeholders: employees, manager, president company

• Not: customer, supplier

Portfolio Management - exam

• A portfolio refers to a collection of projects or programs that are grouped together to facilitate effective management of that work to meet strategic business objectives.

• Portfolio management refers to the central alignment of one or more portfolios. It focuses on ensuring alignment of projects with organizational strategies and objective.

• Example is infrastructure firm that groups its similar infrastructure projects together to facilitate managing for a “best return on investment” Example all wind projects grouped together in a program, all solar grouped together in another program, all roads grouped together in a third. The manager of all these programs is the portfolio manage

Organizational Process Assets - exam

• Internal assets that influence the management of projects in an organization

• Typical organizational process assets include:

• Plans

• Procedures

• Policies

• Processes

• Knowledge base (lesson learned, risk data, EVM dat

Enterprise Environmental Factors - exam

• Enterprise environmental factors refer to both internal and external environmental factors that surround or influence a project’s success.

• They can arise from any of the enterprises involved in the project and are generally an input to most planning processes.

• Typical enterprise environmental factors include:

• Organizational culture, structure, and process

• Infrastructure

• Company work authorization systems

• Marketplace conditions

• Stakeholder risk tolerances

• Political climate

• Organization’s established communication channels

• Existing Human resources and personnel administration

Lecture 2

How is a company managed?

• From the top down in a classical military hierarchy (one person on the top has all the power)

• Upper Management develops vision statements

• Middle Management makes mission statements out of that

• Missions in turn get broken down into objectives for projects and departments.

• They are then broken down into strategies, goals, values and initiatives.

• Often about more money, but also need to fit strategic goals (environment, employee engagement, safety)

Vision & Mission Statement

• Vision statement: business's meaning and purpose for stakeholders, particularly employees. Its more of a look into the future, its what the organization wants to evolve into.

• Flows down to the mission statement

• Mission statement: states the purpose and objectives of an organization

• The firms core business

Organizational Structure - EXAM

• Functional Organizations

• Project Organizations

• Exam question: where does PM have best success with which type of organizational structure? Answer Project Organizations

• Matrix Organizations

Functional Organizations

• Siloed, each department only cares about themself

• Strengths for PM

• Projects are developed within the basic functional structure of the organization, requiring no disruption or change of the firm's design

• Enables the development of in-depth knowledge and intellectual capital

  • In depth, right in the department

• Allows for standard career paths. Project team members only perform their duties as needed while maintaining maximum connection with their functional group

• Weaknesses for PM

• It is difficult to achieve cross-functional cooperation

• Lack of customer focus

• Projects generally take longer to complete due to structural problems, slower communication, lack of direct ownership of the project, and competing priorities among the functional departments

• Projects may be sub-optimized due to varying interest or commitment across functional boundaries.

  • Less money because it goes to running the plant

Project Organizations

• Work with different departments, get done faster

• Strengths for PM

• Assigns authority solely to the PM

• Leads to improved communication across the organization and among functional groups

• Promotes effective and speedy decision making

• Promotes the creation of cadres of PM experts

• Encourages rapid response to market opportunities

• Weaknesses for PM

• Setting up and maintaining teams can be expensive

• Potential for project team members to develop loyalty to the project rather than the overall organization

• Difficult to maintain a pooled supply of intellectual capital

• Concern among project team members about their future once the project ends

Matrix Organizations

• Biggest concern for project resources: who to listen to, have 2 bosses

• Creating an organization with 2 bosses may seem awkward, but there are important advantages to this approach if certain conditions are met:

• There is pressure to share scarce resources across product or project opportunities.

• There is a need to emphasize two or more different types of output. E.g. the company may need to promote it's technical competence (using a functional structure) while continually creating new products (project structure)

• The environment of the organization is complex and dynamic. When firms face complexity and rapidly changing environmental pressures the matrix organization is flexible to accommodate this change

• Strengths for PM

• Suited to dynamic environments

• Emphasizes the dual importance of project management and functional efficiency

• Promotes coordination across functional units

• Maximizes scarce resources between competing project and functional responsibilities

• Weaknesses for PM

• Dual hierarchies mean two bosses

• Requires significant time to be spent negotiating the sharing of critical resources between projects and departments

  • Two bosses, who wins?

• Can be frustrating for workers caught between competing project and functional demands

Stakeholder Management

• What is a "stakeholder"?

• Project Stakeholders are defined as:

• Individuals or groups who have an active stake in the project and can potentially impact it's development.

• Internal Project Stakeholders

• Management, accountant, team members, employees, board directors, presdent

• External Project Stakeholders

• clients/customers, competitors, suppliers, 

• environmental, political, consumer, unions, protestors and other groups

• Who is not an organizational stakeholder? - EXAM

• Think organizational = internal

• Therefore, customer is NOT internal, NOT organizational

Communication Paths - EXAM

• communication paths= n(n-1)/2

• n= number of communication participants

Organizational Culture

Defined as: “The solution to external and internal problems that has worked consistently for a group and that is therefore taught to new members as the correct way to perceive, think about and feel in relation to these problems.”

• Key Factors that Affect the Development of a Culture

• technology (use of email, telephone, meetings)

• environment (automotive, aerospace, government, CO2 emissions regulations, government subsidies)

• geographical location (Daimler-Chrysler merger failure, Mexican or Chinese LCC)

• reward systems (hourly pay, salary, bonus)

• rules and procedures (rule: 40 hrs/wk, really expected: 45 hrs)

• key organizational members (founder of the organization forms culture, Bill Gates vs Steve Jobs)

• critical incidents (become part of the company's lore, either for good or for bad)

• How does Culture Affect Projects?

• Department interaction

  • Cultures favoring cooperation between functional groups and new projects are much more successful than those that adopt a disinterested or even adversarial relationship.

• Employee commitment to goals

  • Projects depend on the commitment and motivation of the team members.

  • Team members have to understand the why in order to be motivated.

• Project planning

  • "Padding" of duration estimates when it is not accepted to be late, but to plan poorly

• Performance evaluation

  • When a culture sends the signal that the goal of the firm is to create innovative new products, it reinforces a project management culture that is aggressive and offers potentially high payoffs (and the occasional significant loss!).

Public/Private Partnerships

• Public–private partnership (P3) describes a government service or private business venture which is funded and operated through a partnership of government and one or more private sector companies. These schemes are sometimes referred to as a P3.

• P3 involves a contract between a public-sector authority and a private party, in which the private party provides a public service or project and assumes substantial financial, technical and operational risk in the project. In some types of P3, the cost of using the service s borne exclusively by the users of the service and not by the taxpayer.

• In other types (notably the private finance initiative), capital investment is made by the private sector on the strength of a contract with government to provide agreed services and the cost of providing the service is borne wholly or in part by the government 

• Government contributions to a P3 may also be in kind (notably the transfer of existing assets).

lecture 3

Collecting Requirements - EXAM

• Business Requirements (high level expectations) (vision, mission, goals)

• Stakeholders requirements (customer, end user)

• Solutions requirements

• Functional (what you see)

• Nonfunctional (i.e. level of performance)

• Project requirements (project processes)

• Quality requirements (metrics, performance measures)

• Collecting Requirements - How?

• Interview the stakeholders

• A conversation with the customer

• Have a list of questions

• Listen

• One on one is best

• Focus group

Project Constraints

• Before you can define the scope of a project, you have to know and understand the enterprise environmental factors that place natural limits to the scope in place.

• Constraints are factors that limit the team's options on things such as resources, budget, and schedule.

• Constraints are inputs to many aspects of project management. Management identifies some, project managers others, with the team and other stakeholders identifying even more

• Constraints - EXAM

  • Schedule

  • Budget

  • Quality

  • Resources

  • Customer expectations and satisfaction

  • Risks

Enterprise Environmental Factors - EXAM

• Enterprise environmental factors refer to both internal and external environmental factors that surround or influence a project’s success.

• They can arise from any of the enterprises involved in the project and are generally an input to most planning processes.

• Typical enterprise environmental factors include:

• Organizational culture, structure, and process

• Infrastructure

• Company work authorization systems

• Marketplace conditions

• Stakeholder risk tolerances

• Political climate

• Organization’s established communication channels

• Existing Human resources and personnel administration

Scope Statement

• A Scope statement is the first document produced in the planning phase of a project being managed and should include:

• the project objectives

• the project deliverables

• the project milestones (ex. Foundation of a house complete, exterior, etc.)

• the project technical requirements

• the project limits and exclusions (ex. This plan excludes the landscape)

• a signed off approval of a review of the document with the customer (customer is not always external, could be your boss)

• a signed off approval of a review of the document with corporate management

• Inputs to the Scope Statement

  • Project charter

  • Requirements document

  • Enterprise environmental factors

  • Organizational process assets

  • Other names for Scope Statements

• Statement of Work, Contract, Proposal

• The Scope Statement is NOT - EXAM

  • Nondisclosure Agreement, Independent Contractor Agreement-discloser agreement

• Scope Statement Negotiation

  • The Scope statement can be hard to gain approval on from all stakeholders. People like to debate the wording, but successful sign off on this item is critical to project success.

Scope Management Plan

• Plan for entire project

• Usually reviewed when looking at milestones to make sure on track

• A Project Scope Management Plan can be driven by project progressive elaboration. Items get near the edge of the scope, and then eventually wander out.

• This is the document that describes how scope and scope changes will be managed. 

• A scope management plan provides advantages. In particular less scope creep, fewer scope changes, less scope conflict, improved communications, and customer satisfaction are achieved.

• The plan is often executed as an extension of the Management by Objectives (MBO) Philosophy which says an organization should:

• Establish unambiguous and realistic objectives

• Periodically evaluate if objectives are being met

• Take corrective action

Scope Verification

• Definition of scope verification: The process of formalizing acceptance of the project scope by the stakeholders.

• Scope verification consists of some or all of the following and is completed at the end of each project phase:

• Reviewing work to ensure it is correctly completed and is satisfactory

• Conducting inspections, reviews, and audits

• Determining whether results conform to requirements

• Documenting completion of deliverables

• Gaining formal sign off

• Scope verification is similar to quality control, but QC relates to the correctness of the work, while scope verification relates to customer acceptance of the work.

• Do we need all stakeholders to agree to scope? - EXAM

• No! Some stakeholders are just groups to be aware of (ex. Environmental groups, the bank, etc.)

Work Breakdown Structure - EXAM

• WBS always used for a project when using good PM practices

• Definition: A work breakdown structure (WBS) is a deliverable oriented grouping of project components that organizes and defines the total scope of the project.

• The WBS is the project scope broken down into smaller manageable pieces.

• Project managers cannot, in fact nobody can, manage projects. PM's manage pieces of projects.

• A WBS looks like a company organization chart, particularly one under development and not yet broken down into its lowest levels, but it is not.

• The WBS is the tool used to decompose a scope to a manageable level.

• Characteristics of a WBS

• Tasks at the lowest level should take between 8 and 80 person hours to complete. This is the correct level of detail required for people to manage.

  • Not more 2 weeks, not less 1 day, if over 80 hrs just break down

• A WBS demonstrates the flow of work for a project and allows the team to view it. A simple list does not.

• A WBS is the correct illustration for generating stakeholder buy-in for a project.

• Rules for Creating a WBS

• A WBS is created by the full project team (SME’s).

• The first level is completed before the project is broken down further

• Each level of the WBS is a smaller segment of the level above

• The entire project is included in each of the higher levels, however eventually some levels will be broken down more than others.

• Work toward the project deliverables

• Work not included in the WBS, is not part of the project.

• Break down the project into work packages that can be realistically and confidently estimated.

• Break down the project to a point where it can no longer be logically subdivided, can be completed quickly, and has a meaningful deliverable.

• Break down the project into packages that can be completed without interruption. (no additional information required)

• Question - For which of the following can work breakdown structure be used?

1. Communicating with the customer

2. Showing calendar dates for each task

3. Showing the functional managers for each team member

4. Showing the business need for the project

• Question - For which of the following can work breakdown structure be used?

1. Communicating with the customer - YES

2. Showing calendar dates for each task

3. Showing the functional managers for each team member

• A WBS does not show dates or work assignments, those are in Gantt chart and possibly in communications plan

4. Showing the business need for the project

• Business need is shown in project charter

Work Packages

• When bottom of WBS, down to work package level

• The lowest level the project manager will manage is called the work package, also sometimes called the activity.

• The person completing the work package may break it down further, but the PM will only track the work to the work package level.

• When the rule of thumb duration is exceeded for work packages, it is often in a scenario where a project manager is working for another project manager. i.e. in subcontractor situations common in the construction and manufacturing industries.

Project Management Maturity - Exam Q on Maturity

Work Authorization

• Once the scope has been decomposed into useful work packages, the next natural step is to get formal agreement between stakeholders regarding project content known as the work authorization. If the client is external, this likely includes the contract signoff.

• Project management contracts to be valid require and consist of at least:

1. Possessing the legal right to contract

2. Being of legal age to contract

3. Being of sound mind at the time of signing

4. Valid and Legal Consideration for both parties

5. A legal scope of work

6. Offer and acceptance

7. Mutual intent to contract

• Project management contracts also likely contain many of the following:

• Excusable delays (ex. Construction in this weather)

• Allowable costs (ex. Over budget)

• Statements of liquidated damages (non-performance clauses)

• Criteria for Inspection

• Responsibility for correction of defects

• Dispute resolution mechanisms

• Question - A project manager new to project management has asked why they should bother using a work breakdown structure (WBS) on their project. The BEST response would be:

1. Tell them it will prevent work from slipping through the cracks.

2. Tell them that one is not needed

3. Tell them it is required if the project involves contracts

4. Tell them it is the only way to identify risks

• Question - A project manager new to project management has asked why they should bother using a work breakdown structure (WBS) on their project. The BEST response would be:

1. Tell them it will prevent work from slipping through the cracks. YES!

2. Tell them that one is not needed

3. Tell them it is required if the project involves contracts (not true)

4. Tell them it is the only way to identify risks

Scope Reporting - EXAM

• Scope reporting consists of regular updates regarding cost, schedule, and technical performance. Typical documents include:

• S-Curves (graphical display of costs vs. project schedule)

• Earned Value Analysis: Reports project status in terms of both costs and time – The budgeted value of work performed regardless of actual costs incurred.

• Variance or exception reports – documenting any slippages in time, cost, or resources

• Schedule status: Updates on schedule adherence

• Technical performance status: Updates on technical challenges and solutions

• The parties receiving these documents could be any stakeholders that need to know

A Lean History

• Lean is a manufacturing & production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination

• “Value” is defined as any action or process that a customer would be willing to pay for

• Lean is centered around preserving value with less work

• Lean manufacturing is based on optimizing flow, increasing efficiency, decreasing waste, and using empirical methods to decide what matters, rather than uncritically accepting pre-existing ideas

• Toyota was a leader in implementing lean practices in the 80s

The Seven Types of Waste

1. Defects/Rework – scrap and fixing errors (make mistake, takes more time to fix)

2. Overproduction – making more just in case (paid for extra stock, unneeded, expire)

3. Inventory/Queue – excessive work in process inventory 

4. Over-Processing – beyond what the customer needs (better quality than necessary)

5. Motion – unnecessary and awkward movements (ex. Walking to printer)

6. Transport – unnecessary material movement (transport is on wheels, ex. Taking the long way)

7. Waiting – delay for an upstream activity to complete (waiting for someone else to do their part)

8. People Waste - everyone has experiences to contribute, companies should take advantage of what everyone can do

Value is Defined by the Customer

• Value Added Activities in Software Developments include:

• Data Base Generation

• High Level Coding

• Machine Language Coding

• Integration Coding with other necessary hardware elements

• Creation of Sub routines and functions

• Creation of Graphics

• Integration of Human Machine Interface

• VM Ware set point selection

• Site trials and commissioning

• Incidental Support Activities (NON Value added) in Software Developments include:

• Standards Developments

• Purchase Order and Invoice processing

• Reports and Presentations

• Bread board or offsite preliminary trials

• Verification of compliance with other software present such as operating systems, fire walls, virus protection

• Verification of compliance with other systems present such as power outage recovery systems, loss of network recovery systems, etc.

• Waste Activities (NON Value Added) in Software Developments include:

• Waiting for information and decisions

• Design and field rework

• Ineffective and too many meetings

• Storing and moving coded elements

• Excess Reporting and paperwork

• Designing for unnecessary or obsolete end user hardware

• Unplanned debugging post launch

• Sorting and removing old program output files

Where to Use Agile or Waterfall

• Waterfall:

• Highly structured processes driven organization

• Large bureaucratic organization

• Organizations that are government regulated

• Agile:

• Fast, lean (somewhat unstructured) organizations

• An environment of (true) collaboration

• Can be big or small

lecture 4

Selling How Time will be used to the senior leadership - EXAM

• Preliminary Project Proposal (PPP): The preliminary project proposal is a short, enthusiastic study outlining the advantages and benefits of the proposed project. It contains raw cost and benefits estimates and positive impacts of the project.

• Project Proposal (PP): This document offers a detailed perspective of the project objectives, and cost and benefits are more precise and elaborate. Resource requirements are defined and the document is used as a contractual agreement to be signed-off. Producing the project proposal often involves the participation of many people in the organization, as expertise from several units is required.

• Project Management Plan (PMP): This document is the last revision and update of the previous ones. Financial estimations are expected to be accurate, and it is completed when the project is well into its design phase. The project plan is the result of the cooperation of all the people having a primary interest or involvement in the project.

• Project Post Mortem (PPM): This document is produced sometime after the project is dismantled. It contains the lessons learned and possibly some statistical data about performance, and quality.

Complimentary Plans to the Time Plan

• Contingency plans: These plans are elaborated when the risk management cycle is performed. They consist of the identification of tasks that would be performed given the occurrence of a particular risk.
  These tasks are planned, sequenced, and estimated in the same way as project activities. This allows the project manager to quantify the impact on project cost and schedule of identified project risks.

• Quality standards: Often, strict, quantifiable levels of quality are contractually required. When this is the case, the project plan should contain the quality standards that are mandatory and include quality plans.

• Implementation standards: Organizations often follow technical processes for the elaboration of their products. They include standards on the way certain activities should be accomplished. The project plan should point to, or contain, these standards.

• Installation plan: When materials and products must be delivered, a delivery and installation plan is required. Often, products integrate the client structure in complex ways and a strategy must be developed to perform the installation.

• Acceptance and test plans: Conforming to quality standards and to client expectations are goals that deserved to be planned. Test plans include everything that is needed to gain assurance acceptable quality levels are reached, whereas acceptance plans exactly define the client requirement for accepting the project results.

• Maintenance plan: Maintenance contracts are often awarded to organizations that have delivered products to clients. If this is the case at the end of a project, then a maintenance plan, which acts as a contract between the client end the vendor, must be established.

• Documentation standards: All projects should have documentation standards, if only for clarity. These standards should be included as sub plans of the project plan. Anyone making a document contribution to the project must follow the standard.

• Taken collectively, all these plans together are known as “The Project Plan”

• Project charter is most important!

Project Scheduling

• First you need to generate the Work Breakdown Structure (WBS) for the project as previously demonstrated in an earlier lecture.

• From the WBS, you need to generate the Network Activity Diagram for the project – commonly referred to as the Network Diagram

Key Scheduling Terminology

• Scope – The work content and products of a project. 

• Work Breakdown Structure (WBS) – A task oriented family tree of activities that organizes, defines, and graphically displays the total work to be accomplished in order to achieve the final objectives of the project.

• Work Package – A deliverable at the lowest level of the work breakdown structure. 

• Often identified as a task, 4-80 hours, assign individual resource or person to work, budget, and how long it will take

• Project Network Diagram – Any schematic display of the logical relationships of project activities.

• Path – A sequence of activities defined by the project network logic.

• Early Start Date (ES) – The earliest possible date on which the uncompleted portions of an activity can be completed.

• Late Start Date (LS) – The latest possible date that an activity may begin without delaying a specified milestone.

• Forward Pass – Network calculations that determine the earliest start/finish time for each activity.

• Backward Pass – Calculation of late finish times for all uncompleted network activities.

• Event – A point in time when an activity is either started or completed.

• Node – One or more defining points of a network. A, B, C

• Predecessors – Those activities that must be completed prior to a later activity in the network.

• Successors – Activities that cannot be started until previous actions have been completed.

• Merge Activity – An activity with 2 or more immediate successor activities flowing into it.

• Burst Activity – An activity with 2 or more immediate successor activities flowing out from it.

• Float (Slack) – the amount of time an activity may be delayed from its early start without delaying the finish of the project.

• Ex, slack in A because don’t to D until B complete

• Critical Path – The path through the project network with the longest duration.

• Critical Path Method – A network analysis technique used to determine which sequence of activities (which path) has the least amount of scheduling flexibility and therefore will most likely determine when the project can be completed.

• Determine longest amount of time project can take

• Resource Limited Schedule – A project schedule whose start and finish dates reflect expected resource availability.

• Maybe said done in 30 days, but resources not available, engineer has to do, can't do all at once, push out time

• Program Evaluation and Review Tool (PERT) – An event and probability based network analysis system generally used in projects where activities and their durations are difficult to define.

The Critical Path - EXAM

• The critical path is the longest set of tasks in the network that must be completed to complete a project

• LONGEST SET OF TASKS, minimum take 32 days

• The tasks on the critical path are called critical because if they're delayed, the project end date will slip

Steps to Reduce the Critical Path

• 1. ELIMINATE TASKS ON THE CRITICAL PATH (if can)

• 2. REPLAN SERIAL PATHS TO BE PARALLEL (break out)

• 3. OVERLAP SEQUENTIAL TASKS (if can, if once start one can start another halfway through maybe)

• 4. SHORTEN THE DURATION ON CRITICAL PATH ACTIVITIES

• 5. SHORTEN EARLY TASKS

• 6. SHORTEN LONGEST TASKS

• 7. SHORTEN EASIEST TASKS

• 8. SHORTEN TASKS THAT COST THE LEAST TO SPEED UP

Resource Leveling - EXAM

• Sometimes it is necessary to make the critical path of the project actually longer!  This technique is called resource leveling.

• While resource leveling does not by definition mandate lengthening the critical path it almost always does.

• Resource leveling is carried out when a project resource must be used to address scheduled activities that need to be performed to meet specified delivery dates, or to address a situation where shared or critical resources are only available at certain times or in limited quantities.

• Resource leveling is also used to keep selected resources at constant levels during specific times of the project work.

Activity Duration Estimation - EXAM

• There are several methods:

• Expert judgment estimating – Guided by historical information this can be used whenever possible.EXAM

• Analogous estimating – A method of estimating that employs using a similar schedule activity from a previous project as the basis for establishing the likely duration of a future schedule activity.EXAM

• Parametric estimating – the quantity of work multiplied by the productivity rate.  For example labor hours to draw times number of hours, or cable installation in meters of cable times labor hours per meter.EXAM

• Three point method – PERT

Reserve analysis estimating – An output of risk analysis, it can be employed to add empty buffers in project timing to deal with risk as part of a contingency plan.

Lags in Precedence Relationships

• 1) Finish to Start (assignment) - EXAM

• Most common, what have been looking at so far

• Start one, then next, this on shows lag 4

• 2) Finish to Finish - EXAM

• One task completed after other completed, R and T need to finish on day 36, both same time

• Setting up the software and simultaneously establish the links to the interfaces and devices.

• However, you can only complete the software configuration after all interfaces and devices have been connected.

Gantt Charts

• Developed by Harvey Gantt in 1917, they are another extremely useful tool for creating and showing a project network.

• Gantt charts establish a time-phased network, which links project activities to a project schedule

• When they are linked to a project schedule, they can be used to track the progress of the project against its plan. Some of the benefits of Gantt Charts are:

• a)they are easy to read and comprehend

• b)they identify the project network coupled with the schedule

• c)they allow for updating and project control

• d)they are useful for assigning resources to tasks

• e)they are also easy to create.

Crashing Projects - Under what Conditions? - EXAM

• The initial schedule may be too optimistic. 

• Market needs change and the project is in demand earlier than anticipated. 

• The project has slipped considerably behind schedule. 

• The contractual situation provides even more incentive to avoid schedule slippage. 

• Crashing = accelerating activities, how to shorten activities, add resources

Options for Accelerating Activities - EXAM

• Improving the productivity of existing project resources (team meeting to focus efforts on the most important aspect of a task. Review best practice how to do the task.)

• Changing the working method employed for the activity, usually by altering the technology and types of resources employed (Change from drawing review to CAD model review)

• Increasing the quantity of project resources, including personnel, plant, and equipment (OT, extra shifts, expedite freight, ...)

Time-Cost Trade offs for Crashing Activities

• 1. The cost-time relationship is linear

• 2. Normal time assumes low-cost, efficient methods to complete the activity

• 3. Crash time represents a limit - the greatest time reduction possible under realistic conditions

• 4. Slope represents cost per unit of time

• 5. All accelerations must occur within the normal and crash times

lecture 5

Earned Value Analysis

• Earned Value Analysis is a point in time technique used for tracking project progress thus far.  It is also a great tool for predicting the performance of the project moving forward.

• Two ways on track: budget and time/schedule

• NO EVA CALCULATIONS ON EXAM

• Fundamentally the concept is simple.  " What have we spent so far, and what are the value of goods and services we have received in return so far"?

• Usually it is very simple for the project manager to calculate this.  He adds up his purchase orders to vendors + his expenses.  These are his actual costs.  He compares them to what he received in return.  This is his earned value.

• Your first instinct upon reading that last note should be " But the project manager should always get exactly what he pays for!!"  Yes that is true, but what he gets does not always solve the problem it was intended to solve or to the degree that was desired.  So, some estimating of earned value is usually required.  It is generally done by estimating the percent complete for each individual work breakdown package and summing it up vs. expectations.

• EVA is generally tracked for senior management in large corporations by the project management office (PMO).

CPI - Cost Performanc Index and SPI - Scheduling

• CPI and SPI greater than 1 is good.  Less than 1 means the project is either tracking over budget or tracking late. - EXAM

• 1 is on track, over 1 is under budget CPI and ahead of schedule SPI

• CV, SV, and VAC being positive is good.  This means the project is either being delivered ahead of schedule or under budget

Application of E.V. to a Task

• Method 1 – As applied earlier in the discussion.  Percentage complete is multiplied by value of the task to determine the earned value thus far. Classic example:  Expansion of a data base

• Method 2 – There is no earned value until the task is complete.  The only two levels of earned value ever applied to a task are $0 or the full value of the activity. Classic example: Creation of a software sub- routine

• Method 3 – The 50%-50% method.  50% of the value of an activity is assumed earned at the outset of the activity, and 50% of an activity is assumed earned at the completion of an activity.  The advantage here is that method 1 is so tough to predict near the back end of an activity. Classic example: Purchase and installation of  a new server

• All methods are valid.  You can even use a mix in your project so long as you clearly state you are doing so.  Watch for this wrinkle on your tests!

Determining Task Completion, Deliverable Properties

• The project manager must be able to assess task completion for all past, current, and future project tasks. To this end, project tasks must have a number of properties which enable this form of control.

• Deliverable Properties - EXAM: In the definition of a deliverable, all the standards and the building processes that apply should be identified clearly. With such information in hand, the project manager can verify completion accurately. For example, one can imagine a programming task defined by the following elements:

1. Formal Specifications: They define the functionality of the program to be written.

2. Design Process: This could be a pointer to where the design process is for this deliverable.

3. Coding Standards: The standards specifying the coding conventions and style.

4. Documentation Standards: The standards describing the required documentation, internal and external, to be produced with the deliverable.

5. Quality Standards: Standards describing the quality items required to be present in the deliverable.

Test Data Sets: The test data that the deliverable must execute without error.

Sunk Costs - EXAM

• Sunk costs are non-recoverable costs a project has spent at any time in the project up to the point of its completion.

• With extremely unsuccessful projects, the temptation is often taken that sunk costs should be considered when additional funding is being considered to fix an unfinished project that requires new funding. Sunk costs should never be considered in establishing future budgets. They have no bearing on future earned value, planned value, or actual cost once a new baseline is established.

lecture 6

How is risk defined?

• Definition of Risk: “Any event that can negatively affect the viability of a project.”

• Positive side is opportunities, but management talking about negative size

• Not possible to eliminate all risk 

• Risk comes in many sizes and shapes. The idea about risk management is to minimize the impact of the negative event. In order to do that the project team has to follow these steps:

• identify the possibility for a risk event

• rate the probability and impact of this event

• find solutions to deal with this event

• Risk Management

  • Risk Management has to deal with these events throughout the life of a project. 

  • Identifying risk throughout, upfront for potential, but always risk

  • The goal is to minimize the exposure of the company to the unpleasant outcome of the risk event

  • Risk can happen at any stage and in any form. The difference between successful projects and those that fail lies in the preparedness of the team to deal with risk events. It is not a case of one project having risk while the next one doesn't.

Project Risk is Based on this Simple Equation  - EXAM

• the common thinking: Risk = Probability of event x impact of event

• So any risk events have to be evaluated in two terms. The likelihood for the event to happen (usually in Percent)  and the impact the event will have ($, time delay).

• Since we are technical people though, it is typically also expected that we are analyzing the “detectability” of any risk we are managing.

• A better way to look at risk:

• Risk = Probability of event  x  impact of event  x  detectability

PFMEA – Process Failure Mode Effects and Analysis

• A PFMEA (or DFMEA when the analysis relates to a Design) is an elegant way to quantitatively rank risk concerns, thus allowing a business team to ensure they are spending their time dealing with the most significant risks to the project. 

• Take severity x occurrence x detection, come up with factor, higher number that we should identify recommended actions

Risk and the Spend Curve

Note that the highest risk likelihood is during the early phases of execution. As time goes on the financial exposure per risk of the company is increasing due to the increase in resources and money spent on the project. On the other hand during the early planning stages the financial exposure to per risk is still low due to the minimum man hours and resources spent. During this time management and the team can usually live with a higher level of uncertainty. However expectations are that during the implementation phase the risk likelihood reduces and the "Total" of risk times likelihood is expected to be fairly low. This is true since during this phase the basic questions like "Will the design work?", "Will the customer like the result?" "Will the manufacturing concept we chose work?" are being answered.

Risk Management - EXAM (4 stages)

• 1)Risk Identification

• The process of determining the specific risk factors that can reasonably be expected to affect your project

• 2)Analysis of the probability and consequences

• The potential impact of these risk factors, determined by how likely they are to occur and the effect they would have the project if they did occur.

• 3)Risk mitigation strategies

• Steps taken to minimize the potential impact of those risk factors deemed sufficiently threatening to the project.

• 4)Control and Documentation

• Creating a knowledge base for current and future projects based on the lessons learned.  Risk documentation is said to be “living” documentation on a project.  It requires ongoing updating.

1) Risk Identification - EXAM

• Starts by classifying the risk into one of the following classes of risk: financial, technology, resources, time (contractual, execution risk, …)

• This list offers a common (but not complete) list of risks any project typically phases:

  • absenteeism

  • staff re-assignment by management

  • resignation

  • tasks take longer than anticipated

  • initial specifications are not as well written as expected

  • changes to the project have a bigger effect than expected

• Typical Risk Factors

1. FINANCIAL RISKS

2. TECHNICAL RISKS

3. COMMERCIAL RISKS

4. EXECUTION RISKS

5. CONTRACTUAL OR LEGAL RISKS

2) Analysis of Probability and Consequences - EXAM

• The next step is to assign a reasonable value to the likelihood and consequence the risk has.

• There are two ways to do it:

• Team assessment

• Quantitative method

• We can construct a risk impact matrix (likelihood on x axis, impact on y, low medium high with high right top).

2a - Quantitative Risk Analysis

• 1) Data Gathering and Representation techniques

• Interviewing to quantify the probability and impact of risks on project objectives. The information gathered depends on the circumstance, but most likely will include the optimistic (low), pessimistic (high), and most likely scenarios for the risk event.

• Probability distributions can be used to represent uncertain events, such as the outcome of a test.

• Expert judgment, experts validate data and techniques

2) Quantitative Risk Analysis and Modeling Techniques

• Sensitivity Analysis helps to determine which risks have the most potential impact on the project. It examines the extent to which the uncertainty of each project element affects the objective being examined when all other uncertain elements are held at their baseline values.

• Expected monetary value analysis (EMV) analysis is a statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen. EMV is calculated by multiplying the value of each possible outcome by its probability of occurrence, and adding them together. This is usually done in a decision tree analysis.

• Decision tree analysis is usually structured using a decision tree diagram that describes a situation under consideration and the implications of each of the available choices and possible scenarios.

• Modeling and Simulation. Here the Monte Carlo technique  is typically used, this iterative process is usually performed by a computer that calculates the outcomes of a set of events with the input of randomized values from a probability distribution function. A probability distribution is calculated.

Decision Tree Analysis Tool

• This tool provides a graphic representation of decisions or options in order to assess the "best" alternative.

• It can be used to derive probabilities of outcomes, however it is most often teamed up with Expected Values to determine $ impacts.

• Recall that… Expected value = risk probability * risk consequences

Risk Matrix

• Red Risk: highest impact potential, a plan has to be worked out in advance of the event from happening to mitigate the effects

• Yellow Risk: usually a team decision if a mitigation strategy has to be in place

• Green Risk: be aware....

3) Risk Mitigation Strategies - EXAM

• The next stage in risk management is the development of effective risk mitigation strategies. There are four possible alternatives a project organization can adopt to address risk:

1. Accept Risk

2. Minimize Risk

3. Share Risk

4. Transfer Risk

5. Contingency Reserve

6. Other strategies

A) Accept Risk

• One option that a project team must always consider is whether the risk is sufficiently strong that any action is warranted. Any number of risks of a relative minor nature may be present at any point in time. However because the likelihood of their occurrence is so small or the consequences of their impact are so minor, they may be judged acceptable and ignored.

• For example the pharmaceutical industry spends billions every year in developing, producing, and promoting new drugs. Knowing full well that less than 5% are likely to receive FDA approval . Hence, a high degree of commercial risk is embedded in the system itself and must be accepted in order to operate in the industry.

• Ex. Repairing Endeavor is too risky, says NASA

  • A small, deep gash in space shuttle Endeavour's heat shield poses no threat to the ship and does not need repair, NASA said on Thursday after studying the problem for nearly a week.

  • NASA officials considered sending astronauts out to patch the 8-centimetre (3-inch) gash in the shuttle's belly, but decided Endeavour was all right and it was better not to interfere with the heat shield, mission management team chairman John Shannon said.

  • "[The hole] does not constitute a risk to the crew, it is not expected to cause any damage to the vehicle structure," he said in a briefing at Johnson Space Center in Houston, Texas, US. "You have something you know you can live with, why would you take the risk of the [spacewalk] to change that?"

  • Greater risk to minimzie than fix

B) Minimize Risk

Strategies to minimize risk are the next option. Consider the Q-400 next gen turboprop airplane built by Bombardier. Each aircraft contains millions of individual parts , most of which must be acquired from vendors. The risk for the plane if one of the parts malfunctions is too great. Therefore most aircraft manufacturers insist that all significant vendors maintain direct contact with the companies quality department. The aircraft companies also insist on interfering with the production process in order to ensure that the resulting quality meets expectations. But because the company cannot manufacture all parts of an aircraft, they seek to minimize risk through supplier selection, quality standards and audits

C) Share Risks

• Risk may be allocated proportionally among multiple members of the project.

• Two of the examples of sharing risk are the research and development done through the European Space Agency (ESA) and the Airbus consortium. Due to the tremendous barriers to entry, no one country in the European Union has the capital  resources and technical skills to undertake the development of the Ariane rocket for satellite delivery or the creation of a new airframe to compete with Boing. ESA and Airbus partners from a number of countries have jointly pooled their resources and at the same time, agreed to jointly share the risk inherent in the venture

D) Transfer Risk

• In some circumstances, when it is impossible to change the nature of the risk, it may be possible to shift the risk to another party.

• For example a good method to prevent excessive budget overruns is a fixed-price-contract. They establish a price upfront, should the project slip, the vendor must carry the full burden of the overrun.

• Alternatively, if the goal is to ensure functionality (quality and performance), the concept of liquidated damages is used. Liquidated damages represent project penalty clauses that kick in at mutually agreed-on points in the development and implementation

E) Use of Contingency Reserves

• Contingency reserves are among the most common methods to mitigate risks. They are defined as the specific provision for unforeseen elements of cost within the defined project scope. In construction projects it is not uncommon to set aside 10-15% of the construction price in a contingency fund. In other fields, however, this practice is not done, due to the fact that the team might fear that the customer or management might see it as a sign of poor planning or inadequate scope definition.

• There are two types of contingencies:

• Task Contingency - is used to offset schedule overruns, budget cuts or other unforeseen circumstances accruing to individual tasks or work packages. These budget reserves are managed by the project manager. Naturally, as the project moves forward, it may be possible to reduce budget reserve requirements for task contingency because of the progression of the work. As a task is completed, the reserve left for that task cannot be accessed anymore.

• Managerial Contingency - is an additional safety buffer applied at the project level. They are used in instances where the customer changes the scope half way through the development process.  "Acts of God", natural disasters or the like are unforeseeable by definition. In these cases Management (not the project manager) has access to this contingency fund

F) Other Mitigation Strategies

• In addition to the above set of mitigation strategies, many organizations adopt a practical approach to minimizing risk through e.g. mentoring new project managers and team members. In a mentoring program, junior or inexperienced personnel is paired with senior/experienced personnel in order to help them learn best practices.

• Another method involves cross-training project team personnel so that they are capable of filling in for each other in the case of an emergency. Cross-training requires that members of the project team learn not only their own duties but also the roles that another team members are expected to perform

Lecture 7

The Project Charter

• One pager beginning of project, contract

• Sometimes known as the Statement of Work (SOW)

• A project charter is the document that gives the specific project manager the authority to proceed with the project.

• A project charter is the document that formally recognizes the existence of a project.

• A project charter provides the goals and objectives of the project.

• Every project must have a project charter to be a project.

• The project charter is the document against which success or failure of the project will be measured.

• Determine budget, timeline, who is the PM?

• EXAM: don’t proceed without conversation/agreement/signature

Characteristics of all Project Charters

• Created by a manager or director who is external to the project and higher in the corporate hierarchy.

• Created during the “defining” or (as in PMBOK) the “initiating” phase of the project.

• Broad enough so that it does not NEED to change as the project changes.

• An output of scope initiation.

• Owned and applied by the project manager if and as necessary post executive approval

Contents of a Project Charter

1. Project Title and Description (What is the project?)

2. Project manager assigned and authority level (Who is given authority to lead the project and to what degree do they have decision making responsibility for cost, resources, and timing – the Triple constraint)

3. Objectives (What Triple constraint numerical criteria will be used to measure project success?)

• Triple constraint: cost/budget, time/schedule, scope, middle = quality

4. Business Case (Why is the project being done?)

5. Product Description and Deliverables (What are the specific deliverables that are wanted and what will be the end result of the project.)

6. Signature noting Approval to Proceed (a person high enough on the organization chart that everyone will indirectly report to).

• You have created the project charter, but could not get it approved.  Your manager and his boss have asked that the project begin immediately.  Which of the following is the BEST thing to do:

1. Set up an integrated change control process

2. Show your manager the impact of proceeding without approval

3. Focus on completing projects that have a signed charter

4. Start work only on the critical path tasks

• Answer:   B   The best thing to do would be to evaluate the impact.   This is the only choice that prevents future problems - always the best choice.  The other choices just pretend the problem does not exist.

Teamwork

• The Co-Located Team

• This team is easiest to deal with, because much of what needs to be done is simply good, sound fundamentals.

• Always be polite, check your ego, and do not micromanage. Let the team feel the freedom of their assigned task.  Hold your team accountable for results as well, but even this interaction can be accomplished politely and professionally…;  Being well liked will help your project results.

• As PM you should in general not exclusively talk shop.  Be friendly, but maintain the dignity of your position.  A few kind words about a colleague’s interests is an excellent ice breaker to almost any interaction.  Then you can proceed on to business.

• Project Teamwork is Evolving

• The traditional concept of team has changed dramatically in recent decades

• And This is the Way it is Heading

• With the explosion of the global economy, mergers, acquisitions, outsourcing, process re-engineering and technology advancement, today's teams have a completely different profile.

• Trust is Key

• Trust is a key factor in building high-performing teams

• The Advantages Presented by Virtual Teams

• Maximizing the 24-hour day is an opportunity that geographically dispersed teams can leverage in certain projects

Performance Reporting for the Finances of the Project

• The most effective and most interesting way to report out the progress of your team is through EVA which we will learn later on in the course. 

• It is important however to know that often management can want more details.  As such if technology permits, and if the document is with me the evening this lecture, I can demonstrate what a more detailed performance report truly looks like.

• I will reinforce this with you many times throughout the course:  Project Managers manage costs – not prices, not profits – COSTS.  That said the reason I mention it now is because so many other financial concepts roll out of costs that you get dragged into them.  Things such as margins, markups, billings, revenue, deviations, etc.  They are all important concepts and will mean something very specific to you one day, but for now remember the PM’s job is to manage COSTS.

Change Management

• Now the team is chosen, we have set out on our tasks, results are coming back very positively, we have even adjusted the play of some of our team and rewarded others.  Fantastic! What could go wrong from here?

• Suddenly the financials are coming back not as rosy and we are overshooting timing as well…..Time to investigate if we are handling change management properly….

• Causes for Changes

• Technical uncertainty

• When the project team learns more about the nature of the deliverable

  • Project scope changes

  • Implementation of contingency plans

  • Improvement changes

• A mandate (government, legal mandate, or company mandate with new boss)

Scope Creep - Definition - EXAM

• Exam - project charter, scope creep

• “Scope Creep in project management refers to uncontrolled changes in a project’s scope.

• Typically, the scope increases by adding both new products and new features of already approved products. As a result, the project drifts away from its original purpose. Because of the tendency to look at only one dimension of a project, scope creep can also result in a project overrunning its original budget and schedule, as more is to be done at the same cost and in the same time (which is usually unrealistic, given a stretched original budget and schedule).

• Scope creep can be a result of: - EXAM

• poor change control

• lack of proper identification what products and features are required to bring about the achievement of project objectives in the first place.

• weak project manager or executive sponsor"

Factors Having the Maximum Impact on Project Productivity

• People

1. Low staff experience or skill

2. Low staff morale

3. Low availability/ experience of supervisors

4. Overtime staff fatigue

• Work

1. Poor clarity/incomplete requirements/ specifications

2. Work-scope changes generated externally to project

3. Work-scope changes generated internally to  project

Five Principles of a Formal Change Program

• All contracts specify formal change process (don’t wait for change, have process up front)

• All changes require formal change order

• All change orders approved in writing by client and project organization

• Project manager is always consulted

• The approved change order becomes part of the master plan

The Change Control Process

Step 1: A Practical Approach

• is this a problem? whose problem, a problem is uncovered

Step 2: A Practical Approach

• characteristics of problem, maybe obvious solution/responsibility

Step 3: A Practical Approach

• alternatives are proposed

Step 4: A Practical Approach

• If the solution is within the scope, issue an Instruction

• If the solution is not within the scope, determine whether the change in scope is essential or desirable.

Step 5: A Practical Approach

• If the solution is desirable, issue a Contemplated Change Request

• If the solution is essential, issue a Change Directive

Step 6: A Practical Approach

• if change is desirable enhancing succes: quote for cost and accept or not

• if change is essential: work begins, quote, quote accepted

Step 7: A Practical Approach

• quote accepted, change order prepared and issued, amount and schedule of contract modified

lecture 8