Effective Project Management

1
Effective Project Management

• Barbara Stone Jodie Mathies
• November 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 youve 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
Tools/Techniques
Outputs

• Performance
• measurement Doc.
• Product Doc.
• Other Project Records

• Performance Reporting
• Project reports
• Project presentations

• Project Archives
• Project closure
• Lessons 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 its 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
• wasnt what the customer wanted
• Doesnt 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

18
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
22
Another Knowledge Area Project Risk Management
23
Knowledge Area processes can be combined in a flow
To create a project schedule (Time Management)
These processes can be combined, and iterative,
if need be
24
Each process has a flow
Activity Duration Estimating
Inputs
Tools/Techniques
Outputs

• Activity List
• Constraints
• Assumptions
• Resource Requirements
• Resource capabilities
• Historical information
• Identified risks

• Expert judgment
• Analogous estimating
• Quantitatively based
• durations
• Reserve time
• (contingency safety)

• Activity duration
• estimates
• Basis of estimates
• Activity list update

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
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
28

• Leadership is the art of accomplishing more than
  the science of management says is possible

29
(No Transcript)
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 doesnt fit our priorities
• No, only if we have time
• No, only if you make ltinsert impossible thing
  heregt 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
Pareto

• The 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 companys
  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 Vs 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 done
• The 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 figures
• Emotional view
• Devils advocate pessimist
• Optimist
• Creativity new ideas
• Organization

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 group
• Implementation 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 application
• Unavailability 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 technology
• Unable to integrate technology into product
• Seek professors help
• Drop class

• Evaluating web site
• We dont 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