© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-1

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-2 Chapter 11: Project Control keep project on target as close to plan as feasible adapt to new circumstances

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-3 Planning vs. Control Planning set goals & directions allocate resources anticipate problems motivate Control guide work toward goals ensure effective use of resources correct problems reward achievement

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-4 IS Control Problems Lin & Hsieh (1995) Corporate Culture can be closed to new ideas Organizational Stability if changing, too busy Developer Experience with IT Developer Task Proficiency Project Size bigger projects, greater risks System Structure changing requirements cause problems

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-5 Managerial Actions to Maintain Project Control Ahituv et al. [1999] 1.Early user involvement 2.Senior non-technical management in charge for time and budget performance 3.Milestones for accurate project progress measurement 4.Hold suppliers & vendors legally responsible for deadlines 5.Dont change project requirements

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-6 Risk Management Boehm (1989)top risk items Personnel shortfalls Dynamic requirements Externally provided components Real-time performance benchmark Development incremental development, requirements scrubbing Unrealistic estimates multiple sources

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-7 the Control Process assess actual vs planned technical accomplishment verify validity of technical objectives confirm need for project time progress to match operational requirements oversee resource usage monitor costs

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-8 Control Process Phases performance standards - technical specifications, budgeted costs, schedules, resource requirements –from user specifications, project plan compare performance with plan - forecast anticipated date and cost at completion corrective action taken when severe variance encountered

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson 11-9 Control Devices Responsibility Assignment –Chart activities with personnel identify what each is responsible for Budget –variance analysis –Earned Value

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Earned Value Work PackageBudgeted% doneEarnedActual A B C D Total earned value5154 Efficiency = earned/actual A= 20/25 = 0.80B = 10/8 = 1.25 total project= 51/54 = 0.94

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Traditional Cost Control variance analysis in project management, deficient - doesnt track how much work completed, no projections of future costs –so show quantities –progress may be nonlinear

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Project Cost Monitoring tie to work packages –work descriptions –time-phased budgets –work plans & schedules –responsibility assignments –resource requirements keep up with change orders

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Work Authorization upper management authorizes project project manager authorizes department work via work orders functional managers authorize work orders to sections

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Data Collection upper management continues or cans project manager adjusts to solve problems work sections report progress

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Data Collection & Tally periodically collect data about actual costs and work progress project control accounting system tallies and summarizes –by work package –by department –project overall manager intimately familiar with budget, actual

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Project Review Meetings where things are going wrong –emergencies –time bombs –opportunities should be periodical participants should have information prior give assignments to present in advance –broaden participation

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson When to Hold Review Meetings periodic –regularity leads to more thorough preparation –can have in central meeting place with network schedule on wall key data available special event –at critical milestones

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Corrective Action identify WHEN ACTION NECESSARY –how much variance is acceptable? –rather than preset limits, ought to be constant projection to completion –is change worse than current?

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Reasons for Changes change in project scope & specification changes in design - errors, omissions, afterthoughts, revised needs changes to improve rate of return changes to adopt improvements

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Impact of Changes cause grief the more the project completed, the more difficult to change impact on project scope, cost, schedule are major sources of conflict may reduce changes & impact by change review process

© McGraw-Hill/Irwin 2004 Information Systems Project ManagementDavid Olson Summary project control guides work toward goals assess actual versus planned need data collection, information dissemination focus on work package & cost account use authorization process constantly update projected performance