Accelerating Requirements with Process-Centric Prototyping

Slide 1: Technology and Business Solutions Conference Accelerating Requirements with Process-Centric Prototyping George Clark and Jamie Raut Miami, FL • June 8 – 10, 2006 Produced by the Leading Edge Forum 11/5/2007 11:47:52 AM 4111-06_FMT 1

Slide 2: Speaker Introductions • George N Clark Principal Consultant, Denver Delivery Services, Consulting Group Senior Business Process Specialist. 8+ years with CSC Consulting working in Project Management, Business Architecture, and Business Process roles. • Jamie Raut Senior Consultant, San Francisco Delivery Services, Consulting Group Architectural Specialist. 6+ years with CSC Consulting and CSC Australia. Application Architect and Developer specializing in JavaEE technologies. 11/5/2007 11:47:52 AM 4111-06_FMT 2

Slide 3: Presentation Overview • Project(s) background • Methodology • Process-centric approach • Lessons Learned • Q&A • Appendix: Supporting Tools 11/5/2007 11:47:52 AM 4111-06_FMT 3

Slide 4: Project Background • Project inception January 2005 • Segment-leading Financial Services company • Industry leading performance by key business metrics • Three distinct processes being addressed, ranging from commercial real estate origination through to loan servicing: – High-value, low volume commercial real estate origination – Medium-value, medium volume commercial real estate origination – High-volume commercial real estate loan servicing • Prototype applications developed for each process by small, high-performance teams to: – Sell the vision, gain stakeholder acceptance, build momentum – Validate and further develop stakeholder requirements 11/5/2007 11:47:52 AM 4111-06_FMT 4

Slide 5: Existing Methodology • Waterfall Approach used by bank was slow. Best case scenario (below) would lead to 14 month development cycles • In reality, it ended up taking much longer than 14 months, with mixed levels of success 11/5/2007 11:47:52 AM 4111-06_FMT 5

Slide 6: Process Centric Prototyping • An abbreviated Requirements phase is followed on by a series of Solution Demonstration Lab sessions where actual screens and functionality are developed and reviewed SDL 1 SDL 2 SDL 3 11/5/2007 11:47:52 AM 4111-06_FMT 6

Slide 7: Requirements Definition • Started with the definition of the high-level process. • 100+ interviews and other materials allowed initial process model, which was collaboratively developed by business and IT • Swim lane view of the process constructed, roles defined, activities identified (human-to-system and system-to- system) Identify roles Identify activities for each role 11/5/2007 11:47:52 AM 4111-06_FMT 7

Slide 8: Initial Design and Development • Human-to-system activities earmarked for development of screens; identification of fields on screens allowed attributing of process model and beginnings of the data model 11/5/2007 11:47:52 AM 4111-06_FMT 8

Slide 9: Solution Demonstration Lab • SDLs further refined definitions of individual screens, fields, processes and sub-processes as participants were given the view of the process and led through the enabling activities. • Prototype was tailored to each project’s process requirements/attributes, e.g. high-touch, high-value, low volume commercial real estate origination process required more flexibility than loan servicing. The process application was developed accordingly. 11/5/2007 11:47:52 AM 4111-06_FMT 9

Slide 10: Lessons Learned • Moving from a Waterfall Approach to an Iterative Development Process – Client Organizational Issues - IT • While most people who work in IT talk to an iterative development process, few understand what it truly means • Working with less than complete documentation is uncomfortable for many who have been working in IT a long period of time – User Community • Users who have been exposed to IT projects are eager to embrace an iterative approach where there feedback is solicited in a regular manner • Maintain involvement of user community. Have IT management regularly report to the community and take responsibility for delivery. – Small High Performance Cross-Functional Team • The ability to create a dedicated, high quality, cross functional team is absolutely necessary to making an iterative development process work. Iterative development requires a strong, seasoned technical team to result in a quality product at release n. 11/5/2007 11:47:52 AM 4111-06_FMT 10

Slide 11: Lessons Learned (continued) • Start High Level with a Large Audience – The User Community will want to understand the high level process before diving down into the details • Move to Smaller Sessions with a Narrow Focus – After laying out the high level process and functionality, move to smaller groups with a very narrow focus on detailed functionality – Ensure there is a designated decision-maker included who can make a call on an issue and move on – Maintain momentum by holding to a regular schedule or work sessions and updates – Have developers quickly prototype ideas that come out of work sessions that perhaps aren’t clear to the whole group. Experiment! 11/5/2007 11:47:52 AM 4111-06_FMT 11

Slide 12: Lessons Learned (continued) • Determination of a Tool is Critical – IT involvement from the beginning is necessary to pick an appropriate tool – Tool must be Business Analyst and End User friendly, to get appropriate feedback and buy off on the process 11/5/2007 11:47:52 AM 4111-06_FMT 12

Slide 13: Q&A • Questions? 11/5/2007 11:47:52 AM 4111-06_FMT 13

Slide 14: BPM Tools Used on CG Projects in San Francisco • BEA AquaLogic BPM • BEA WebLogic Integration • ProActivity • Savvion • Intalio BPM Tools Evaluated for CG Projects in San Francisco • TIBCO Staffware iProcess Suite • Action Technologies • Microsoft Biztalk 11/5/2007 11:47:52 AM 4111-06_FMT 14

Slide 15: Supporting Tools • ProActivity used for initial process modeling • BEA AquaLogic Business Service Interaction (formerly FuegoBPM) selected by project team as a platform for the prototype build • Process model refined within BEA, UI built out in response to SDL feedback 8:00am SDL 5:00pm Develop 11/5/2007 11:47:52 AM 4111-06_FMT 15

Slide 16: Supporting Tools (continued) • Process model made use of common modeling techniques: sub- processes, conditional transitions et cetera. • Format was XPDL to capture notion of ‘roles’ absent in BPEL. • Actual execution model shown in SDLs. • Use of BEA AL BPM for exposing UI: JSP, Struts Tiles, AJAX • Process flexibility quickly built using proprietary BEA feature 11/5/2007 11:47:52 AM 4111-06_FMT 16

Slide 17: Supporting Tools (continued) • Several other generic, JSP- based web application prototypes were built for the other business processes. • These prototypes were based on the one constructed using BEA AL BPM but did not use that tool. • Required due to inability to use the BEA tool for non- technical/political reasons. • Processes for these prototypes were modeled and presented using MS Visio. 11/5/2007 11:47:52 AM 4111-06_FMT 17