1. Reducing ITS Project Risk By using and developing consensus based regional ITS architecture and a systems engineering process Robert S. Jaffe, Ph.D., CSEP President Manny S. Insignares Vice President, Technology Consensus Systems Technologies (ConSysTec) Corporation, April 2010 ConSysTec

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. The Systems Engineering Process (SEP) ConSysTec

12. 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

13. 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

14. Table 4: Standish Group Project Risk Factors and Assessment Project Success FactorsSuccess Points Success Potential of Your Project Yes = Add Points Value; No = 0 1. User Involvement19 2. Executive Management Support 16 3. Clear Statement of Requirements 15 4. Proper Planning11 5. Realistic Expectations10 6. Smaller Project Milestones9 7. Competent Staff8 8. Ownership6 9. Clear Vision & Objectives3 10. Hard-Working, Focused Staff3 Total100% ConSysTec Regional ITS Architecture Project specific 61%

15. 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

16. 4. Establishing a Policy for Planning and Designing for Sustainability Planning and designing sustainable ITS systems may require a policy directive The regional ITS architecture and systems engineering process can facilitate sustainable ITS solutions by taking into account a total life- cycle view of the ITS system Sustainability implies an even longer life-cycle, whereby fiscal, environmental and social benefits and costs can be taken into consideration to yield positive returns ConSysTec

17. 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

18. References 1.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