# Presentation: 943348

##    LBNL Project Management Overview

**LBNL**
**Project Management:**
**Project Realities**

**February 2003**

## Objectives

- Reinforce the use of project management terms consistent with their approved definitions
- Provide guidance for project conduct and participation
- Enable participants to contribute to project success
- Provide additional references about project management

- This module will:

## Agenda

**Project Team Formation**
**Project Planning**
**Change Management**
**Progress Reporting**
**Reviews – Product and Project**
**Risk Assessment and Management**
**Communication**
**Problem Management**
**Recommended Reading**

## A.  Introduction to Project Management

**A.  Introduction to Project Management**

## Project Team Formation

**Clear goals and objectives**
- Overall understanding of team’s role in project, its responsibilities and what it needs to accomplish
- Involve all team members in defining the goals
- Clarify roles, decisions and responsibilities
**Understanding of interdependence**
- If everyone does their “own thing,” no real team exists
- Most deliverables influence other people’s deliverables

**Attributes of an effective project team:**

## Project Team Formation

**Cohesiveness**
- Depends on number of personal needs each member can satisfy by belonging to the team
- Increases as team’s ability to meet individual needs increases
**Level of trust**
- Build working relationships that are characterized by openness and trust
- Openly recognize conflict and resolve it through discussion
**Potency**
- Belief that team can achieve goal of the project
- Reward early successes of project team

**Attributes of an effective project team:**

## Project Team Formation

**Directing**
- Organize and direct work of others
- Make each person accountable for specific deliverables
- Motivate by demonstrating what needs to be done
**Supporting**
- Set high but realistic standards of performance
- Explain what needs to be done
- Motivate by giving feedback
- Be personally involved

**Leadership Styles:**

## Project Team Formation

**Coaching**
- Recognize and praise good work
- Be open and supportive
- Motivate by letting others structure their own work
**Delegating**
- Assign task responsibilities and let others carry them out
- Motivate by giving control and showing respect
- Limit personal involvement in deliverables

**Leadership Styles:**

## Project Team Formation

**Forming**
**Storming**
**Norming**
**Performing**
**Mourning**

**Five Stages of Team Development:**

## Project Team Formation

**Members come together as set of individuals, not yet a group**
**Members try to make sense out what they are supposed to do**
**Members learn acceptable interpersonal behaviors**
**Members look for directing leadership**

**Forming**

## Project Team Formation

**Members are more comfortable with each other and begin to understand the project goal**
- Members decide whether they like project and how committed they will be to do it
**Original agreements are challenged as group struggles to agree on objectives and strategy**
- Personal agendas may be revealed, generating certain amount of interpersonal hostility
**Members look for supporting leadership**

**Storming**

## Project Team Formation

**Members settle into project behaviors and are comfortable with the level of commitment**
**Members come to consensus on norms and practices**
**Members look for coaching leadership**

**Norming**

## Project Team Formation

**Final solution or decision emerges; implementation proceeds smoothly**
**Each member has a role and is comfortable with it**
**Members look for delegating leadership**

**Performing**

## Project Team Formation

**Members complete project and prepare for break up of the team**
**Members falter as patterns must change to complete final details and finishing touches**
**Members drift from team roles and sense of cohesion**
**Members look for supportive leadership**

**Mourning**

## B.  Project Planning

**A.  Introduction to Project Management**

## Project Planning – Key Steps

**Adopt the right organization structure**
-  With clear accountability and procedures (rules)
**Match the right people with the right job**
-  No system is better than the people who implement it
**Allow adequate time and effort for planning**
-  Use _Work Breakdown_ and _Dependency Network Planning_ that clearly defines  who will do what, for how much, and when
**Ensure that deliverable packages are properly sized**
-  Must be manageable, have organizational accountability
-  Must be realistic-in terms of effort, time and money

**Implementing a Project Management System:**

## Project Planning – Key Steps

**Work at ensuring realistic information flow (communication)**
-  Accurate information is required for management
-  Poor communication causes many project difficulties
**Establish and use **_**Integrated Planning and Control Systems**_** as a focal point for implementation of the project**
-  Know where you are going
-  How you are getting there
-  When you have arrived

**Implementing a Project Management System:**

## Project Planning – Key Steps

**Be willing to re-plan**
-  The best laid plans go astray; change is inevitable
**Long before the end of the project, plan for the end**
-  Plans must be developed for:
- Personnel
- Other resources
- Transfer of knowledge

**Implementing a Project Management System:**

## Project Planning

**Integrated Performance Measurement:**
**It is a continuing process throughout the life cycle of the project**
**It should not be an occasional panic exercise triggered by sudden awareness of a crisis**
**Regular feedback is the only way of keeping the project on track**

## Project Planning

**Integrated Performance Measurement:**
**Provide visibility for the integrated plan and performance standards**
**Identify significant problems before they occur, to the extent possible, so they can be avoided or their effects minimized**
**Identify opportunities for schedule acceleration, cost reduction, or technical improvement, and exploit them before the opportunity is lost**

## Project Planning

**Integrated Performance Measurement:**
**Facilitate the comparison of actual performance to the predetermined plans and standards, at successively lower levels within the organization**
**Identify significant deviations from the plan**
**Assure corrective action when needed by promoting the analysis of significant deviations**

## Project Planning

**Integrated Performance Measurement:**
**Determine value earned (what are you getting for money and time allocated)**
**Provide feedback to management and/or the customer and the performers of the work**

## Project Planning

**Purpose of Project Planning:**
**Clarify project objectives and expectations**
**Serve as a basis for negotiating commitments**
**Record commitments for everyone’s information**
**Help identify the optimal assignment of people and resources**

## Project Planning

**Purpose of Project Planning:**
**Provide a **_**baseline**_*** against which actual performance can be compared**
**Facilitate the early identification of potential problems**
**Make people aware of project deliverables**
**  ****	***** *****Baseline ****is the word used in projects to describe the original estimates of cost, schedule and performance*

## Project Planning

**The project planning process includes:**
** **Setting objectives
-  Deciding the overall program or strategy to be followed
-  Developing the schedule
-  Estimating resource requirements (includes $ and people)
-  Forecasting the future project environment
-  Developing the project organization
-  Preparing required operating policies and procedures
-  Developing standards for performance

## Project Planning

**Why people fail to plan:**
** ****Don’t appreciate what planning will help them accomplish**** **
** ****Don’t realize the potential consequences of not planning**** **
** ****Don’t know how**** **
** ****Don’t have the right people**** **
** ****Don’t have time**** **
** ****Don’t equate planning with “real” work**
** ****FEAR**

## Project Planning

**It is not possible to successfully complete a relatively simple project without planning**
**Project planning uses a set of techniques that every manager should understand and apply**
-  You want to be the first to know if trouble is on the horizon
-  You do not want other stakeholders to find out first

## Project Planning

- Reference to Project Charter
- Acceptance criteria for deliverables
- Performance standards
- Schedule of deliverables and milestones

- Resource requirements for
- People
- Funds
- Equipment
- Facilities
- Information
- Project organization
- Relevant policies and procedures

**The total Project Plan should contain:**

## Project Planning

**Work Breakdown Structure (WBS):**
**The WBS is a framework for identifying and displaying all deliverables the team must perform in order to complete the project.**
**It includes the breaking out of project work into increasingly smaller pieces called **_**Work Components**_** which:**
- Are more precisely defined
- Require smaller amounts of time and resources to complete
- Usually consist of sets of deliverables

## Project Planning

**Work Breakdown Structure (WBS):**
**Estimating resources for a number of small, well-defined deliverables is easier than estimating a complex work component**
- Each deliverable estimate is evaluated by someone very knowledgeable in the associated deliverables
- The person responsible for the deliverable “owns” the estimate
- Total estimate based on summary of pieces is more credible

## Project Planning

**Developing the Dependency Network:**
**Select the group of deliverables which will be included in the project network diagram**
- All, or some sub-section, of the deliverables from the WBS
**Assign a number to each deliverable and consider each in turn**
- WBS number is easiest, but it can be ordinal numbers
**Mark each deliverable on a Post-it******** note**
- Record ID number / Name
- Time estimate to complete deliverable
- Resources required for deliverable (people, facilities, etc.)

## Project Planning

**Developing the Dependency Network:**
**For each deliverable, ask:**
- Which deliverable(s) must be completed **immediately** before this deliverable can be started (this may change)?
**Record milestones on Post-it******** notes in a fashion that distinguishes them from deliverables**
**If useful, conduct affinity analysis**

## Project Planning

**Developing the Dependency Network:**
**Determine the order of precedence among deliverables / milestones as follows:**
- Find those that have no immediate predecessors; these will be your starting deliverables
- It is best to make a single milestone the *Start *– or *kickoff*
- Next, identify the deliverable(s) which have these initial deliverables as their _immediate_ predecessors; these will be the next deliverables to be scheduled
- Connect deliverable/milestone dependencies
- Finish/Start
- Start/Start (usually with lag)
- Avoid Start/Finish and Finish/Finish (distorted logic)
- Continue until all deliverables have been arranged in the diagram

## Project Planning

**Example Dependency Network:**

## Project Planning

**Developing the Dependency Network:**
**Find the critical path – the sequence of operations that determine the shortest time the project can be completed (without regard to resources or availability)**
**This critical path is the infinite resources critical path.  **
**Record results for further analysis ****(resource allocation and schedule management)**
**If critical path changes, delivery date changes; communicate immediately**

## Project Planning

| Deliverable/Milestone | ID | Duration | Resource | Predecessor |
| --- | --- | --- | --- | --- |
| Start milestone | S | 0 | - | - |
| Deliverable 1 | 1 | 5 | A | S |
| Deliverable 2 | 2 | 2 | B | S |
| Deliverable 3 | 3 | 6 | C | 2 |
| Deliverable 4 | 4 | 3 | A | S |
| Deliverable 5 | 5 | 1 | C | J |
| Deliverable 6 | 6 | 4 | D | 4 |
| Deliverable 7 | 7 | 2 | B | 3,5,6 |
| Inner Milestone | J | 0 | - | 1,4 |
| End milestone | E | 0 | - | 7 |

**Dependency Network Development Worksheet**

## Project Planning

**Improving the quality of the project schedule:**
**The overall quality of the final project schedule depends heavily upon the accuracy of the estimates of individual span times developed for each individual deliverable**
**The accuracy of the these estimates can be improved if:**
- The deliverables for which estimates of span time are developed are defined in sufficient detail to minimize complexity and uncertainties
- Span time estimates are developed by, or in consultation with, those people have the most knowledge and/or experience with each deliverable

## Project Planning

**Improving the quality of the project schedule:**
**When estimating span times:**
- First estimate the actual deliverable time
- The amount of time it would take one person working full time on the deliverable to complete it
- Then extend this estimate by the external constraints affecting the deliverable in order to arrive at an estimate of span time

## Project Planning

**Displaying the project schedule:**
**The network diagram is useful to support the analysis of the project.**
**The final schedule is more commonly displayed in one or more of the following formats:**
- _Key Events Scheduler_ – a tabular listing of project milestones
- _Deliverables Plan_ (project “to do”list) – a tabular listing of project deliverables to be completed
- _Milestone Chart_ – a graphical representation of project milestones
- _Bar (Gantt) Chart_ – a graphical representation of project deliverables to be created

## Project Planning

**Displaying the project schedule:**
**While each of the formats presents the schedule information in an easy-to-read format, none of them depicts deliverable inter-relationships gracefully.**

## Project Planning

**Bar or Gantt Chart**

## Project Planning

**Uncertainty increases with time**
**The work done in the initial phases predicts the ultimate schedule**
**Detailed plans, schedules, estimates, are only of value through the next few phases**
**Ultimate goal is generally understood, and may be refined as the project progresses**
***Don’t Drive Beyond the Headlights***

## Project Planning

**Bar or Gantt Chart:**
**The Bar or Gantt Chart may be modified to represent earliest and latest start times, slack times, and deliverable interdependencies**
**These charts are useful for displaying the project schedule to other audiences **
***The dependency network is one of the most useful tools for project planning.***

## Project Planning

**NO!**

**Do you detail plan the whole thing?**

## C.  Change Management

**A.  Introduction to Project Management**

## Change Management

**Issues and Change Relationship**
**Issues Categorization**
**Issues Log**
**Issues Severity**
**Issues Audit Trail **
**What is Change Management?**
**Cost of Change**
**Change Log**
**Change Management Process**
**Change Management Plan**

## Issues and Change Relationship

**Change Management**

## Change Management

**Issues Categorization**

## Change Management

**Issues log**
**Simple rule –> **
**When an issue comes up, **
***	******Just Log It***
**Single source for the project**

## Change Management

**Issue**
- Action Item
- Action Item
- Action Item
**Issues can spawn multiple action items to get them resolved**
**Do you keep a separate log of Action Items? **

**Structure of an issue:**

## Change Management

- Issue id
- Title
- Author
- Date discovered
- Description
- Priority
- Severity
- Complexity

**Examples of Log Data:**

- Type of issue
- Person assigned to issue
- Date person was assigned
- Description of resolution
- Person who resolved issue
- Date resolved

## Change Management

**Managing Issues**
**A database tool would be ideal**
**Use Excel until it’s implemented**

## Change Management

**Issues Severity:**
**Green****	**- annoyance, cosmetic	** ****	**
**Yellow ****	**- will become very painful (red) if not attended 		  to eventually
**Red ****	**- show-stopper

**From perspective of:**
-  Project Sponsor
-  Project Director
-  Project Manager
-  Other Stakeholders

## Change Management

**Issues Audit Trail**
**Entering the resolution information in the Issues Log provides a valuable audit trail, no matter how winding the path may be**

## Change Management

**What is change management?**
**A set of *****FORMAL***** ****procedures that provide for the *****ORDERLY***** management of change in a dynamic environment**
**It is not a plan to prohibit or inhibit change**

## Change Management

**Examples of Change:**
**Added function**
**Incorrect assumption**
**Imposed delays**
**New standards / ways**
**Environment alterations**
**Extended approval times**
**Etc.**

## Change Management

**Issues Log**
**Worth doing**
**Steering Committee and Project Directors are interested in it**
**Not hallway conversation topic**

## Change Management - Process

**Change Management - Process**

- Request
- Submitted

- Estimate
- To Assess
- Impact

- Proposed
- To Project
-  Manager

- Approved?

- Feedback
- To
- Requestor

- No

- Assess
- Impact

- Estimate
- To
- Implement

- Proposed
- To Project
-  Manager

- Approved?

**Feedback**
**To**
**Requestor**

- No

- Yes

- Large?

- Yes

- Escalate
- to Project
- Director

- Yes

- Implement
- Change

**Feedback**
**To**
**Requestor**

- No

- Etc.

## Change Management

**Change Management Plan**
**States who is going to do what, when, where and how**
**Provides basis for work that follows product development**
-  Know what you did

***Lays the groundwork for: ******Integrity, Repeatability, Traceability***

## Change Management

**Change Management Plan Contents**
**Introduction**
- Describes the plan’s purpose, scope of application, key terms and references; e.g., it lays the foundation for what’s to come. Sets expectations, etc.
**Organization**
-  Participants and responsibilities

## Change Management

**Change Management Plan Contents ****cont.**
**Change Management Process**
- Process diagram
- Describe process steps
**Change Management Tool**
- Describe software tool(s) to be used, it any
**Checklists and templates as needed**
- Change Request Form
- Etc.

## D.  Progress Reporting

**A.  Introduction to Project Management**

## Progress Reporting

**Linkage between Tracking and Status Reporting**
**Collecting Tracking Data**
**Status Reporting**

## 					- Fred Brooks

**One day at a time.**
- 					*- Fred Brooks*

**Progress Reporting**

## Tracking
Collecting Data
State of Deliverables, Time, Cost
Analyzing Data

Status Reporting
Telling Stakeholders results of Analysis
Proposing Options to Improve Project
(aka Corrective Action)

- Collecting Data
- State of Deliverables, Time, Cost
- Analyzing Data
**Status Reporting**
- Telling Stakeholders results of Analysis
- Proposing Options to Improve Project
- (aka Corrective Action)

**Progress Reporting**

## Collecting Project Status Data

**What**
**When**
**Why**
**Where and How**
**Who**

**Progress Reporting**

## What

**State of Deliverables**
- Progress
- Issues
**Time**
- Resource Hours Spent
- Estimate to Complete*
**Cost**
- Spent via Purchase
- Spent via Resource Time

**What**

## When

**Weekly**
**Ever need it more frequently?**
- Maybe; near phase-end or near Go Live

**When**

## Why

**With deliverables < 25 hours**
- You know your status every week

**Why**

## Where

**Written status report**
**Weekly status meeting**
**If needed, daily face time**

**Where**
**&**
**How**

## Who

**Project Manager**
**Project Administrator**

**Who**

## Progress Reporting

**Communications focal point for project so specialists can stay tuned in to their work**
**Provides consistent and efficient administration of the project **
** **Minute-taking and producing reports
-  Updating and displaying project schedules
-  Building productive working relationships
-  Liaising with clients and Project Manager** **

**Project Administrator:**

## Progress Reporting

**Submitting time data to project management software can be time-consuming**
**Working on multiple projects**
** **
-  Clients
-  DBA’s, etc.

**Data Collection Challenges:**

## Collect Black & White Deliverable Status with 3 Factoids:

**??  % Complete ??**

**Progress Reporting**

## EffectiveProgressTracking

**Progress Reporting**

**Notes:**
Have you ever noticed how quickly a project gets to be 90% complete and how  long that final 10%  seems to take??  So often, we base project progress on the passage of time rather than the completion of project deliverables. 
Progress is based on the completion of project products or deliverables, not by the usage of time spent on the project.
A detailed plan enables us to schedule exactly who will be producing a project deliverable and when.
What is needed is a control which will track progress by completion of deliverable.

## Progress Reporting

**Everyone Wants Status – *****Just Different Information***

**Progress Reporting**

**Important Stakeholders**

**Peripheral Stakeholders**

## Project Assumptions:

Everyone wants success

Everyone wants to know what they can do

Everyone wants to know quickly

Executives want to solve problems

and they will drill down to get details when they need them...

**Everyone wants success**
**Everyone wants to know what they can do**
**Everyone wants to know quickly**
**Executives want to solve problems**
- and they will drill down to get details when they need them...

**Progress Reporting**

## Status Reporting:

**Many projects throughout LBNL**
**We all want to know, *****AT A GLANCE*****, what the status is**
**We want MBE (Management By Exception)**

**Progress Reporting**

## Overall Project Status at LBNL

**Green**
**Yellow**
**Red**
**Three characteristics**
- State of Deliverables
- Time
- Cost

**Progress Reporting**

## Progress Reporting - Example

**Progress Reporting - Example**

## Progress Reporting - Example

**Progress Reporting - Example**

## Analyzing collected data to report status

**State of Deliverables**
**Time**
**Cost**

**Progress Reporting**

## What does PMI* recommend you track?

**Quality**
**Scope**
**Risks**
**Schedules**
**Costs**
**Procurement**
**	**

**Using**
- Variance Analysis
- Trend Analysis
- Earned Value Analysis

**Progress Reporting**

**** Project Management Institute (PMI)***

## Analyzing collected data – Map to PMI

**State of Deliverables**
- Progress
- Issues
**Time**
- Resource Hours Spent
- Estimate to Complete*
**Cost**
- Spent via Purchase
- Spent via Resource Time

**Quality**
**Scope**
**Risks**
**Schedules**
**Costs**
**Procurement**
**	**

**Progress Reporting**

## Analyzing data for State of Deliverables:

**Progress**
- Green 	- Done and accepted
-             	     -or-
- Green 	- On track
- Yellow	- Might miss
- Red		- Will miss
**Drilldowns**
- Change controls	- Scope
- Issues                 	- State of Deliverables
- Schedule             	- Time

**Progress Reporting**

## Issues
 Number of Red
 Number of Yellow
 Number of Green

Drilldowns
	Trend Analysis = Will they be finished on time?

** ****Number of Red**
** ****Number of Yellow**
** ****Number of Green**
**Drilldowns**
**	****Trend Analysis = *****Will they be finished on time?***

**Progress Reporting**

**Analyzing data for State of Deliverables:**

## Progress Reporting

**  ****Green****	**- on target
**  ****Yellow****	**- % high or low
**  ****Red****	****	**- % high or low
**Drilldowns**
**	****Variance Analysis**
**	****Trended Analysis**

**Progress Reporting**

**Analyzing data for Time:**

***Beware the simplistic % complete trap from project management software.***

## Deliverable Starts vs. Completes

- Example of how trend analysis might look

**Progress Reporting**

- No. of Deliverables

## Progress Reporting

**  ****Green****	**- on target
**  ****Yellow****	**- in trouble
**  ****Red****	****	**- not a chance
**Drilldowns**
**	****Variance Analysis**
**	****Trended Analysis**

**Progress Reporting**

**Analyzing data for Time:**

***Not from project management software – from status reports***

## Progress Reporting

**  ****Green****	**- on budget
**  ****Yellow****	**- % over/under budget
**  ****Red****	****	**- % over/under budget
**Drilldowns**
**	****Variance Analysis**
**	****Trended Analysis**

**Progress Reporting**

**Analyzing data for Cost:**

## E.  Reviews – Product and Project

**A.  Introduction to Project Management**

## Reviews – Product and Project

**Is the product OK?**

**Is the project OK?**

**Quality Assessment**

**Project Reviews**

- Design Review

- Test Review

- Internal Audit

- ISS Project Review

**Project Retrospective**

## Reviews – Product

**Candidates for Review**

**Reviews – Product**

## Quality Assessment:

**Rigorous Reviews**
- Essence models
- Design specs
- Prototype & corresponding documentation

**Test Reviews**
- Approach
- Completeness
- Issues raised and resolutions

**Reviews – Product**

## Quantitative?
Usually covered by status reports

Qualitative
Usually Checklist-based
Other items to review:
Perceptions
Acceptance
Cooperation
Choices

- Usually covered by status reports
**Qualitative**
- Usually Checklist-based
- Other items to review:
- Perceptions
- Acceptance
- Cooperation
- Choices

**Reviews – Project**

## Project Retrospectives:

**After the dust settles:**
** ****Re-create the history of the project**
- Use artifacts to reconstruct the experience
- Use stories to reconstruct the feelings
** ****Acknowledge**
- What we did that really worked
- What we might do differently next time
** ****Learn**
- Lessons Learned become part of organization’s revised Best Practices

**Reviews – Project**

## F.  Risk Assessment and Management

**A.  Introduction to Project Management**

## Risk Assessment and Management

**Risk Factors**
**Risk Assessment**
**Risk Management**

## Risk Assessment and Management

**Risk “implies a voluntary taking of doubtful or adverse chances”; “exposure to loss, disadvantage or destruction”**
**                         ***- **Webster’s International Dictionary Unabridged*
***Risk is about the possibility of failure......***

## Project size
Number of physical sites
Lack of team dedication
Stringent quality vector
Schedule rigidity
Lack of sponsor commitment/support
System effect on business operations
Size/diversity of user community
Incomplete communication
Expectations are not realistic

**Number of physical sites**
**Lack of team dedication**
**Stringent quality vector**
**Schedule rigidity**
**Lack of sponsor commitment/support**
**System effect on business operations**
**Size/diversity of user community**
**Incomplete communication**
**Expectations are not realistic**

**Risk Assessment and Management**

**Risk Factors:**

## Risk Assessment and Management

**Lack of team’s control of critical elements**
**Hardware/software complexity, availability, integration**
**Experience level of all participants**
**Lack of dedication of funding**
**Constrained project work locations**
**Misperceptions/hidden agendas**
**Lack of availability of decision makers**
**Duration**
**Lack of participant commitment**

**Risk Assessment and Management**

**Risk Factors:**

## Risk Assessment and Management

**Risk assessment is the active investigation of the risk factors to predict:**
**  **Likelihood of causing difficulty
-   Severity of that difficulty
**If likelihood/severity are high:**
-  Mitigation Planning offers a reduction of likely failure and/or a way to reduce the detrimental effects

## Risk Assessment and Management

**Processes required to systematically identify, analyze, and respond to project risks:**
**Risk Management Planning**
**Risk Identification**
**Qualitative Risk Analysis**
**Quantitative Risk Analysis**
**Risk Response Planning**
**Risk Monitoring & Control**

## Risk Assessment and Management

**Risk Management Protocol:**
** ****Reactively    **– managing surprises, “putting out fires”
** ****Proactively   **– risk avoidance, “buy off” risk
**  ****Assessing failure factors**
**  ****Creating mitigation plans**
**  ****Securing agreement to proceed anyway**
**           ****– ****or –**
**  ****Pulling the plug prudently**

## G.  Communication

**A.  Introduction to Project Management**

## Communication

**Effective Listening**
**Congruence**
**Empathy**
**Agreements**

## Communication

**Use attentive body language**
**Use thinking speed constructively**
**Maintain silence / observe**
**Avoid prejudice**
**Avoid jumping to conclusions**
**Be an active listener**
**Additional listening skills**

**Skills for Effective Listening:**

## Communication

**Congruence is an important factor**
**Two perspectives:**
-   Internally
-  When feelings, thoughts and words are all on the same wavelength
-   Externally
-  When interacting with others, keeping a balance among these:

*- From Virginia Satir*

## Communication

**At the heart of congruence is self-esteem**.

## Communication

**BLAMING**
- “I am everything; you are nothing”.
-  Criticize
-  Boast
-  .... who needs friends anyway...

**PLACATING**
- “You are everything; I am nothing”.
-  Apologize
-  Grovel
-  .... who deserves friends anyway...

**Types of Incongruence:**

***SELF***

***CONTEXT***

***OTHER***

***SELF***
** *****ESTEEM***

***SELF***

***CONTEXT***

***OTHER***

***SELF***
** *****ESTEEM***

***XXXXX***

***XXXX***

## Communication

**SUPER-REASONABLE**
- “It is everything; you and I are nothing”.
-  Explain
-  Ignore practicality
-  .... friends aren’t important anyway...

**IRRELEVANT**
- “Nothing counts for anything”.
-  Chatter; squirm
-  Interrupt
-  ....  huh? ...

**Types of Incongruence:**

***SELF***

***CONTEXT***

***OTHER***

***SELF***
** *****ESTEEM***

***SELF***

***CONTEXT***

***OTHER***

***SELF***
** *****ESTEEM***

***XXXX***

***XXXXX***

***XXXX***

***XXXXXXX***

***XXXXX***

## Communication

**LOVER-HATER:**
- “It is nothing; you and I are everything”.
-  Match movements
-  Speak only to other
-  Anticipate the other
-  ....  who else matters? ....

**Types of Incongruence:**

## Communication

**Congruence:**
-  Every interchange is a creative effort
-  Freedom
-  Personal responsibility
-  Sharing
-  Clarity
-  Realism

## Communication

**“****A respectful understanding of what others are experiencing.” **
**                                                      ****	***- Marshall Rosenberg*
**  ****Advice and reassurance are different from empathy**
**  ****First we need empathy for ourselves**
**  ****Then, we hear the other from their perspective**
**  ****Perhaps use paraphrasing to clarify what you hear **
**  ****Intellectual understanding blocks empathy**

**Empathy**

## Communication

**Empathy**

**Messages that intimidate us are from individuals with needs unmet (appealing to us to contribute to their well being)**
- empathy allows us to hear those needs
**We can then choose whether to respond to requests that stem from those needs**
- after we listen fully
**Always be willing to ask a third party to help if things get stuck**

## Communication

-  **When agreements occur that affect:**
** **plans for the project
-   models/specifications for the project
-   roles/responsibilities
** ****Make sure they are captured in writing, and**
** ****Forwarded to appropriate stakeholders**

**Agreements**

## H.  Problem Management

**A.  Introduction to Project Management**

## Problem Management

**Perception**
**Problem Arenas**
**Problem Resolution**

## Problem Management

**Our typical response**
**Try to change the things we perceive**
- (sometimes we can change the things we desire)

## Problem Management

**Things as Desired**
**      ****(The Plan)**

**Things as Perceived**
**      ****(The Work)**

**A way to look at problems:**** **

## Problem Management

**“****Management by exception”**
** ****is a problem-centric style of communication**

**  ****Early bad news is far more preferable than delayed bad news**
**  ****Make exception reports part of ongoing status reporting**

## Problem Management

**Ideally, problems should be discovered by the person responsible for the system or sub-system**
**Sometimes the person responsible may be scared to bring up the problem and is trying desperately to solve it without involving upper management**
-  Upper management must ensure that information is passed up the chain of command without fear of reprisals

**In Times of Trouble . . .**

## Problem Management

**Sometimes, the person responsible is too close to the day-to-day problems and is unaware of the magnitude of the problem**
- Upper level management needs to keep informed of the work proceeding at lower levels in the project organization
- Integrated performance measurements provide a neutral way of evaluating progress
*“****Trust, but verify”***

**In Times of Trouble . . .**

## Problem Management

**Catastrophic event**
-  Easy to diagnose and organize a response
-  Every manager recognizes the need for resources to be applied to the deliverable which is in trouble
**Project Manager warns of problems meeting the cost, schedule or performance goals**
-  Project Director needs to confirm
- If confirmed, a response is required
- If not confirmed, Project Manager needs reassurances about resources

**Problem Categories:**

## Problem Management

**Project Director suspects problems with deliverable in his area or performance metrics indicate that there are problems**
-  Project Manager needs to confirm
- If confirmed, a response is required
- If not confirmed, Project Director needs reassurances about the deliverable

**Problem Categories:**

## Problem Management

**When problems are identified **_**ACTION MUST BE TAKEN**_
-  Delays will only make matters worse
**Actions may include**
-  Revising the schedule
- Accept the delay as inevitable
-  Re-allocating resources
- Work smarter toward the same goals
-  Revising overall project objectives and/or performance criteria
- Work at same rate towards reduced goals

**Corrective Action:**

## Problem Management

**First consideration should be given to corrective actions which:**
- Are simple
- Will have the smallest impact on overall project progress
**Only if all such actions prove to be inadequate should more serious steps be considered**

**Corrective Action:**

## Problem Management

**When corrective actions are necessary:**
- The impact of such actions on all aspects of the project should be carefully assessed
- Project plans should be revised to reflect the impact of any major changes on overall performance specifications, schedules and resource requirements
- All audiences who will be affected by the changes should receive written copies of the revisions

**Corrective Action:**

## Problem Management

**Special attention should be directed towards monitoring the corrective actions taken to ensure that they do, in fact, successfully resolve the problem(s) identified**

**Corrective Action:**

## Problem Management

**If changes to the approved plan become necessary during the course of the project, be sure to:**
- Thoroughly assess the impact of such changes on _all_ aspects of the project
- Make such changes in writing
- Obtain all necessary sign-offs and approvals of the revised plan
- Share the new plan or plan amendments with all audiences, being sure to emphasize how the changes will affect them

**Making Changes to an Approved Plan:**

## Problem Management

**Do not ignore funding agencies, government officials**
- They will normally be nervous of changes they do not understand
- External review committees can help make changes more acceptable

**Making Changes to an Approved Plan:**

## Problem Management

**Changing the Schedule**

**Evaluate the deliverable in trouble:**
- Is the deliverable on the critical path?
- Can more resources be applied to the deliverable?
- Look at resource loading graphs
- Can the deliverable be delayed?
- If the deliverable is delayed, does this affect resource allocation?
- Look at resource loading graphs

## Problem Management

**Changing the Schedule**

**Evaluate each deliverable following the deliverable in trouble:**
- Is the deliverable on the critical path?
- Can more resources be applied to the deliverable?
- Look at resource loading graphs
- Can the deliverable be delayed?
- If the deliverable is delayed, does this affect resource allocation?
- Look at resource loading graphs

## Problem Management

**Changing the Schedule**

**If resource loading is a problem:**
** **
- Can additional people be found?
- Temporary/transfer work
- Can additional equipment, material, facilities be found?

## Problem Management

**In general, changing the schedule changes the resources**
- Presumably, the resource loading was already optimized
**The general philosophy of most projects is to try and limit the schedule changes to the fewest number of deliverables**
- Focus more resources on the deliverable in trouble
- Try and add resources that are not already committed to other deliverables
- If deliverable is being performed in the Lab, assign part of deliverable to a vendor
- If deliverable is being performed by a vendor, assign part of deliverable to the Lab

**Re-allocating Resources:**

## Problem Management

- If deliverable is being performed by a vendor, assign part of the deliverable to another vendor
- This is the reason why deliverables with a high risk factor are often split initially between two vendors to maximize the options later
**The original contracts must be carefully written with measurable performance goals and non-performance clauses**

**Re-allocating Resources:**

## Problem Management

**Evaluate the deliverable in trouble and the deliverables following it to modify the way in which the work is broken down**
- Use “brainstorming” with a small group of knowledgeable people to come up with as many alternate ideas as possible
- One of them may save you
- Transfer work from oversubscribed resources and assign it to free (or less occupied) resources
- Re-examine political limitations
- Modify strategy to concentrate on _less_ risky approach
***If there are already delays in the deliverable, do ***_***not***_*** add more risk.***

**Changing the Work Breakdown Structure:**

## Problem Management

**Evaluate the deliverable in trouble and the deliverables following it to see whether any of the performance objectives can be reduced**
**First, examine whether the performance goals of the Project Manager are the same as the project performance objectives**
- It is natural for Project Managers to want to do the best possible job

**Revising Performance Objectives: ****   Examining Internal Objectives**

## Problem Management

- No manager wants their deliverable to limit the performance of the project
- Some of the “internal” performance objectives of the deliverable will be  tighter than those strictly required for the project as a whole
- Most senior managers know that this is a common practice
- Aiming high is how a good manager guarantees that the required performance is reached
- In times of crisis, this “comfort factor” may be removed in the interest of the project as a whole
- This decision can be made at the level of the Project Manager’s supervisor (next level up)** **

**Revising Performance Objectives: ****   Examining Internal Objectives ****cont.**

## Problem Management

**Finally, it may be necessary to revise the project performance objectives**
- Can only be initiated at the level of the Project Manager
**The technical contingency should be addressed first**
- Can problems be resolved by removing one or more of the technical contingencies from the project scope?

**Revising Performance Objectives: ****   Revising Project Performance Objectives**

## Problem Management

- Is this option more acceptable to the funding agency, government officials and future users than other alternatives?
- It is always better to propose options, rather than an all-or-nothing proposal when negotiating
- You can be sure that if you do not provide alternative solutions, someone else will (and you will look bad)
**As a last resort, a change of the project cost, schedule and/or performance objectives should be proposed – **_**REBASELINE**_

**Revising Performance Objectives: ****Revising Project Performance Objectives ****cont.**

## Problem Management

**Occasionally in the project cycle, it will be necessary to re-evaluate the entire state of the project and re-establish:**
- Modified project goals and performance criteria
- Total project costs
- Annual project costs
- The top-level project schedule
**Every effort should be made to include all known variances in the new plan**

**Rebaseline:**

## Problem Management

**Issues Log**
**You will lose the confidence of the funding agency if:**
- Rebaselines occur frequently
- Additional changes in the project plan occur soon after the rebaseline
- Why were they not included?
- How can you be sure that there aren’t other changes?

**Rebaseline:**

## Problem Management

**All of the previous discussions focused primarily on cost and schedule problems**
**Some new projects, by their very nature, push the envelope of what is possible**
- Technical difficulties are almost guaranteed
- These can only be solved by people with technical expertise
- This is why specialists are taught management, rather than having professional managers run the project

**Response to Technical Problems:**

## Problem Management

**There are three categories of technical problems**
- Solving many small difficulties takes more time than foreseen
- This has already been discussed
- A major problem comes up
- The person or vendor responsible is unable to meet the performance specifications

**Response to Technical Problems:**

## Problem Management

**Local**
- Known to a few
- State of deliverables/cost/schedule
- Local remedies
**System wide**
- Known to many
- Sometimes blurred by symptoms
- Often involves rework

**Problem Arenas:**

**Cataclysmic**
- Everyone knows
- Everyone pitches in
- Might benefit from contingency planning

## Problem Management

**Discovery**
- Is / is not
- Severity / urgency / generality
**Solution Ideas**
- Good fit?
- Effectiveness?
**Potential problem forecast**
- Adherence?
- New problems?

**Three Step Problem Solution Protocol:**

## Problem Management

**Upper management will continue to be **
**informed to the same degree they**
**demonstrate trust.**

## Problem Management

**Better sooner than later**
**Options**
- Revise schedule
- Change resources
- Modify the Charter
- Sacrifice quality
**Negotiate choices**
- Or escalate.... or impose....

**Problem Resolution:**

## Problem Management

**Smallest nearest fix**
- Keep risk levels in mind
**Let everyone know about the change**
- In writing
**Monitor resolution for effectiveness**
**When all else fails, start over**** **

**Problem Resolution:**

## I.  Recommended Reading

**A.  Introduction to Project Management**

## Recommended Reading

- Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth
- Controlling Software Projects: Management, Measurement, and Estimates by Tom Demarco, Barry W. Boehm
- Peopleware : Productive Projects and Teams, 2nd Ed. by Tom Demarco, Timothy Lister
- The Politics of Projects by Robert Block
- The Deadline: A Novel About Project Management by Tom Demarco
- People and Project Management by Rob Thomsett
- Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald M. Weinberg
- Are Your Lights On?: How to Figure Out What the Problem Really Is by Donald C. Gause, Gerald M. Weinberg
- Teaching the Elephant to Dance: The Manager's Guide to Empowering Change by James A. Belasco
- A Whack on the Side of the Head: How You Can Be More Creative by Roger Von Oech

## Recommended Reading

- Quality Software Management, Vol. 1: Systems Thinking by Gerald M. Weinberg
- Quality Software Management, Vol. 2: First-Order Measurement by Gerald M. Weinberg
- Quality Software Management, Vol. 3: Congruent Action by Gerald M. Weinberg
- Quality Software Management, Vol. 4: Anticipating Change by Gerald M. Weinberg
- New Peoplemaking by Virginia M. Satir
- Nonviolent Communication : A Language of Compassion by Marshall B. Rosenberg
- Masterful Coaching by Robert Hargrove
- Practical Project Management : Restoring Quality to DP Projects and Systems by Meilir Page-Jones, Rob Thomsett
- Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products by Daniel P. Freedman, Gerald M. Weinberg