July 09, 2008 NIH Project Management Community Project Scope and Change Management Discussion This document is confidential and is intended solely for the use and information of the client to whom it is addressed.

1 The purpose of today’s discussion is to share Change and Requirement Management techniques/process that enable us to effectively manage project scope  Speaker: Chris Ghion  Relevant Background: –Booz Allen Hamilton: Currently supporting FDA CIO office, leading technical and software engineering initiatives using Oracle, Documentum, J2EE, Business Objects and Cold Fusion. Responsible for the program management and technical leadership of over 30 concurrent FDA projects, 200 staff –CareFirst BCBS: Led Information Technology strategy and delivery in support of sales and marketing organizations, acting as CIO Strategic Advisor for all CareFirst Information Technology Plans and Initiatives, and directing development and implementation of Enterprise Analytics technical program in support of Marketing organization –Verizon: Program Manager in the e-Commerce business unit. Established the first e- commerce capability to add phone service via the internet

2 One year after obtaining CMMI Level 3 we still identified the majority of changes affecting project scope in the latter phases of the SDLC, regardless of SDLC type (waterfall, iterative, RAD) JUNE 2004 Phase IdentifiedChange % Requirements4% Design18% Development24% Test54%  Community Models and Multi Dimensional Requirement Views are created to bridge the gap between business and engineering by addressing each dimension of a requirement from both a user (community) and developer perspective.  These artifacts provide a robust and detailed depiction of user needs, concepts of operation, interface specifications, data models, and requirements specifications and allocations.  The layered graphical presentation at the center of this method enables all project constituents to clearly understand the intent of the need and participate in detailed specification development and validation process. JUNE 2008 Phase IdentifiedChange % Requirements37% Design28% Development25% Test10% CHALLENGESOLUTIONRESULTS

3 Community Model Purpose: To provide a segmented enterprise view and user role types; suppliers, customers, brokers, and partners from an enterprise ‘community’ perspective. Building a community model helps to understand the enterprise environment, its users, its boundaries and the interfaces the architecture must support. Usage: We develop Community Models to show how systems support business processes as depicted within the Firms and Products Community of Interest And Community Models are developed to show the relationship between systems within the local and enterprise environments (Slide 4)

4 Multi-Dimensional Requirements View (MRV)  Created in an integrated environment of stakeholder, developers and integrators  Captures the activity workflow of people and systems  Captures the behaviors between functions, applications and data  Derives new requirements from integrated architecture analysis  Provides framework to map existing legacy requirements  Blend requirement analysis with preliminary design to answer how the system will satisfy the expressed needs of the community Requirements Visualization Web viewable; DOORS, RequistPRO Central Repository Define operational functional steps – activity workflow Map ops functions to system layer applications Map data created & data read to functions Derive new requirements, map existing requirements Derive and/or Map business rules to functions MRV System Requirements – Workflow, Interfaces, Behaviors

5 In conclusion, an automated Change Management supporting process remains the foundation for proactively managing project scope  Artifacts are selected from the organizational BAH repository or provided by the client and loaded into the configuration management repository  If desired, automated workflow processes are configured for artifact management.  Metrics are entered into the CM toolset as team members check-in each artifact. Each metric contains project-specific thresholds  When exceeded, the thresholds trigger automatic notifications that risk mitigation/planning activities need to occur  Project data are electronically transferred into the metrics databases at daily intervals  Full project reporting and monitoring is facilitated through the use of dashboards Configuration Management Toolset Risk Management Portal Metric Collection per Lifecycle Artifact Metrics Database Dashboard