Comprehensive Delivery Process

1. State of Connecticut Department of Information Technology (DOIT) Comprehensive Delivery Process System Development Methodology (SDM) for Rapid Application Development (RAD) Training Presentation

2. Agenda • RAD Project Critical Success Factors • RAD Project Risks • Overview of SDM-RAD Project Characteristics • Overview of SDM-RAD Activities, Deliverables, and Events • Key Points of Emphasis: • Time-boxing • Joint-Application Design (JAD) Sessions • Prototyping • Sprint Planning • Sprint Management • Sprint Burn-down Chart

3. RAD Critical Success Factors Effective Project Scoping…Be Prudent… Scope should be achievable; Position the team for success; Remember that requirements & design iterations are limited (limit of 3) and time-boxed (7 calendar days per iteration); Do not over commit!; Remember that once requirements & design is complete, the delivery of functionality is time-boxed (i.e. SDM RAD requires the delivery of VALUE-ADDED functionality in 30 calendar day increments); Do not over commit! Strong Project Management RAD projects are very fast-paced and requires EXCEPTIONAL project management skills Requires effective status reporting process in a fast-paced development environment; Requires effective forecasting skills; day-to-day forecasting and adjusting to ensure that the project team can successfully achieve project delivery commitments on-time and within budget; Rapid adjustment of project resources based on day-to-day analysis of REMAINING HOURS to complete committed work. Strong Facilitation Skills Effective RAD projects utilize cross-functional working sessions (e.g. JADs, daily status meetings); Without strong meeting facilitation skills, RAD projects are likely to fail. JAD sessions should be well planned; Session objectives should be pre-determined and the process to achieve the objectives within the allotted time should be carefully “rehearsed”;

4. RAD Project Risks Risk 1: Due to fast-paced nature of RAD projects, technicians may compromise when developing solutions. Mitigation: Pre-establish solution quality criteria in the Project Management Plan prior to beginning solution development (e.g. number of acceptable defects by severity level); Include the delivery of system documentation within the scope of each delivery “package”; Establish traceability between requirements and design components; Write test cases based on defined requirements. Risk 2: Project resources must be largely (if not fully) committed to the RAD project in order for the team to meet aggressive and inflexible schedule commitments; this may pose an organizational challenge. Mitigation: Secure all required BUSINESS AND TECHNOLOGY resources UPFRONT, before initiating the project with the PMO; If resources can not be secured and largely (if not fully) committed to the project, use of the SDM RAD methodology should be reconsidered. Risk 3: Successful RAD projects require strong project management and facilitation skills; without these skills, the project team is not likely to succeed. Mitigation: Leadership must assign a strong project manager to the RAD project; If a strong project manager is not available, use of the SDM RAD methodology should be reconsidered; Seek a trained facilitator who could be temporarily enlisted to plan and facilitate JAD sessions, only; if strong facilitation skills are not available to the project team, use of the SDM RAD methodology should be reconsidered.

5. SDM – RAD Project Characteristics The SDM-RAD methodology is used for custom application development projects within the State of Connecticut. SDM RAD has four (4) phases within which defined IT work products are created and delivered.  These phases are: Business Issue, User Design, Sprint, and Closure. All phases are executed sequentially, although multiple iterations of work is expected within the User Design and Sprint phases of the project. At the conclusion of each phase (at a minimum), decision-point meetings are held with the Project Steering Committee to review the current project status and receive authorization to proceed to the next phase. Specific characteristics of SDM-RAD projects are outlined below. Note: SDM RAD is not applicable for Infrastructure projects or COTS projects.

6. = Time-boxed = These activities are executed iteratively for each sprint SDM RAD (Overview)

7. SDM - RAD Deliverables & events Business Issue Sprint Closure User Design • Phase Kickoff Meeting • Solution Approach Document • Cost/Benefit Analysis • Project Management Plan • Project Team Wheel • Project Profile • Request for Information (RFI) (O) • Detailed Schedule for Next-Phase • Phase-End Decision-Point Meeting • 30-Day Sprints- For each planned Sprint: - Environment Migration Checklist - Sprint Kickoff Meeting - Sprint Code/Unit Testing - Sprint UAT & Signoff - Sprint Performance Testing & Signoff (O) - Sprint Burn-down Chart (O) - Test Summary Report - Sprint Deployment to Production • - System Bill of Materials • - Updated Deployment Strategy & Plan - Updated Sprint Plan - Updated Cost/Benefit Analysis - Updated Project Management Plan • Production Support & Administration Document • PSC Decision-Point Meetings • Production Support Signoff • Project Summary • Project Shutdown • Backout/Recovery Plan • Business Process Model (O) • Data Model (O) • Deployment Strategy & Plan • Established Development Environment • Phase Kickoff Meeting • Phase-End Decision Point Meeting • Procurement – 3rd Party Services (O) • Prototype • Requirements Workbook • Solution Alternatives Document • Solution Sign-Off • Sprint Plan • System Design Document • System Security Profile • Test Strategy & Plan • TRB Design Review • Updated Cost/Benefit Analysis • Updated Project Management Plan Legend: (O) – Optional – Time-Boxed

8. Time-boxing Time-Boxing Best Practices Identify the appropriate time box (i.e. 30 days). Identify candidate areas for time boxing. (e.g. contained, clear expectations) Identify your objectives during the time box. Execute results within your time box. Evaluate and adapt. Time-boxing is a delivery concept where work is confined to a fixed duration to be completed. The end date is set “in stone”, and can not be changed. The work to be delivered within the time-boxed period must have clear requirements for completion, and result in a clear work product that can be transitioned to the next stage of delivery. Benefits of Time-Boxing: Increase focus; Increase motivation; Works against procrastination; Avoids “perfectionism”;  Defeats analysis paralysis.  Drawbacks of Time-Boxing: Technicians compromise on solutions; Problems encountered often deferred (sometimes indefinitely); Requires focused resource commitment, which may pose an organizational challenge.

9. JAD Sessions JAD Session Best Practices: Plan the JAD sessions; Use an objective, trained Meeting Facilitator to guide the team to session objectives; Invite the right resources (decision-makers); Conduct the JAD sessions off-site; Use prototypes to create “real-time” feedback to facilitate quick decisions on system requirements and design; Joint Application Development (JAD) is a process that accelerates the design of information technology solutions. JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need to expedite the delivery of a jointly developed solution. Benefits of JAD Sessions: Reduced system development time and costs; Improved system quality and productivity; Improved business buy-in and acceptance; Business and Technology partnership; Drawbacks of JAD Sessions: Requires focused resource commitment, which may pose an organizational challenge; Without strong facilitation, JAD sessions can be disastrous.

10. Prototyping Prototyping Best Practices Iterative development cycles Can begin as paper-based Evolves to software-based Produces re-usable software that can be leveraged during construction. Prototyping is an iterative process to build a model of a business application. Prototypes are used to document and clarify the requirements and design of user interfaces, reports, business logic, and data models to successfully deliver the business application. Benefits of Prototyping: Reduced cost: Provides early feedback on the requirements at a time when the cost of making the changes are low; Reduced timeline: Reduces development time by producing models/formats/code which can be re-used during construction; Improved business buy-in and acceptance; Provides visible progress, improving team moral and sense of accomplishment; Exposes developers to potential system enhancements. Drawbacks of Prototyping: Can lead to insufficient analysis. Users expect the performance of the completed application to be the same as the prototype. Can cause systems to be left unfinished and/or implemented before they are ready. Sometimes leads to incomplete documentation. If sophisticated software prototypes are employed, the time saving benefit of prototyping can be lost. Review Requirements Prepare for Next Review Review Models Modify Prototype

11. Sprint Planning When planning the various sprints that will be delivered during the Sprint Phase of SDM-RAD, the project team must establish achievable delivery goals & objectives within each sprint package. The plan for each sprint package should include the business functions to be delivered to the end-users, as well as the expected deliverables required to support system documentation and end-user training. Detailed work hours should be estimated to complete each task/deliverable contained within each 30-day sprint package. Estimated work hours represent the estimate of actual working time needed to complete the task, if un-interrupted (i.e. it is NOT an estimate of DURATION). Sprint 2 Package • Function 3 • Function 4 • Function 5 • System Doc • Training Sprint 1 Package • Function 1 • Function 2 • System Doc • Training Sprint 3 Package • Function 6 • Function 7 • System Doc • Training Sprint 4 Package • Function 8 • Function 9 • Function 10 • System Doc • Training 30 Calendar Days 30 Calendar Days 30 Calendar Days 30 Calendar Days

12. Sprint Management Sprint Management Daily huddles (efficiently facilitated); 10-20 minutes Focus on REMAINING HOURS Daily re-forecasting based on REMAINING HOURS Adjust resource assignments as needed to re-gain lost time when forecasted to be off-schedule. Effective sprint management is critical to the successful delivery of projects using the SDM-RAD methodology. Each sprints is time-boxed to 30 calendar days, and dates can not be extended. Therefore, very “tight” management is required to monitor the progress of the team on a daily basis, with constant re-forecasting of estimated completion dates. Sprint management is driven by the REMAINING HOURS of work effort to complete the sprint tasks, as provided by the sprint task owners. A daily sprint “huddle” is recommended, which should last no more than 10-20 minutes. During this “huddle”, the Technology Manager asks each task owner the following questions: “Which sprint tasks (if any) did you complete yesterday? How many remaining hours are required for you to complete your active sprint tasks? Do you have any roadblocks (if so, quickly describe…the huddle is not meant to resolve the issues, just to communicate them)?

13. Sprint Burn-down chart

14. On-going SDM Support • SDM Resources: • SDM Website: www.ct.gov/doit/sdm • SDM Overview & Training • SDM Sample Deliverables • Online videos • SDM Feedback: • DOIT.SDMFeedback@ct.gov • SDM Feedback mailbox is reviewed on a weekly basis • Feedback is targeted to scheduled monthly maintenance releases

15. Thank you for attending! Any questions, comments or suggestions?? Trained Business & Technology Partners + = SDM Successful Projects

16. Document Attributes Document Revision History PMO USE ONLY State of Connecticut DOIT System Development Methodology (SDM) Document Name: RAD Training Presentation Used within the following SDM Methodologies: RAD