SDLC

System Development Life Cycle (SDLC) and Project Risk Management
Steve Wakefield Surinder Thind

ISACA Fall Conference - Sept. 25-27, 2006 - San Francisco, CA
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
Copyright 2006 Deloitte Development LLC. All Rights Reserved.
Part I
System Development Lifecycle
Definition
System Development Life Cycle (SDLC):
Definition
Defining, acquiring and implementing application systems. This includes all stages of activity from requirements identification through implementation of the application system.
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.
Overview
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.
SDLC Phases
Project Management
Phases
Initiation
Analysis
Design
Develop
Test
Implement Maintain
Change Management Quality Assurance System Reviews and Audits
SDLC Phases - Initiation

Initiation Analysis Design Develop Test Implement Maintain
Key Activities Key Deliverables
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 Roles
Executive Management Project Sponsor/Business Champion Project Manager Business Analyst System Analyst System Architect Users
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
Key Roles
Business Analyst System Analyst Users Enterprise/Technical Architects Database Architects Quality Assurance Specialist Change Management Specialist
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
Key Roles
System Analyst System Architects Technical Architects Database Architects Quality Assurance Specialist Change Management Specialist
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
Key Roles
System Analyst Software Programmer/Developers Database/Technical Architects Enterprise Architects Quality Assurance Specialist Change Management Specialist
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
Key Roles
System and Business Analyst Test Manager Functional Test Specialist Performance Test Specialist Users QA & Change Management Specialist
10
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
Key Roles
System and Business Analyst System Architect Test Manager Test Specialists Operations/Help Desk Users QA & Change Management Specialist
11
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
Key Roles
Users Operations & Help Desk System Administrator Database Administrator Technology Support QA & Change Management Specialist
12
SDLC Models
Common SDLC Models
Waterfall Traditional model. Each phase completed before the next phase started. Incremental development over several iterations. Each iteration is a short Waterfall model. Incorporates principals of Waterfall model in a continuous flow. Prototyping frequently conducted. Rational Unified Process (RUP). Others Spiral. Extreme Programming. Object-oriented Development.
Iterative
RAD
Hybrid
Combination of models above.
13
SDLC Models - Waterfall

SDLC Phases
Initiation Analysis Design
Go-Live
Develop
Test
Implement
Maintain
Key Points 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
14
SDLC Models Iterative/Incremental

SDLC Phases
Initiate
Go-Live
Increment 1
Increment 2
Increment 3
Maintain
Key Points 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.
15
SDLC Models - RAD

SDLC Phases
Prototype
Key Points 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.
16
SDLC Models Rational Unified Process

SDLC Phases
Key Points 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.
17
SDLC Table of Contents

1. Overview Road Map Organization Structure Guidelines 2. Initiation Phase Overview Roles & Responsibilities Tools Policies and Procedures Request Submission Project Initiation Key Deliverables/Templates 3. Analysis Phase Overview Roles & Responsibilities Tools Policies and Procedures Requirement Analysis Cost/Benefit Analysis Design Alternatives Feasibility Analysis Impact Analysis Implementation Analysis Business Requirement Specifications System Architecture requirements Key Deliverables/Templates 4.2 Technical Design Phase Overview Roles & Responsibilities Tools Policies and Procedures Design Overview Technical Impact Assessment Application Flowcharts Technical Design specifications System Interfaces specifications Physical database objects, elements System Infrastructure specifications Hardware, Software Network, Connectivity Data storage Performance, Reliability Backup and Recovery Security Key Deliverables/Templates 5. Development & Unit Testing Phase Overview Roles & Responsibilities Tools Policies and Procedures Coding Procedures, Standards Unit Testing procedures Walkthrough/Peer Review procedures Development environment Key Deliverables/Templates 6. Testing Phase Overview Roles & Responsibilities Tools Policies and Procedures Test Strategy and Plan Integration Testing System Testing Regression Testing User Acceptance Testing Test Environment Test Cases, Scenarios, Scripts Test Defects Test Metrics Copyright 2006 Deloitte Development LLC. All Rights Reserved. Key Deliverables/Templates
4. Design Phase 4.1 Functional Design Phase Overview Roles & Responsibilities Tools Policies and Procedures Process flows Functional Process description Logical data models Inputs/Outputs description User Interface descriptions Regulatory/Compliance specs Conversion specifications Testing requirements Training requirements Control specifications Privacy and Security specs Key Deliverables/Templates
SA M PL E
18
SDLC Risks
Initiation Analysis Design Develop Test Implement Maintain Examples of 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. 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.
19
SDLC Reviews : Planning

Factors to be considered when planning SDLC Reviews 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.
20
SDLC Reviews : Scope

Scope of SDLC reviews 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.
21
SDLC as a Business Transformation Agent

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. Examples of Operational Problems due to ineffective SDLC User dissatisfaction. Manual workarounds. Redevelopment/Scrapped systems. Unauthorized access. Misuse of information. Weak application controls. Fraud. Audit findings. Lost customers. Increased complaints. Law suits. Unpredictable processing results. Incorrect reports or other information. Abnormal batch processing ends. Errors in related systems.
22
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.
2004 51%
Source: Standish CHAOS Report 2004, 40,000 IT Projects
Project Success Rate
2004 15% 1994 31% 1994 16% 2004 34%
Success Challenge Failure
1994 53%
Opportunity Two-thirds of projects are still unsuccessful! Significant room for improvement persists. Reason Methodologies warrant further improvement and better execution.
23
Summary
Key Messages 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 organizations 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.
24
Part II Project Risk Management
25
Definition
PMI PMBOK
Project Management Institute Project Management Body of Knowledge A project is a temporary endeavour undertaken to create a unique service, product, or result. - PMBOK Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. - PMBOK
Project
Project Management
26
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.
Key Message 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.
27
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
Key Message
4 4
Factor into your business model the cost of developing sound internal controls in the IT project. Internal controls should be part of the overall requirements.
28
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
Key Message
4 4
Completion and approval of one or more deliverables are designed to ensure proper control of project. Sign-off is normally sacrificed to speed up project execution
29
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
Key Message Project management is accountable for the effective control of these nine areas throughout the project lifecycle.
30
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 corrective actions as required
Closing
Accept project or phase and bring project or phase to ordered end
31
Project Management Lifecycle

Plan
Initiate
Monitor & Control
Close
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. The project manager is responsible for ensuring that all activities occur according to plan.
32
Process Group Interactions
Source Page 68, PMBOK 3rd Edition

Key Message The interactions provide clues as to where to focus your efforts when performing a review/audit
33
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 Activities 4 Develop Project Charter 4 Develop Preliminary Project Scope Statement 4 Develop Project Management Plan 4 Direct and Manage Project Execution 4 Monitor & Control Project Work 4 Integrated Change Control 4 Close Project Integration Management Deliverables
4 4 4 4 4 4 4 4 4
Project Charter Preliminary Project Scope Statement Project Management Plan Deliverables Work Performance Information Requested Changes Forecasts Administrative Closure Procedures Final Product, Service or Result
Key Messages
4 4
Project needs will change; the project is a living object. Unification, articulation & integrative actions are crucial for successful project completion.
34
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 Activities 4 Scope Planning 4 Scope Definition 4 Create WBS 4 Scope Verification 4 Scope Control Scope Management Deliverables 4 Scope Statement 4 Scope Management Plan 4 Work Breakdown Structure (WBS) 4 WBS Dictionary 4 Scope Baseline
Key Message
4 4
The primary concern is defining and controlling what is and is not included in the project. It is the best place to start when reviewing a project. Poorly defined scope/scope creep are common weaknesses of challenged/failed projects.
35
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 Activities 4 Activity Definition 4 Activity Sequencing 4 Activity Resource Estimating 4 Activity Duration Estimating 4 Schedule Development 4 Schedule Control Time Management Deliverables 4 Activity List & Attributes 4 Project Schedule Network Diagram 4 Milestone List 4 Activity Resource Requirements 4 Resource Breakdown Structure 4 Activity Duration Estimates 4 Project Schedule (Gantt, CPM, etc)
Key Message
4 4
Estimation is one area that is weak across the projects. Normally effort is underestimated. Milestones are normally poorly defined or not defined at all.
36
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
Key Message
4
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
Time is normally underestimated because necessary activities are not included (i.e. quality reviews, retesting).
37
Cost Management
Concept:
Processes required to ensure that project is completed within approved budget
Cost Management Activities 4 Cost Estimating 4 Cost Budgeting 4 Cost Control Cost Management Deliverables 4 Activity Cost Estimates 4 Project Funding Requirements 4 Cost Baseline (updates) 4 Performance Measurements 4 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). Cost reporting is normally done on past events and do not include projections based on project variances.
38
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
Duration can be better guide to resource cost than total personhours 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
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
Key Message
4 Cost
management addresses general management techniques like return on investment, discounted cash flow, and investment payback analysis. conclusions from past phases/projects, industry or your own experience.
4 Draw
39
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 Activities 4 Quality Planning 4 Perform Quality Assurance 4 Perform Quality Control Quality Management Deliverables 4 Quality Management Plan 4 Quality Metrics/ Checklists/ Policy 4 Process Improvement Plan 4 Quality Baseline 4 Quality Control Measurements 4 Recommended Defect Repair 4 Validated Deliverables
Key Messages
4 4 4
Quality assurance in concerned with prevention and process. Quality control is concerned with monitoring and product. Quality should be planned in not inspected in.
40
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 Planning 4 Acquire Project Team 4 Develop Project Team 4 Manage Project Team Human Resource Management Deliverables 4 Project Organization Chart 4 Roles and Responsibilities 4 Resource Availability 4 Staffing Management Plan 4 Team Performance Assessment 4 Project Staff Assignments
Key Messages
4 4
The best resources you have for the project are the resources you have. Human resource management is the project universe not just the project team.
41
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 lead times Pertinent constraints, such as a hiring freeze, a limited budget, etc.
Key Message
4 4 4
Good processes will not replace the need for good people. Requiring technical staff to work overtime wont make up for management mistakes. Look for the training plan and for team members relevant experience
42
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 Activities 4 Communications Planning 4 Information Distribution 4 Performance Reporting 4 Managing Stakeholders Communications Management Deliverables 4 Communications Management Plan 4 Performance Reports 4 Resolved Issues 4 Approved Change Requests 4 Approved Corrective Actions
Key Message
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. Project documentation must be managed properly. Look for documentation management roles. Analyze stakeholders needs to effectively communicate project information at the right time in the right manner.
4 4
43
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 Activities 4 Risk Management Planning 4 Risk Identification 4 Qualitative Risk Analysis 4 Quantitative Risk Analysis 4 Risk Response Planning 4 Risk Monitoring & Control Risk Management Deliverables 4 Risk Management Plan 4 Risk Register 4 Risk Related Contractual Agreements 4 Recommended Preventive/ Corrective Actions
Key Messages
4 4
Every project has risk, and every project should maintain a risk management plan. Risk quantification includes risk control.
44
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
Key Message
4 4 4
Project Risk Management is not a one time event. Assessing the impact is as important as identifying the risk. The project manager is not the only responsible party when it comes to risk identification.
45
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 Acquisitions 4 Plan Contracting 4 Request Seller Responses 4 Select Sellers 4 Contract Administration 4 Contract Closure Procurement Management Deliverables 4 Procurement Management Plan 4 Make or Buy Decisions 4 Contract Statement of Work (SOW) 4 Procurement Documentation Package 4 Qualified Sellers List 4 Evaluation Criteria 4 Contract 4 Contract Management Plan
Key Messages
4 4 4 4
Procurement risk includes fraud, litigation, service delivery failure, solicitation failure, etc. Procurement planning and documentation are keys to effectively obtaining the required services. Fixed price is not always the best contracting strategy RFIs are a good option to better define scope and pre-select vendors.
46
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.
Key Message
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. It can be used as a quick hit when reviewing the project. Key tool to manage vendors. A well used EVT can become a tactical and strategic tool for the project leadership.
4 4 4
47
Using Earned Value Technique

Estimated at Completion Variance at Completion
Estimated to Completion
Budget at Completion
Actual Cost
Cost Variance Planned Value Schedule Variance Earned Value
PV = Planned Value = Budgeted Cost of project at date AC = Actual Cost = Cost of work performed EV = Earned Value = % Completed X Budget at Completion CV = Cost Variance = EV - AC SV = Schedule Variance = EV - PV CPI = Cost Performance Index = EV / AC SPI = Schedule Performance Index = EV / PV BAC = Budget at Completion = Approved Budget EAC = Estimated at Completion = BAC / CPI VAC = Variance at Completion = BAC - EAC ETC = Estimated to Completion = EAC - AC
Time of Report
Project Completion Date
Time
48
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
49
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 paramountdo it right the first time! People, process and technology are included in the risk equation
Key Message Success is dependent upon understanding and mitigating potential failures before they become reality.
50
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
Key Messages
4 4
Rk is Id n a n e tific tio
Tec hno log y
P je t R k ro c is s P cs ro e s
e o ll eop Pe
R kR s o s is e p n e
R kA a s is n ly is
P jectR Mn rin an C n l ro isk o ito g d o tro
Effect of changes to the organization should be addressed
Understand and anticipate the potential failure points. Build a success charter to mitigate the potential failure points.
51
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
Key Message
4
Understanding the early warning signs may prevent the cost of failure from rising, and enhance the likelihood the project can be recovered.
52
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)
53
Questions
Steve Wakefield Senior Manager Deloitte & Touche 50 Fremont Street, 33rd Floor San Francisco, CA 94105 415-783-6384 slwakefield@deloitte.com Surinder Thind Manager Deloitte & Touche 50 Fremont Street, 33rd Floor San Francisco, CA 94105 415-783-4741 sthind@deloitte.com
54

SDLC

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDLC

Uploaded by

Copyright:

Available Formats

System Development Life Cycle (SDLC) and Project Risk Management

Steve Wakefield Surinder Thind

Part II Project Risk Management

System Development Lifecycle

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Change Management Quality Assurance System Reviews and Audits

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Initiation

SDLC Phases - Analysis

SDLC Phases - Design

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Develop

Program specifications Source code and objects Unit testing results

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Phases - Test

SDLC Phases - Implement

SDLC Phases - Maintain

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Combination of models above.

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Models - Waterfall

SDLC Models Iterative/Incremental

SDLC Models - RAD

SDLC Models Rational Unified Process

SDLC Table of Contents

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Reviews : Planning

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC Reviews : Scope

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

SDLC as a Business Transformation Agent

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Impact of SDLC Methodology

Project Success Rate

2004 15% 1994 31% 1994 16% 2004 34%

Success Challenge Failure

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Part II Project Risk Management

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Project Controls Often Overlooked

Project Management Knowledge Areas

Project Management Process Groups

Monitoring and Controlling

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Project Management Lifecycle

Monitor & Control

Process Group Interactions

Source Page 68, PMBOK 3rd Edition

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Time Audit Concepts

Cost Management Audit Concepts

Human Resource Management

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Human Resource Audit Concepts

Risk Audit Concepts

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Earned Value Technique

Copyright 2006 Deloitte Development LLC. All Rights Reserved.

Using Earned Value Technique