Effective Project Management

Barbara Stone & Jodie MathiesNovember 15, 2007

2

Agenda

• Closing projects

• PMBOK

• Leadership –• Saying ‘no’

• Problem solving

Final presentation/paper

3

Key elements of successful project closure

• Ensure that the project will deliver what was promised

• Actively lead the project team through a confusing period of time

• Ensure timely completion of the “odds-and-ends” (the punch list activities)

• Prepare for the transition into the next phase in the overall project life cycle

4

Key elements of successful project closure

• Secure consensus that the project has met the completion criteria

• Obtain customer acceptance and verify customer satisfaction

• Ensure that the project records reflect accurate “as-built” data

• Transfer what you’ve learned to others

5

Key elements of successful project closure

• Acknowledge the contribution of contributors

• Bring the project to efficient administrative closure

6

Project Closure – Persistence

Project Documentation

Which project documents are important to archive? Many organizations have standards.

• Charter

• Final project status / measurement against success criteria: CVA / ROI, etc

• Lessons Learned / Best Practices / Recommendations

7

PMBOK: ‘Administrative Closure’

Inputs

1. Performance measurement Doc.

2. Product Doc.

3. Other Project Records

Tools/Techniques

1. Performance Reporting

2. Project reports

3. Project presentations

Outputs

1. Project Archives

2.2. Project closureProject closure

3.3. Lessons learnedLessons learned

8

Project Closure – Persistence

New ‘Releases’

Even though this ‘project’ is closing, the product of the project will, often, need further development / enhancements.

Knowing this, what can this project team do?

• Document the heck out of the existing product

• Document possible enhancements – either requested ones that were not included in this project scope or ideas that occur to the team

9

Project Closure – Persistence

Turnover

The product of the project may need to be managed / maintained / operated.

Generally this is a different team.

This project is responsible for appropriate turnover activities:

• Presentations

• Training

• Documentation (FAQ / user guides/etc)

10

Project Closure - Obsolescence

Yes, sometimes you are already planning obsolescence of what you just built

Still need to document – and possibly to provide input to new / replacement product

11

Team closure – Recognition and Rewards Recognition:

• within the team and to management• direct line management communication of team member contributions

Rewards:• event – when it is a good idea. Never make team members use personal time. Remember food!• compensation and time off• stuff – Sometimes the company culture is big on stuff and the team members really like it. Sometimes it’s a waste.

12

Close-out challenges

• Requires diverse technical, organizational & leadership skills

• Often has fewest bargaining chips• Behavioral issues across extended

team greatest focus area

13

Project no longer financially justified – why not shut down?

• Negativity associated with cancelling project

• Inertia• Pride

14

End in sight & team not ready

• Team has grown close• Ownership of objectives• Fear of future

15

End of project – end of team?

• Inclusion – result of project absorbed into organization along w/some team members

• Integration – Team members reintegrated into organization from which they were borrowed

• Extinction – everyone associated with project let go when project shut down

16

Expectation management

• Product • wasn’t what the customer wanted• Doesn’t work outside test environment• Unexpected charges against project

• Team• Drift away• Dislike documentation, training & trivia• Fear of future – drag out tasks

17

Expectation management – cont.

• Customer• Acceptance criteria &/or hand-off process

unclear• Disagreement about ownership of

remaining tasks• Change of personnel

PM Body of Knowledge - PMBOK

19

What is the PMBOK?

Project Management Body of Knowledge

• Publication of the PMI (Project Management Institute)

• Currently on the 3rd edition

• Content is the basis for the professional exams: PMP and CAPM

• 390 pages…..

20

PMBOK: Nine ‘Knowledge Areas’

• Integration Management

• Scope Management

• Time Management

• Cost Management

• Quality Management

• Human Resource Management

• Communications Management

• Risk Management

• Procurement Management

21

Each Knowledge Area has subsidiary processes

Scope Management Processes

Main Output

Initiation Scope section of charter

Scope planning (iterative) Requirements (scope statement)

Scope Definition WBS

Scope verification (iterative)

Formal acceptance of deliverable(s)

Scope Change Control Scope changes

22

Another Knowledge Area: Project Risk Management

Risk Management Processes

Output(s)

Risk Management Planning Risk Management Plan

Risk Identification Risks; Triggers

Qualitative Risk AnalysisPrioritized Risks; Project Risk ranking

Quantitative Risk AnalysisPrioritized Risks; Probabilistic analysis of Project

Risk Response Planning Risk Response Plan

Risk Monitoring & ControlWorkaround or Corrective Action plans

23

Knowledge Area processes can be combined in a flow

Process Output

Activity Definition Detailed WBS; activity lists

Activity Sequencing Project Network Diagrams

Activity Duration Estimation

Activity Duration Estimates

Schedule Development Project Schedule

These processes can be combined, and iterative, if need be

To create a project schedule (Time Management):

24

Each process has a flow

Inputs

1. Activity List

2. Constraints

3. Assumptions

4. Resource Requirements

5. Resource capabilities

6. Historical information

7. Identified risks

Tools/Techniques

1. Expert judgment

2. Analogous estimating

3. Quantitatively based

durations

4. Reserve time

(contingency = safety)(contingency = safety)

Outputs

1. Activity duration estimates2. Basis of estimates3. Activity list update

Activity Duration Estimating

25

PMBOK: Five ‘Process groups’

Initiating defines & authorizes project work

Planning defines/refines objectives, and plan of action to attain objectives & scope

Executing integrates people/resources to carry out plan

Monitoring and Controlling regularly measures progress and variances to plan

Closing formalizes acceptance of deliverables

These process groups are used when appropriate. They are not project phases.

26

How do ‘Knowledge Areas’ and ‘Process groups’ go together?

Each of the Knowledge Areas has processes that fit in the Process Groups. For example:

Scope Management Processes Process Group

Scope DefinitionScope Planning

Planning

Scope Control Monitoring & Controlling

27

A final PMBOK nugget

“Most experienced Project Management

practitioners know there is no single way

to manage a project. They apply project

management knowledge, skills, and

processes in different orders and

degrees of rigor to achieve the desired

project performance”

Leadership is the art of accomplishing more than the science of management

says is possible

29

30

Saying no to:

• Subordinate• Peer• Boss• Client

31

Boss

• Review constraints and things identified as critical

• Review charter, goals, ROI

• Give two alternatives

• Using project resources for personal gain is a questionable practice

32

Ways to say no

• No, that doesn’t fit our priorities• No, only if we have time• No, only if you make <insert

impossible thing here> happen• No, next release• No. Never. Ever. Really.

33

Creation of problem ≠ responsibility or ability to solve

• When an organization finds itself in a blame cycle, some people feel pressure to take responsibility for addressing a shared problem.

• When I agree to accept responsibility for resolving a shared problem, even when I agree that I contributed to creating the problem, I might be depriving the organization of better options for addressing the problem.

34

ParetoThe reason that the 80/20 principle is so

valuable is that it is counter-intuitive. We tend to expect that all causes will have roughly the same significance. That all customers are equally valuable. That every bit of business, every product, and every dollar of sales revenue is as good as any other … That all problems have a large number of causes, so that it is not worth isolating a few key causes. That all opportunities are of roughly equal value, so that we treat them all equally.

35

Pareto - What, how, when to use

• Shows relative importance of different aspects of a problem. 80/20 rule = 80% of the problems come from 20% of the causes.• 80% of customer complaints arise from

20% of your products/services• 80% of process defects arise from 20%

of process issues• 20% of the sales force produces 80% of

company’s revenues

36

Compare performance

• A minority of business activity is useful

• Value delivered to customers is rarely measured and always unequal

• Great leaps forward require measurement and comparison of the value delivered to customers and what they will pay for it

37

When to use

• You need to identify major causes of a problem

• You need a focus to resolve an issue because resources are limited

• You are ready for the first step of an improvement process

38

To discover:- Those ‘few’ items that affect the ‘many’

- Where your time is best spent

- Where your ‘pain points’ are

- What to focus on in any given process

- How best to display graphs / charts to reveal the ‘few’ V’s the ‘many’

- How your user base is behaving

- How your team are performing

39

Pareto examples• Prioritizes problems to initiate problem solving.

Example: Which product generates the most help calls from customers?

• Categorizes problems by different groupings of data, allowing you to analyze the data.Example: Data can be sorted by customer, by division, by location, by product, and so on.

• Builds consensus by drawing attention to the important causes of a problem.Example: A Pareto chart presents visual evidence of the 80/20 rule

40

How to construct

• Segment the range of data into groups or categories

• Left side is labeled frequency (the number of occurrences when the issue happened).

• Right side is vertical axis is the cumulative percentage and the horizontal axis is labeled with categories or groups of issues.

41

Pareto – getting started

42

Identify problem & requirements

43

Set-up schedule

44

Data sample

45

Measuring success

• Will the problems identified as 20% of the causes (the tallest bars) offer the greatest impact if solved?

• Do the categories used to collect the data reflect current real-life causes?

• Does the prioritization of the data reflect the current situation?

• Did you allow enough time to collect data that reflects an accurate measurement of the problem?

46

Use of the Pareto• If managed correctly, we can get 80% of business

objectives in the first 20% of the investment, and the rest can be managed to minimize just how much money we spend and risk we assume from the last 20% of benefit.

• Typically,• business community isn't given the chance to

make the business case for the requirements• sponsors aren't given the chance to arbitrate• IT isn't given the chance to show just how much

CAN be doneThe whole thing starts off badly and goes from there.

47

Pareto model – ideal design

• Capture complete, all-inclusive requirements. No filtering!

• IT comes away with a complete understanding of the users' vision.

• IT builds preliminary designs of the technical solution to deliver the features the vision includes. The design is the full court press of database designs, integration requirements, user interface designs, functional designs and technical specs

48

Technique review

• Affinity Diagram• Cause and effect (Ishikawa)• Six Hats• Pareto

49

Affinity diagrams

50

Cause-and-effect

51

Six thinking hats

• White-

• Red -• Black-• Yellow

-• Green

-• Blue -

Neutral; facts & figuresEmotional viewDevil’s advocate; pessimistOptimistCreativity & new ideasOrganization

52

Chart it

53

Risk/Opportunity handling

• Identify risks• Quantify• Qualify

• Rank by criticality• Identify options for

managing• Assign owner• Establish trigger

• Changes also change risks• Positive• Negative

• Review, reprioritize, take action

54

SMART

• Specific• Measurable• Actionable• Relevant• Timely

55

Options for action

• Avoidance – is the most direct response. Eliminating the risk or its ability to impact your project.

• Mitigation – means reducing the probability of the risk or minimizing its impact if it does occur.

• Contingency – simply means having alternative plans in place to deal with a threat, should one occur or should a mitigation plan fail.

• Transference – shifts the risk to another party. This often involves a legal or contractual relationship.

• Sharing – involves two separate parties (i.e., company and customer; system developer and end-user) taking on the responsibility for dealing with the threat and the risk.

• Acceptance – could be active or passive. • Passive acceptance means nothing will be done to prepare for the risk in advance. Instead, it will

be dealt with if and when it occurs. • Active acceptance usually means developing a contingency plan in case the event occurs later.

This could involve holding money or resources in reserve. In either case, the project manager and the organization must be able to tolerate the consequences of the accepted risk event should it occur.

56

Examples:• Tangible, realistic plan to resolve communication issues

among organizational groupImplementation plan will negatively affect one criteria that the

status quo maintains & will cause 1-2 members of the board to oppose change.

• Thoroughly consider the interest of all stakeholders & explicitly counter all tradeoffs with a list of advantages

• Design and implement service applicationUnavailability of development or testing equipment and

facilities• Lay out the development and test infrastructure in the

project plan at the beginning

57

Examples:

• Creating product with unfamiliar technologyUnable to integrate technology into product• Seek professor’s help• Drop class

• Evaluating web siteWe don’t conduct enough interviews to give us

good research data to work with• Scan through initial data set • increase # of interviews

58

Final paper• 3+ page paper. Professional Quality counts!• Objective: demonstrate understanding of project

management techniques, methods, & constraints through a review of your project

• Metrics - Articulated:• Assessment of project

• What PM tools / techniques / templates used – or not• Assessment of them

• Impact of your PM decisions / actions on the project• PM Lessons learned• PM Best practices• What would you do differently if beginning project

today? What would you do the same?• How successful were you as a Project Manager? Why?

59

• Implies measurement• Quality assessment