reducing its project risk by using and developing consensus based regional its architecture and a...
TRANSCRIPT
Reducing ITS Project Risk
By using and developing consensus based regional ITS architecture and a systems
engineering process
Robert S. Jaffe, Ph.D., CSEPPresident
Manny S. InsignaresVice President, Technology
Consensus Systems Technologies (ConSysTec) Corporation,April 2010
ConSysTec
Introduction: We will show that Developing, Maintaining, and Using a regional
ITS architecture to plan ITS projects
and Using a Systems Engineering process to
design, build, and test ITS projects: Reduces the risk of ITS project cost/schedule
overrun
and Reduces the risk of not meeting all the needs
originally intended
ConSysTec
Key Concepts
1. Regional ITS architecture and policy
2. Use of ITS Architecture/ Systems Engineering
3. Project deployment and success factors
4. (Establishing a policy for planning and designing for sustainability.*)
* Discussed in the paper, not in the presentation.
ConSysTec
1. Regional ITS Architecture & Systems Engineering Policy
A regional ITS architecture and associated SE asks:
1) Are we (the transportation agencies in the region) doing the right projects with no conflicts or overlaps?
2) Are regional multi-modal transportation organizations (transit, traffic, public safety, etc.) able to share needed information between ITS systems?
3) What needs (or user services) can be satisfied through ITS investments?
4) How do we measure success? This last one is not included in the current DOT Rule/Policy.
ConSysTec
Policy acts a catalyst to facilitate:
Development of the Regional ITS Architecture Use of the Regional ITS Architecture
in ITS Project Programming (“Integration Strategy”*) In Deployment of each ITS project (“Rule 940”)
* Proposed, but not current policy
ConSysTec
2. Use of ITS Architecture & Systems Engineering
The key purpose of Systems Engineering is to direct and focus an organization’s intention at every stage of development
ConSysTec
Project Success Factors Systems Engineering Impacts
Improves chances of delivering results within timeframe and budget, and meeting the intended needs (scope)
By detecting defects early (when they are easy to fix) through a process that emphasizes Stakeholder Validation Technical Verification Other methods (risk management, configuration
control, etc.)
ConSysTec
Relation of Budget Spent on Systems Engineering to Project Cost Overrun
Percent Budget Spend on SE Analysis
Average Project Cost Overrun
Less than 5% 125%
5 to 10% 83%
More than 10% 30%
ConSysTec
Table 2: Relation of Time Spent on Systems Engineering to
Project Delay
Later Project Phases: Design, Implementation, Test
Effort (Man-Hours) Devoted to Requirements
Activities
Schedule Devoted to
Requirements Activities
Completed Faster
14% 17%
Completed Slower
7% 9%
ConSysTec
3. Project Deployment and Success Factors
Deployment: A Systems Engineering Process Model
Project Success Factors Assessing the Contribution to Project Success
of All Project Success Factors Regional ITS Architecture
ConSysTec
The Systems Engineering Process (SEP)
Time Line
SystemRequirements
SystemVerification &
Deployment
SubsystemVerification
Unit / DeviceTesting
High-LevelDesign
DetailedDesign
Software / HardwareDevelopment
Field Installation
System Validation Plan
System Verification Plan(System Acceptance)
SubsystemVerification Plan
(Subsystem Acceptance)
Unit / DeviceTest Plan
Document/Approval
Operationsand
Maintenance
Changesand
Upgrades
Retirement/Replacement
SystemValidation
RegionalArchitecture(s)
Feasibility Study/ Concept
Exploration
Concept ofOperations
ConSysTec
Why apply Requirements-Based Validation and Verification at each stage
of the Systems Engineering Process?
Find and then eliminate defects early Find requirements gaps and inconsistencies
(i.e., conflicting requirements) Find requirements redundancies Uncover poorly-structured relationships among
system elements
ConSysTec
Table 3: Standish Group CHAOS Report Project Success Rates
Description of Project Outcome % in 2006 % in 1994
Successful, meaning projects were completed on time, on budget and met user needs
35% 16%
Outright failure or project cancelled
19% 31%
Challenged, meaning they had cost or time overruns or didn’t fully meet the user’s needs
46% 53%
ConSysTec
Table 4: Standish Group Project Risk Factors and Assessment
Project Success Factors Success Points
Success Potential of Your ProjectYes = Add Points Value; No = 0
1. User Involvement 192. Executive Management Support
16
3. Clear Statement of Requirements
15
4. Proper Planning 115. Realistic Expectations 10
6. Smaller Project Milestones 9
7. Competent Staff 88. Ownership 69. Clear Vision & Objectives 3
10. Hard-Working, Focused Staff 3
Total 100%
ConSysTec
Regional ITS Architecture
Regional ITS Architecture
Regional ITS Architecture
Regional ITS Architecture
Project specific
Project specific
Project specificProject specificProject specific
Project specific61%
Assessment of Project Success using Standish Group Method
According to the Standish Group’s method, we can increase the chances of project success by up to 60% if we: Develop a Regional ITS Architecture Use this architecture in project planning and
deployment Apply the Systems Engineering process
ConSysTec
Acknowledgments
The authors would like to thank our many clients who have trusted us to develop their consensus based ITS Architectures, and who have been the inspiration for this work.
ConSysTec
References1. Intelligent Transportation Systems Strategic Plan – Kentucky
Transportation Cabinet, Commonwealth of Kentucky, June 2000
2. State of Florida Department of Transportation, “The 2005 Update of Florida’s Intelligent Transportation System Strategic Plan,” December 2005
3. Minnesota Department of Transportation Office of Traffic, “Security and Operations Statewide ITS Strategic Plan 2006: An Action Plan for ITS Development and Deployment,” June 30, 2006
4. Paul Gonzalez, “Building Quality Intelligent Transportation Systems Through Systems Engineering;” Mitretek Systems, April 2000
5. Karl Wiegers, More About Software Requirements, Microsoft Press, 2006
6. Joseph Blackburn, Gary Scudder, and Luk N. Van Wassenhove, “Improving Speed and Productivity of Software Development: A Global Survey of Software Developers,” IEEE Transactions on Software Engineering, December 1996.
7. The “The Standish Group Report: CHAOS,” The Standish Group, 1995
8. David Rubinstein, “The Standish Group Report: There’s Less Development Chaos Today,” Software Development Times, March 1, 2007
ConSysTec