System Development Life Cycle (SDLC) and Project Risk Management Steve Wakefield Surinder Thind ISACA Fall Conference - Sept. 25-27, 2006 - San Francisco, CA
System Development Life Cycle (SDLC) and
Project Risk Management
Steve Wakefield
Surinder Thind
ISACA Fall Conference - Sept. 25-27, 2006 - San Francisco, CA
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
2Copyright © 2006 Deloitte Development LLC. All Rights Reserved.
Part ISystem Development Lifecycle
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.
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.
5Copyright © 2006 Deloitte Development LLC. All Rights Reserved.
SDLC Phases
MaintainImplementTestDevelopDesignAnalysis
Project Management
Initiation
Phas
es
Change Management
Quality Assurance
System Reviews and Audits
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
25Copyright © 2006 Deloitte Development LLC. All Rights Reserved.
Part IIProject Risk Management
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
54Copyright © 2006 Deloitte Development LLC. All Rights Reserved.
Questions
Steve Wakefield
Senior ManagerDeloitte & Touche50 Fremont Street, 33rd FloorSan Francisco, CA 94105415-783-6384
Surinder Thind
ManagerDeloitte & Touche50 Fremont Street, 33rd FloorSan Francisco, CA 94105415-783-4741