MGMT631 Slides Two.ppt

Fall 2009 David Harris

MGT631 IS Project ManagementMGT631 IS Project Management

Slides Two

Fall 2009 2

Session ObjectivesSession ObjectivesCase discussion:

e.g. Big I & BCDC, Grip Projects

System Life CycleRapid Application Development

(RAD)Prototyping & Time BoxCapability Maturity Model (CMM)

Remember Verzuh’sRemember Verzuh’sFive Essential Success FactorsFive Essential Success Factors

Agreement on GoalsPlan clearly indicating what and whoConstant, effective CommunicationControlled ScopeManagement support

Case DiscussionCase Discussion “BIG I” Successful? Well planned? Clear accountability? Did things go wrong? Effective

communications? Carrot & stick?

“BCDC” Fiasco? Planned or happened? Anyone accountable? Anyone fired? Frank’s plumbing? One disaster after

another? Who cares?

I40/Coors Interchange I40/Coors Interchange Reconstruction ProjectReconstruction Project

http://nmgrip.com/projects.asp?project=14912

I40 – Pennsylvania BridgeI40 – Pennsylvania Bridge

http://nmgrip.com/projects.asp?project=15300

Fall 2009 6

Projects Don’t Run In IsolationProjects Don’t Run In Isolation

Projects operate in broad organizational environment

PMs must take holistic or systems view understand how project fits into

larger organization

Project Management doesn’t take place in Project Management doesn’t take place in isolationisolation

Project environment

Organizational environment

Rest of the world

Boundaries Interactions create pressure & cause changes

Systems View of Project ManagementSystems View of Project Management

Systems approach emerged in 1950s More analytical approach to management & problem

solving Examine the problem by first understanding the

environment in which it exists, next reduce the problem into smaller components & then manage the resolution of the problem

Three parts: Systems philosophy: View things as systems,

interacting components working within an environment to fulfill some purpose

Systems analysis: problem-solving approach Systems management: Address business,

technological & organizational issues before making changes to systems

Fall 2009 9

Systems Development Life Cycle Systems Development Life Cycle

Systems Development Life Cycle SDLC framework for describing phases in

developing & maintaining information systems

Typical SDLC phases include planning, analysis, design,

implementation & support

Fall 2009 10

Systems Development Life CycleSystems Development Life Cycle

Traditional (heavyweight)

RAD

(Rapid Application Development)

Agile (Lightweight)

Fall 2009 11

Sample SDLC ModelsSample SDLC Models

Waterfall model well-defined, linear stages of systems

development of support

Spiral model software developed using iterative or

spiral approach rather than linear approach

Fall 2009 12

Sample SDLC Models (cont.)Sample SDLC Models (cont.) Incremental release model

progressive development of operational software

RAD model produces systems quickly without

sacrificing quality (!)

Prototyping model develops prototypes to clarify user

requirements

Systems Development Life CycleSystems Development Life Cycle

Systems ImplementationProduct:

Operational System

Systems ImplementationProduct:

Operational System

Systems InvestigationProduct:

Feasibility Study

Systems InvestigationProduct:

Feasibility Study

Systems AnalysisProduct:

Functional Requirements

Systems AnalysisProduct:

Functional Requirements

Systems DesignProduct:

System Specifications

Systems DesignProduct:

System Specifications

Systems MaintenanceProduct:

Improved System

Systems MaintenanceProduct:

Improved System

Understand theBusinessProblem orOpportunity

Develop anInformationSystemSolution

Implementthe InformationSystemSolution

SDLCSDLC

Traditional ApproachTraditional Approach

Structured Approaches:Structured Approaches:Waterfall MethodWaterfall Method

Spiral Model of Software Development Spiral Model of Software Development (Boehm, 1988)(Boehm, 1988)

RAD -- PrototypingRAD -- Prototyping

Use and Maintainthe Accepted

System

Use and Maintainthe Accepted

System

Identify an EndUser's Information

Requirements

Identify an EndUser's Information

Requirements

DevelopInformation System

Prototypes

DevelopInformation System

Prototypes

Revise the Prototypesto Better Meet EndUser Requirements

Revise the Prototypesto Better Meet EndUser Requirements

PrototypingCycle

MaintenanceCycle

Fall 2009 17

Sandra DewitzSandra DewitzSystems Analysis & Design (1996)Systems Analysis & Design (1996)

Traditional systems development ill-suited for online, real time systems

development ill-suited for leading edge development does not foster customer-designer

communication inflexible as freezes requirements (tries to!)

Three popular strategies joint application development (JAD) phased development rapid application development (RAD)

Fall 2009 18

JADJADOvercomes customer-designer

communications gapReduce time/effort documenting,

approving requirements/designJAD sessions bring

users/designers together to focus on project development

Employs prototyping as integral part of process

Fall 2009 19

JPPJPPJoint Project Planning (JPP)

sessionObjective: develop a project plan

that meets conditions negotiated between requester & provider

Wysocki chapter 8

Fall 2009 20

Phased DevelopmentPhased Development

Partitions large system into subsystem based on major processes

Performs traditional cycle iteratively till full system implemented

Fall 2009 21

RADRAD

Similar to both JAD & phased development Segments system into subsystem Iteratively performs model-critique-refine

process till users approve prototype What sets RAD apart is addition of TIMEBOX

sets time limit on prototyping phase Goal is having working system of limited

functionality quickly

Fall 2009 22

RADRAD (continued) (continued)

Incremental delivery reduces time from requirements to system delivery

Limited time and expense at risk for organization

RAD approach not appropriate for all projects

RAD ProcessRAD Process

System

definition

System initiationinitiation

JAD planning JAD planning & design& design

Timebox

User request for change

System

evaluation

Put system into productionPut system into production

Minor system Minor system

modifications mademodifications made

system redefinition system redefinition performed if not suitable for performed if not suitable for

implementationimplementation

User reviewBuild & evolve

Fall 2009 24

Other SDLC ModelsOther SDLC Models Scrum model Rational Unified Process (RUP) model Agile methodologies

e.g. eXtreme Programming XP) model

Fall 2009 25

Project Phases & Management ReviewsProject Phases & Management Reviews

Project should successfully pass through each project phase in order to continue on to next

Management reviews (also called phase exits or kill points) should occur after each phase to evaluate project’s progress likely success continued compatibility with organizational

goals

Distinguishing Project Life Cycles & Distinguishing Project Life Cycles & Product Life CyclesProduct Life Cycles

Project life cycle applies to all projects, regardless of products being produced

Product life cycle models vary considerably based on nature of product

Most large IT products are developed as a

series of projects * Project management is a done is all of the

product life cycle phases

* I have three 5-7 months mini-projects not an 18 months project

Fall 2009 27

Project Team – Stakeholders – OrganizationProject Team – Stakeholders – Organization

Marchewka

“project success does not depend primarily on the team, but more on the set of processes and infrastructure in place”

Fall 2009 28

Need for Organizational Commitment to ITNeed for Organizational Commitment to IT

If the organization has a negative attitude toward IT, it will be difficult for an IT project to succeed

Having a Chief Information Officer (CIO) at a high level in the organization helps IT projects

Assigning non-IT people to IT projects also encourages greater commitment

Fall 2009 29

Need for Organizational StandardsNeed for Organizational Standards

Standards & guidelines help project managers be more effective

Senior management can encourage use of standard forms & software for project

management development & use of guidelines for writing

project plans or providing status information creation of project management office or

center of excellence

Fall 2009 30

Project Management Process GroupsProject Management Process Groups Project management can be viewed as

a number of interlinked processes The project management process

groups include initiating processes planning processes executing processes controlling processes closing processes

PMBOK PMBOK Project Management Process GroupsProject Management Process Groups

Fall 2009 32

Developing an IT Project Developing an IT Project Management MethodologyManagement Methodology

Just as projects are unique, so are approaches to project management

Many organizations develop their own project management methodologies, especially for IT projects

Next slides illustrates outline methodology from Marchewka

An IT Project MethodologyAn IT Project Methodology

PLC versus SDLCPLC versus SDLC

Software Engineering Institute (SEI)Software Engineering Institute (SEI)

SEI at Carnegie Mellon, funded by DOD http://www.sei.cmu.edu/

Focus on 2 areas of software development enhanced management process technical engineering practices

Fall 2009 36

Process ImprovementProcess Improvement

““If you can guarantee the quality If you can guarantee the quality of the processes used by an of the processes used by an

organization, you can guarantee organization, you can guarantee the quality of the products and the quality of the products and services generated by these services generated by these

processes”processes”

Fall 2009 37

Capability Maturity ModelsCapability Maturity Models

SEI offers a number of CMMsCMMs define best practicesAre cornerstones for process

improvement How mature/immature are your

organization’s processes?Software CMM defines

principles & principles underlying software process maturity

Fall 2009 38

Software CMMSoftware CMMFive Levels of MaturityFive Levels of Maturity

Initial overall approach ad hoc, occasionally

chaotic; few processes defined; success depends on individual effort

Repeatable basic PM processes in place to track cost,

schedule, functionality Defined

S/w processes for management & engineering documented, standardized & integrated into development processes

Fall 2009 39

Five levels of Maturity (cont.)Five levels of Maturity (cont.)

Managed detailed measures of software process

& product quality collected; software processes understood & controlled

Optimizing continuous process of improvement

enabled by quantitative feedback from process &piloting innovative ideas & technologies

Fall 2009 42

Maturity Levels & DefectsMaturity Levels & Defects

Maturity level 1 2 3 4 5

Defects E/KSLOC 12 6 2.5 0.9 0.3

Fall 2009 43

The Cost of QualityThe Cost of Quality

The cost of quality is the cost of conformance or delivering

products that meet requirements and fitness for use

the cost of nonconformance or taking responsibility for failures or not meeting quality expectations

Costs Per Hour of Downtime Caused by Costs Per Hour of Downtime Caused by Software DefectsSoftware Defects

BusinessBusiness Cost per hour downCost per hour down

Automated tellerAutomated teller

(medium-sized bank) (medium-sized bank) $14,500$14,500

Package shipping servicePackage shipping service $28,250$28,250

Telephone ticket salesTelephone ticket sales $69,000$69,000

Catalog Sales centerCatalog Sales center $90,000$90,000

Airline reservation centerAirline reservation center

(small airline)(small airline)$89,500$89,500

Fall 2009 45

Six Phases of a ProjectSix Phases of a Project

1) Enthusiasm

2) Disillusionment

3) PANICPANIC

4) Search for Guilty

5) Punishment of Innocent

6) Praise & Honors for Non-Participants