Top Banner
System Development Life Cycle (SDLC) and Project Risk Management Steve Wakefield Surinder Thind ISACA Fall Conference - Sept. 25-27, 2006 - San Francisco, CA
55
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Sdlc

System Development Life Cycle (SDLC) and

Project Risk Management

Steve Wakefield

Surinder Thind

ISACA Fall Conference - Sept. 25-27, 2006 - San Francisco, CA

Page 2: Sdlc

1Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Agenda

• Part I – System Development Life Cycle (SDLC)•Definition

•SDLC Phases

•SDLC Models

•Risks and Points of Control

•The Need for Project Management

• Part II – Project Risk Management•PMI and PMBOK

•Project Management Lifecycle

•Project Management Areas and Associated Risks

•Characteristics of Successful (and Failed) Projects

Page 3: Sdlc

2Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Part ISystem Development Lifecycle

Page 4: Sdlc

3Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Definition

Definition

System Development Life Cycle (SDLC):

Defining, acquiring and implementing application systems. This includes all stages of activity from requirements identification through implementation of the application system.

Page 5: Sdlc

4Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Overview

Overview

SDLC:

Provides a framework to convert management and/or business need into an application system.

Can be applied to custom development, vendor purchased or combination.

Establishes procedures, practices, and guidelines governing the system development and maintenance activities.

Consists of documented and undocumented methods, tools and guidelines.

Typical SDLC phases: Initiation, Analysis, Design, Development, Testing, Implementation, and Maintenance.

Typical SDLC models: Waterfall, Incremental, RAD, Hybrid and others.

Page 6: Sdlc

5Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases

MaintainImplementTestDevelopDesignAnalysis

Project Management

Initiation

Phas

es

Change Management

Quality Assurance

System Reviews and Audits

Page 7: Sdlc

6Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - InitiationMaintainImplementTestDevelopDesignAnalysisInitiation

Gain understanding of problem or business need

Develop project objectives and scope

Gather high-level user requirements

Conduct feasibility analysis

Conduct cost/benefit analysis

Scope project size, schedule and budget

Obtain stakeholder approvals

Project Charter

Feasibility Study Results

Cost/benefit results

System features

Project Approval

Key Deliverables

• Executive Management

• Project Sponsor/Business Champion

• Project Manager

• Business Analyst

• System Analyst

• System Architect

• Users

Key Roles

Key Activities

Page 8: Sdlc

7Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Analysis

Gain understanding of current system functionality

Meet with users to gather business and functional requirements

Develop business and functional process flows

Analyze requirements and develop alternative design solutions

Compare alternatives or perform vendor/tool evaluation

Develop user prototype

Business Requirements

Functional Specifications

Alternate Design Solutions

Vendor/Tool analysis

User Prototype

• Business Analyst

• System Analyst

• Users

• Enterprise/Technical Architects

• Database Architects

• Quality Assurance Specialist

• Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Deliverables

Key Roles

Key Activities

Page 9: Sdlc

8Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Design

Develop process flows & data flows

Develop database design & data models

Develop high-level system function design

Develop system architecture design

Develop system function design

Develop interface and conversion requirements design

Develop infrastructure design

Develop training and testing requirements

Develop deployment strategy

Logical Design Specifications - process models, data models, database design

Physical Design Specifications – system, architecture, infrastructure, conversion, interface

• System Analyst

• System Architects

• Technical Architects

• Database Architects

• Quality Assurance Specialist

• Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Activities Key Deliverables

Key Roles

Page 10: Sdlc

9Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Develop

Develop program specifications

Develop software code:

— System

— Database

— Interface

— Infrastructure

— Conversion

Conduct unit testing

Conduct code reviews and walkthroughs

Program specifications

Source code and objects

Unit testing results

• System Analyst

• Software Programmer/Developers

• Database/Technical Architects

• Enterprise Architects

• Quality Assurance Specialist

• Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Activities Key Deliverables

Key Roles

Page 11: Sdlc

10Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Test

Develop test strategy and plan

Develop test cases

Develop test environment and data

Conduct System Testing

Conduct Integration Testing

Conduct User Acceptance Testing

Conduct stress/performance testing

Track and resolve system defects and issues

Report test results

Test strategy and plan

Test Case Specifications

Test Environment & Data

Test Results

Test defects and issues log

Test Signoffs

• System and Business Analyst

• Test Manager

• Functional Test Specialist

• Performance Test Specialist

• Users

• QA & Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Deliverables

Key Roles

Key Activities

Page 12: Sdlc

11Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Implement

Develop deployment/cutover plan

Develop contingency plan

Conduct user and operations training

Perform data conversion

Deploy software/application

Cutover to production

Go-live

Decommission old system

Deployment plan

User Training Manuals

Operation Manual

Production system/code

Contingency Plan

• System and Business Analyst

• System Architect

• Test Manager

• Test Specialists

• Operations/Help Desk

• Users

• QA & Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Deliverables

Key Roles

Key Activities

Page 13: Sdlc

12Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Maintain

Perform day-to-day support & operations

Support system users

Correct system defects

Perform system enhancements

Update system documents

System defects logs

Operations and Maintenance logs

Updated documentation

System enhancements logs

• Users

• Operations & Help Desk

• System Administrator

• Database Administrator

• Technology Support

• QA & Change Management Specialist

MaintainImplementTestDevelopDesignAnalysisInitiation

Key Activities Key Deliverables

Key Roles

Page 14: Sdlc

13Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC ModelsCommon SDLC Models

• Traditional model.

• Each phase completed before the next phase started.Waterfall

• Incremental development over several iterations.

• Each iteration is a short Waterfall model.Iterative

• Incorporates principals of Waterfall model in a continuous flow.

• Prototyping frequently conducted.RAD

• Rational Unified Process (RUP).

• Spiral.

• Extreme Programming.

• Object-oriented Development.

Others

• Combination of models above.Hybrid

Page 15: Sdlc

14Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Models - WaterfallSDLC Phases

InitiationAnalysis

DesignDevelop

TestImplement

Maintain

Go-Live

• Also called “Traditional” or Big-Bang model.

• Each phase needs to be complete before start of next phase.

• Requirements are defined in Analysis phase and all subsequent phase activities are based on those requirements.

• Each step has a clear cut off before proceeding to next phase.

• Well suited when there is:

• Limited Constraints on time, budget and resources.

• Scope for the work is complete, correct, un-ambiguous.

• Limited possibility of scope, requirements or design changes.

• Not suited for software development projects due to their complexity and constant changes

Key Points

Page 16: Sdlc

15Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Models – Iterative/Incremental

• Also called “Incremental” model.

• Emphasizes need to go back and reiterate earlier stages.

• Each incremental stage is a waterfall model.

• Allows for demonstrated proof of concept early in the development cycle.

• Enables larger problems to be tacked in small chunks.

• Allows for change.

• Allows for testing to occur earlier – faults found earlier.

• Well suited for most software development projects.

Key Points

Increment 2Increment 1 Increment 3 Maintain

Initiate

SDLC Phases

Go-Live

Page 17: Sdlc

16Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Models - RADSDLC Phases

Prototype

• RAD stands for “Rapid Application Development”.

• Makes it possible to develop systems faster, especially where the user interface is an important component of application.

• Incorporates the principles of Waterfall SDLC but in a continuous flow.

• Prototyping is frequently conducted as part of requirements development.

• Design and testing activities are conducted as requirements are completed.

• Testing activities maybe conducted as part of the implementation.

• Implementation leads to changes that start the system development process all over.

Key Points

Page 18: Sdlc

17Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Models – Rational Unified Process

• RUP stands for Rational Unified Process. Develop by Rational Software (now part of IBM).

• RUP is a comprehensive and a practical process with specific advice on activities, when to do each activity and how much, has integrated tool support and has document templates.

• RUP is based on traditional software engineering methods, UML and iterative concept.

• Key practices: Develop software iteratively, manage requirements, use component based architecture, visually model software, continuously verify software quality, control changes to software.

• Key concepts: Worker, Activity, Artifact, Workflow, Iteration, Phase, Development cycle.

• 4 RUP Phases: Inception, Elaboration, Construction and Transition.

Key Points

SDLC Phases

Page 19: Sdlc

18Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Table of Contents1. Overview

Road MapOrganization StructureGuidelines

2. Initiation PhaseOverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Request SubmissionProject Initiation

Key Deliverables/Templates

3. Analysis PhaseOverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Requirement AnalysisCost/Benefit AnalysisDesign AlternativesFeasibility AnalysisImpact AnalysisImplementation AnalysisBusiness Requirement SpecificationsSystem Architecture requirements

Key Deliverables/Templates

4. Design Phase4.1 Functional Design Phase

OverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Process flowsFunctional Process descriptionLogical data modelsInputs/Outputs descriptionUser Interface descriptionsRegulatory/Compliance specsConversion specificationsTesting requirementsTraining requirementsControl specificationsPrivacy and Security specs

Key Deliverables/Templates

4.2 Technical Design PhaseOverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Design OverviewTechnical Impact AssessmentApplication FlowchartsTechnical Design specificationsSystem Interfaces specificationsPhysical database objects, elementsSystem Infrastructure specificationsHardware, SoftwareNetwork, ConnectivityData storagePerformance, ReliabilityBackup and RecoverySecurity

Key Deliverables/Templates

5. Development & Unit Testing PhaseOverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Coding Procedures, StandardsUnit Testing proceduresWalkthrough/Peer Review proceduresDevelopment environment

Key Deliverables/Templates

6. Testing PhaseOverviewRoles & ResponsibilitiesToolsPolicies and Procedures

Test Strategy and PlanIntegration TestingSystem TestingRegression TestingUser Acceptance TestingTest EnvironmentTest Cases, Scenarios, ScriptsTest DefectsTest Metrics

Key Deliverables/Templates

SAMPL

E

Page 20: Sdlc

19Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Risks

• Adoption of inappropriate SDLC for the application system.

• Inadequate controls in the SDLC process

• User requirements and objectives not being met.

• Inadequate stakeholder involvement.

• Lack of management support.

• Inadequate project management.

• Inappropriate technology and architecture.

• Scope variations.

• Time over-runs.

• Cost over-runs.

• Inadequate quality of the application system.

Examples of SDLC Risks

• Insufficient attention to security and controls.

• Performance criteria not being met.

• Inappropriate resourcing/staffing.

• Inadequate staffing skills.

• Insufficient documentation.

• Inadequate contractual protection.

• Inadequate adherence to chosen SDLC and/or development methodologies.

• Insufficient attention to interdependencies on other applications and processes.

• Inadequate configuration management.

• Insufficient planning for data conversion/migration and cutover.

MaintainImplementTestDevelopDesignAnalysisInitiation

Page 21: Sdlc

20Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Reviews : Planning

• The acquisition/development mode, technology, size, objectives and intended usage of the application system.

• Project structure for the acquisition and implementation.

• Skill and experience profile of the project team.

• The SDLC model chosen.

• The formal SDLC methodology and customized process design adopted, if any.

• Risks that are likely to effect the SDLC.

• Any concerns or issues perceived by appropriate management.

• The current SDLC stage.

• Any prior review of the earlier SDLC stages of the application system.

• Any prior SDLC reviews of similar application systems.

• The skill and experience level of the IS auditors available and the possibility of getting competent external assistance where necessary.

Factors to be considered when planning SDLC Reviews

Page 22: Sdlc

21Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Reviews : Scope

• Project charter.

• Project structure; Roles and responsibilities.

• SDLC methodology adopted; Associated tools chosen.

• Control processes within the SDLC model such as validations, approvals and sign-offs.

• Structure of SDLC deliverables; Actual deliverables.

• Project reporting and Progress tracking .

• Resource management.

• Risk management.

• Quality assurance.

• Change management, Configurationion management.

• Problem management including SLAs.

• Data conversion/migration.

• Documentation relating to in-project reviews including system testing.

• Relevant legal, regulatory and policy aspects to be complied with, if any.

Scope of SDLC reviews

Page 23: Sdlc

22Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

SDLC as a Business Transformation Agent

• To support business operations, organizations implement application systems. An effective SDLC supports business transformation.

• Ineffective SDLC processes can result in operational problems related to:

• Data quality or integrity.

• Application functions.

• Information Security.

• Business process and IT Controls.

• Customer Satisfaction.

Business Transformation Agent

Examples of Operational Problems due to ineffective SDLC

• Lost customers.• Increased complaints.• Law suits.• Unpredictable processing results.• Incorrect reports or other information.• Abnormal batch processing ends.• Errors in related systems.

• User dissatisfaction.• Manual workarounds.• Redevelopment/Scrapped systems.• Unauthorized access.• Misuse of information.• Weak application controls.• Fraud.• Audit findings.

Page 24: Sdlc

23Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Impact of SDLC Methodology• Effect - Over the past decade, project

success rates have more than doubled and the “Average Cost of Overrun” has decreased dramatically, from 180% to 43%.

• Cause – Better methodologies and methodology execution:

• Iterative Approach.

• Executive Support.

• User Involvement.

• Experienced Project Management.

• Clear Business Objectives.

• Minimized Scope Creeps.

Project Success Rate

199453%

199431%

200451%

200415%

199416%

200434%

SuccessChallengeFailure

Source: Standish CHAOS Report 2004, 40,000 IT Projects

• Opportunity – Two-thirds of projects are still unsuccessful! Significant room for improvement persists.

• Reason – Methodologies warrant further improvement and better execution.

Page 25: Sdlc

24Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Summary

SDLC has multiple phases such as Analysis, Design, Develop, Implement, etc.

SDLC methodologies can be either custom or vendor developed.

There are several SDLC approaches or models such as Waterfall, Iterative, RAD, etc.

SDLC consists of documented and undocumented methods, tools and techniques.

SDLC processes should be developed, documented, and deployed with consideration to their affect on and fit into the overall organization’s processes.

Responsibility for SDLC processes and procedures lies throughout the organization.

SDLC processes must be aligned with technology standards as well as current and planned systems architecture.

SDLC risks are present in all phases.

An effective SDLC process is important to support business processes.

Key Messages

Page 26: Sdlc

25Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Part IIProject Risk Management

Page 27: Sdlc

26Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Definition

PMI Project Management Institute

PMBOK Project Management Body of Knowledge

Project

“A project is a temporary endeavour undertaken to create a unique service, product, or result.” - PMBOK

Project Management

“Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.” - PMBOK

Page 28: Sdlc

27Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Components

• Goal•Deliver on time, on budget and per specifications (quality)

•Manage business expectations, human resources and project cost (time, money and business needs)

•Identify, quantify and control risk

• Project Manager•Ensures all activities occur according to plan

•Manages stakeholders, clients, budget, schedule, providers, product, etc.

Formal project management significantly increases the likelihood of success. A simple view of project management and actual project performance generally underlie the significance and materiality of project failures, especially in information technology.

Key Message

Page 29: Sdlc

28Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Controls

• Risk can be significantly mitigated through a series of well thought out controls.

• The controls lifecycle in an IT project should: •Define key control objectives

•Map existing control activities against control objectives

•Identify areas where required controls are absent and remediate

•Perform ongoing tests, validate, remediate and monitor

4 Factor into your business model the cost of developing sound internal controls in the IT project.4 Internal controls should be part of the overall requirements.

Key Message

Page 30: Sdlc

29Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Controls Often Overlooked• Examples of controls activities overlooked in IT

solutions are:•Approvals, authorizations and verifications

•Direct or functional activity management

•Security of assets

•Segregation of duties

•Information technology controls and performance

4 Completion and approval of one or more deliverables are designed to ensure proper control of project.4 Sign-off is normally “sacrificed” to “speed up” project execution

Key Message

Page 31: Sdlc

30Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Management Knowledge Areas• There are 9 possible areas associated with any

project that need to be actively managed• Integration Management

• Scope Management

• Time Management

• Cost Management

• Quality Management

• Human Resource Management

• Communications Management

• Risk Management

• Procurement Management

Project management is accountable for the effective control of these nine areas throughout the project lifecycle.

Key Message

Page 32: Sdlc

31Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Management Process Groups• Initiating

• Recognize that project or phase should begin and decide to commit and fund

• Planning

• Determine steps required to meet project needs throughout project lifecycle

• Executing

• Manage resources required to carry out plan

• Monitoring and Controlling

• Monitor and measure progress against plan, and effect correctiveactions as required

• Closing

• Accept project or phase and bring project or phase to ordered end

Page 33: Sdlc

32Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Project Management Lifecycle

Monitor&

ControlInitiate Close

Plan

Execute

Key Messages

4 The project management lifecycle contains integrated and re-iterative components that are continuously applied to each knowledge area and phase of the project as appropriate.

4 The project manager is responsible for ensuring that all activities occur according to plan.

Page 34: Sdlc

33Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Process Group Interactions

Source – Page 68, PMBOK 3rd Edition

The interactions provide clues as to where to focus your efforts when performing a review/audit

Key Message

Page 35: Sdlc

34Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Integration Management• Includes processes and activities to identify, define, combine,

unify and coordinate processes & project management activities

• Concept

• Involves making trade-offs among competing objectives to meet stakeholder expectations

Integration Management Activities4 Develop Project Charter4 Develop Preliminary Project Scope

Statement4 Develop Project Management Plan4 Direct and Manage Project Execution 4 Monitor & Control Project Work4 Integrated Change Control4 Close Project

Integration Management Deliverables

4 Project Charter4 Preliminary Project Scope Statement4 Project Management Plan4 Deliverables4 Work Performance Information 4 Requested Changes4 Forecasts4 Administrative Closure Procedures4 Final Product, Service or Result

4 Project needs will change; the project is a living object.4 Unification, articulation & integrative actions are crucial for successful project completion.

Key Messages

Page 36: Sdlc

35Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Scope Management• Includes processes required to ensure project includes

all/only work required and to complete project successfully

• Concept

• Product Scope – features and functions that characterize product, service or result

• Project Scope – work required to deliver product, service or result with the specified features and functions

Scope Management Deliverables4 Scope Statement4 Scope Management Plan4 Work Breakdown Structure (WBS)4 WBS Dictionary4 Scope Baseline

Scope Management Activities4 Scope Planning4 Scope Definition4 Create WBS4 Scope Verification4 Scope Control

4 The primary concern is defining and controlling what is and is not included in the project. 4 It is the best place to start when reviewing a project. Poorly defined scope/scope creep are common

weaknesses of challenged/failed projects.

Key Message

Page 37: Sdlc

36Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Time Management• Includes processes required to accomplish timely

completion of the project

• Concept:•Specific time definition, sequencing and estimating activities are identified and controlled in project schedule

Time Management Deliverables4 Activity List & Attributes4 Project Schedule Network Diagram4 Milestone List4 Activity Resource Requirements 4 Resource Breakdown Structure4 Activity Duration Estimates4 Project Schedule (Gantt, CPM, etc)

Time Management Activities4 Activity Definition4 Activity Sequencing4 Activity Resource Estimating4 Activity Duration Estimating4 Schedule Development4 Schedule Control

4 Estimation is one area that is weak across the projects. Normally effort is underestimated. 4 Milestones are normally poorly defined or not defined at all.

Key Message

Page 38: Sdlc

37Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Time – Audit Concepts• Allow enough time for:

• Quality assurance, client, and management reviews

• Reacting to review feedback by making revisions to deliverables followed by further reviews

• Status meetings and admin activities

• Re-estimating and ongoing monitoring

• Re-testing

• Vacations and statutory holidays

• Consider what can be done concurrently vs. what must be done sequentially

• Inter-relationships and dependencies

• Resource usage and availability

• Tolerance for risk

• Phasing the go-live

4 Time is normally underestimated because necessary activities are not included (i.e. quality reviews, retesting).

Key Message

Page 39: Sdlc

38Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Cost Management

• Concept:•Processes required to ensure that project is completed within approved budget

Cost Management Activities4 Cost Estimating4 Cost Budgeting4 Cost Control

Cost Management Deliverables4 Activity Cost Estimates4 Project Funding Requirements 4 Cost Baseline (updates)4 Performance Measurements4 Forecasted Completion

Key Message

4 Cost management is concerned with both the approved budget as well as the actual lifecycle costs (e.g trade-offs).

4 Cost reporting is normally done on past events and do not include projections based on project variances.

Page 40: Sdlc

39Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Cost Management – Audit Concepts• Insert buffer or contingency

into estimate - Work tends to take longer and cost more than expected, due to:

• Design changes• Non-design changes• Poor estimating techniques

• Personnel rates can change through the course of a project

• Include project performance as part of annual performance evaluation

• Project Risk Management has a cost (just as car insurance!)

• Beware the strong tendency to underestimate time required

• Duration can be better guide to resource cost than total person-hours required to complete tasks

• Include anticipated expenses such as travel, living, team lunches, etc.

• Any scope change should include a budget impact analysis

• Estimate based on individual tasks, not based on task groupings

• Try to find records of previous work performed of a similar nature

4Cost management addresses general management techniques like return on investment, discounted cash flow, and investment payback analysis.

4Draw conclusions from past phases/projects, industry or your own experience.

Key Message

Page 41: Sdlc

40Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Quality Management• Includes all activities to determine and implement

quality policy, objectives and responsibilities so project will satisfy needs for which it was undertaken

Quality Management Deliverables4 Quality Management Plan4 Quality Metrics/ Checklists/ Policy 4 Process Improvement Plan4 Quality Baseline4 Quality Control Measurements4 Recommended Defect Repair4 Validated Deliverables

Quality Management Activities4 Quality Planning4 Perform Quality Assurance4 Perform Quality Control

4 Quality assurance in concerned with prevention and process.4 Quality control is concerned with monitoring and product. 4 Quality should be planned in not inspected in.

Key Messages

Page 42: Sdlc

41Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Human Resource Management

• Concept:•Includes managing all the project stakeholders, sponsors, customers and individual contributors to the project

Human Resource Management Activities

4 Human Resource Planning4 Acquire Project Team 4 Develop Project Team4 Manage Project Team

Human Resource Management Deliverables

4 Project Organization Chart 4 Roles and Responsibilities4 Resource Availability4 Staffing Management Plan 4 Team Performance Assessment4 Project Staff Assignments

4 The best resources you have for the project are the resources you have.4 Human resource management is the project universe not just the project team.

Key Messages

Page 43: Sdlc

42Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Human Resource – Audit Concepts• Consider the following:

• Technical requirements of the project vs. technical competence of prospective team members

• Relevant (non-technical) experience of prospective team members

• Personnel development plans, goals and interests

• Training plan for team members

• Potential need for external resources

• Availability of internal & external resources, and required leadtimes

• Pertinent constraints, such as a hiring freeze, a limited budget, etc.

4 Good processes will not replace the need for good people.4 Requiring technical staff to work overtime won’t make up for management mistakes.4 Look for the training plan and for team members relevant experience

Key Message

Page 44: Sdlc

43Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Communications Management• Includes processes for timely, appropriate

generation, collection, distribution, storage, retrieval and ultimate disposition of project information

• Concept: Provides critical links between personnel, ideas and information necessary for project success

Communications Management Deliverables

4 Communications Management Plan 4 Performance Reports4 Resolved Issues4 Approved Change Requests4 Approved Corrective Actions

Communications Management Activities

4 Communications Planning4 Information Distribution 4 Performance Reporting4 Managing Stakeholders

4 Communications management is the internal and external view of the success of the project, and must ensure that all applicable internal and external compliance regulations are adhered to.

4 Project documentation must be managed properly. Look for documentation management roles.4 Analyze stakeholders needs to effectively communicate project information at the right time in the

right manner.

Key Message

Page 45: Sdlc

44Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Risk Management• Includes processes concerned with conducting risk

management planning, identification, analysis, responses, and monitoring and control on a project

• Concept:•Seeks to maximize probability and impact of positive events and minimize consequence of adverse events

Risk Management Deliverables4 Risk Management Plan4 Risk Register4 Risk Related Contractual Agreements4 Recommended Preventive/ Corrective

Actions

Risk Management Activities4 Risk Management Planning4 Risk Identification4 Qualitative Risk Analysis4 Quantitative Risk Analysis4 Risk Response Planning4 Risk Monitoring & Control

4 Every project has risk, and every project should maintain a risk management plan. 4 Risk quantification includes risk control.

Key Messages

Page 46: Sdlc

45Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Risk – Audit Concepts• Project Risk Management:

• Needs to be included in the plan (performed upfront)

• Needs to be scalable (to size, duration and complexity of project)

• Should be considered as an input when approving project

• Project Risk Management logs should be kept current

• Risk impact should be assessed from qualitative and quantitative perspective

• Vendors/Integrators should have input on project risks

• A clear definition of escalation procedures is required

4 Project Risk Management is not a one time event.4 Assessing the impact is as important as identifying the risk.4 The project manager is not the only responsible party when it comes to risk identification.

Key Message

Page 47: Sdlc

46Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Procurement Management• Includes processes to purchase or acquire products, services

needed from outside the project team to perform the work

• Concept:

• Seeks to maximize results of internal and external sourcing of goods and services

Procurement Management Activities

4 Plan Purchases and Acquisitions4 Plan Contracting 4 Request Seller Responses 4 Select Sellers4 Contract Administration 4 Contract Closure

Procurement Management Deliverables4 Procurement Management Plan 4 Make or Buy Decisions4 Contract Statement of Work (SOW) 4 Procurement Documentation Package4 Qualified Sellers List4 Evaluation Criteria4 Contract4 Contract Management Plan

4 Procurement risk includes fraud, litigation, service delivery failure, solicitation failure, etc. 4 Procurement planning and documentation are keys to effectively obtaining the required services. 4 Fixed price is not always the best contracting strategy4 RFIs are a good option to better define scope and pre-select vendors.

Key Messages

Page 48: Sdlc

47Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Earned Value Technique• EVT is a quantitative method

• EVT measures performance of the project as it moves from project initiation through project closure.

• The methodology also provides a means to forecast future performance based upon past performance.

4 EVT provides project metrics. EVT compares the cumulative value of budgeted cost of work performed to both budgeted cost for work scheduled and to the actual cost of work performed.

4 It can be used as a quick hit when reviewing the project.4 Key tool to manage vendors.4 A well used EVT can become a tactical and strategic tool for the project leadership.

Key Message

Page 49: Sdlc

48Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Using Earned Value Technique

Budgetat

Completion

Actual Cost

Planned Value

Earned Value

Time

Estimatedat

Completion

ProjectCompletion

Date

Timeof

Report

Schedule Variance

Cost Variance

PV = Planned Value = Budgeted Cost of project at dateAC = Actual Cost = Cost of work performedEV = Earned Value = % Completed X Budget at CompletionCV = Cost Variance = EV - ACSV = Schedule Variance = EV - PVCPI = Cost Performance Index = EV / ACSPI = Schedule Performance Index = EV / PVBAC = Budget at Completion = Approved BudgetEAC = Estimated at Completion = BAC / CPIVAC = Variance at Completion = BAC - EACETC = Estimated to Completion = EAC - AC

Varianceat

Completion

Estimatedto

Completion

Page 50: Sdlc

49Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Successful Projects: Themes• Project starts with end in mind

• Organization is committed to project

• Project relies on sound processes and has sufficient internal controls

• Steering committee and project manager are empowered to act

• Organization is ready and accepts that the environment will change

• Organization is ready to enable technology to achieve results

Page 51: Sdlc

50Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Successful Projects: Themes (cont.)• Risk management is planned, not ad-hoc

• Resource allocation based on plan and required skills

• Project has strong business case

• Organization performs due diligence before selecting “best” option

• Key considerations include much more than “cost”

• Quality is paramount…do it right the first time!

• People, process and technology are included in the risk equation

Success is dependent upon understanding and mitigating potential failures before they become reality.

Key Message

Page 52: Sdlc

51Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Successful Projects Depend on Technology, People, and Process

• Seven elements frequently cited as having highest percentage for potential failure if not executed:

• IT solution should be validated against core business strategy

• Plan should be based on experience of project stakeholders

• Project should have executive management champions

• Controls should be identified as potential point of failure

• Project cost should be defined

• Professional skepticism (due diligence) should be performed

• Effect of changes to the organization should be addressed

4 Understand and anticipate the potential failure points.4 Build a “success charter” to mitigate the potential failure points.

Key Messages

Risk

Identification

Risk

Identification

Risk ResponseRisk Response Risk AnalysisRisk Analysis

Project Risks

Process

Tech

nolog

y People

Project Risk Monitoring and Control

Risk

Identification

Risk

IdentificationRisk

Identification

Risk

Identification

Risk ResponseRisk ResponseRisk ResponseRisk Response Risk AnalysisRisk AnalysisRisk AnalysisRisk Analysis

Project Risks

Process

Tech

nolog

y People

Project Risk Monitoring and Control

Page 53: Sdlc

52Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Characteristics of Failing/Challenged Project Begin in Planning Phase

• Project officially “in trouble” has public warning signs:

• Project milestones and deliverables are officially delayed

• Project milestones are ignored or not fully defined

• Personnel turnover increases (management, line, contractor)

• Funding is monitored at the detail level

• Before project is officially “in trouble,” warning signs are evident:

• Changes in project status reporting with concentrations on “completed” rather than “remaining”

• Approved (funded) requirements are discussed as “next phase”

• Changes in project terminology both verbal and non verbal

• Subject matter experts appear

4 Understanding the early warning signs may prevent the cost of failure from rising, and enhance the likelihood the project can be recovered.

Key Message

Page 54: Sdlc

53Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Additional Resources

• Project Risk Management•www.pmi.org

•www.isaca.org

•www.sei.cmu.edu/cmmi

•www.risksig.com (PMI Risk Special Interest Group)

• SDLC •www.ibm.com/software/rational

•www.extremeprogramming.org

•www.agilealliance.org

•www.wikipedia.org (Agile, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP)

Page 55: Sdlc

54Copyright © 2006 Deloitte Development LLC. All Rights Reserved.

Questions

Steve Wakefield

Senior ManagerDeloitte & Touche50 Fremont Street, 33rd FloorSan Francisco, CA 94105415-783-6384

[email protected]

Surinder Thind

ManagerDeloitte & Touche50 Fremont Street, 33rd FloorSan Francisco, CA 94105415-783-4741

[email protected]