Bus 564 Project Management - PowerPoint PPT Presentation

1 / 26
About This Presentation
Title:

Bus 564 Project Management

Description:

Project Characteristics v. Control Approach. Source: Dr. ... Walkthroughs pg. 459 (less formal, structured walkthroughs) Other types: Fig. 2 / Table 1. Pg. ... – PowerPoint PPT presentation

Number of Views:32
Avg rating:3.0/5.0
Slides: 27
Provided by: DRK106
Category:

less

Transcript and Presenter's Notes

Title: Bus 564 Project Management


1
Bus 564 Project Management
  • Ch. 12
  • Tracking Progress Project Control

2
Project Characteristics v. Control Approach
High
High
Behavior Control
Outcome Control
Client Liaison Understanding of IS development
Process
Outcome Measurability
Clan Control
Self Control
Low
Low
Behavioral Observability
High
Low
Source Dr. Kevin McCormack - 2002
3
Definitions
  • Outcome Control
  • Define targets and controllees decide how to meet
    them.
  • Behavior Control
  • Define steps and procedures for task performance
    according to prescribed procedures.
  • Self Control
  • Individuals set their own goals, self monitors
    goal achievement and rewards / sanctions
    themselves accordingly.
  • Clan Control
  • Clan - group of individuals who are dependent on
    each other / common goals. Clan control operates
    when all members embrace the same values, similar
    problem solving approaches and commits to
    achieving group goals.

4
Definitions
  • Outcome Measurability
  • Ability to measure achieved results.
  • Behavior Observability
  • Availability of information that reveals
    controllers behaviors.
  • Client Liaison
  • Business manager that is actively sponsoring /
    championing an IS project.
  • Understanding of IS Development Process
  • Knowledge of IS development lifecycles, practices
    and procedures.

5
Measuring Progress
  • Schedule
  • Cost
  • Changes
  • Escalation
  • Recovery / Cancellation

6
Metrics and Visibility
  • establishing the methods of monitoring the
    software project and reporting project status..
    Objective determine project status and
    visibility of progress.
  • Software quality metrics
  • Quantitative measure of the degree to which
    software possess a given attribute that affects
    its quality (reliability, maintainability,
    portability)
  • Software quantity metrics
  • Quantitative measure of some physical attribute
    of software.(line of code, function points,
    pages of docs)
  • Management metrics
  • Management indicators that can be used to measure
    management activities such as budget spent, value
    earned, costs overruns, schedule delays)

7
Compare
Act
Detect
Process
8
Metrics and Visibility
  • establishing the methods of monitoring the
    software project and reporting project status..
    Objective determine project status and
    visibility of progress.
  • See pg.. 452, Ch. 10 for list of metrics
  • Software engineering metrics (ESC)
  • Management metrics (US Airforce)
  • Software Engineering Institute (SEI) Metrics

9
Metrics and Visibility
10
Defects Measurement - Control Chart Approach
High
100
UCL (Upper Control Limit)
of Defects Detected by Week
LCL (Lower Control Limit)
Build (and Test) Phase
Roll out Phase
Close out
Low
0
Time
Source Dr. Kevin McCormack - 2002
11
Requirements Measurement Approach
High
100
of Changes by Week
Acceptance (cumulative)
Design Phase
Build Phase
Roll out Phase
Close out
Low
0
Time
Source Dr. Kevin McCormack - 2002
12
Defects Measurement Approach
High
100
Progress (cumulative)
of Defects Detected by Week
Build (and Test) Phase
Roll out Phase
Close out
Low
0
Time
Source Dr. Kevin McCormack - 2002
13
Peer Reviews
  • process in which a software product
    (requirements, docs, designs, code, test plans)
    is examined by peers of the products authors..
    Objective detecting faults and identifying
    improvements.
  • Software Inspections (can id 80 of defects
    early)
  • Walkthroughs pg. 459 (less formal, structured
    walkthroughs)
  • Other types Fig. 2 / Table 1. Pg. 460-1
    (limited or unlimited pg. 459)
  • Benefits Figures 3,4, 5, 6 and 7 25-30
    productivity improvement
  • Cost 15 of the total cost.
  • Source Software Peer Reviews. Wheeler, et. Al.

14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
Software PM Audits
  • help identify organizational problems.
  • Project team knows whats right, wrong and how
    to do it better.
  • Audits give them a voice.
  • Reviews the process, tools and organization
    employed.
  • Done when needed not as part of the lifecycle.
  • Clues found page 471.
  • Why Audit? pg. 472
  • How group interviews, questionnaires,
    one-on-one
  • Who 3-5 people outside of organization.
  • Tools listening, questionnaire, structured
    interviews, public praise (sympathy), walking
    around (observation and water cooler talk)
  • Source Software Project Management Audits.
    Bernstein, L. Bell Laboratories.

23
Project Recovery
  • What is a troubled project?
  • No idea when it will finish. Laden with defects
  • Excessive OT (60 ) Loss of PM control
  • Loss of customer confidence Defensive team
    behavior
  • Strained relations
  • Recovery options (McConnell pg. 373)
  • Cut scope to fit time
  • Short term productivity improvement
  • Face it / damage control
  • Reasons for troubled projects?
  • Lack of PM control
  • Short cuts
  • Recovery plans
  • Big steps not a thousand cuts
  • First steps, people, processes, product
    (McConnell pg. 376)
  • Back to the basics

24
De-escalation
  • reversal of commitment to failing courses of
    action through termination or redirection. -
    Keil, M. and Robey D.. Turning around troubled
    software projects., Journal of Management
    Information Systems. Spring 1999.
  • Escalation -
  • continued commitment in the face of negative
    information about prior resource allocations
    coupled with uncertainty surrounding the
    likelihood of goal attainment.
  • Actors who triggered de-escalation (Table 3)
  • Top management
  • Internal IS auditor
  • External auditor / consultant
  • IS users
  • Is project team members
  • IS management

25
(No Transcript)
26
De-escalation
Actions taken in de-escalation (Table 4) Redefine
the project Improve project management (processes
and practices) Change in project
leadership Subdivide the project Resolve specific
problems Adding / removing resources Layoff and
hiring (shoot the wounded?) Training A process
for detecting and deciding must
include.. Detection of negative information about
the project Information passing to someone
authorized to take action Receptivity (mum
effect, whistle blowing, deaf ears, three
monkeys) Decision process - escalation or
de-escalation - willingness to take action
Write a Comment
User Comments (0)
About PowerShow.com