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