Clarification Document for myDEQ Web Portal Phase II Submitted to: Arizona Department of Environmental Quality 1100 West Washington Street Phoenix, Arizona 85007 In response to solicitation number ADEQ15-00004460 Submitted by:
Karsun Solutions, LLC 13655 Dulles Technology Drive, Suite 110 Herndon, VA 20171-4670 November 19, 2014
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
Table of Contents 1.
Project Background and Description .................................................................................... 4
2.
Implementation Strategy Overview ...................................................................................... 4
3.
What’s In ............................................................................................................................ 6
3.1 Phase I Transition-in, Code Migration & Deployment to Production .................................. 6 3.2 Phase II - Business Process and User Stories ........................................................................ 7 3.3 GoLean Pipeline Continuous Integration/Delivery Platform ................................................ 8 3.4 Artifacts ................................................................................................................................. 8 3.5 Operations and Maintenance Support ................................................................................... 8 3.6 Transition-Out ....................................................................................................................... 9 3.8 Warranty ................................................................................................................................ 9 4.
What’s Out .......................................................................................................................... 9
4.1 Business Process ................................................................................................................. 10 4.2 Production Environment Release Management .................................................................. 10 4.3 Phase I Functionality and Technical Debt........................................................................... 10 4.4 System Interfaces ................................................................................................................ 10 4.5 Help Desk ............................................................................................................................ 11 5.0 Client Actions .......................................................................................................................11 6.0 Value Added Capabilities......................................................................................................12
6.1 O&M after Last Iteration (Value Add #1) .......................................................................... 12 6.2 Function Breakdown Structure for Phase I and Phase II (Value Add #2) .......................... 12 6.3 Implementation Iterations after June 30th 2015 (Value Add #3)......................................... 13 7.0 Milestone Schedule ...............................................................................................................13 8.0 Schedule of Values ................................................................................................................14 9.0 Risk Management Plan and Risk Register .............................................................................15 10.0 Weekly Reporting ...............................................................................................................15
10.1 Milestone Schedule Accomplishments ............................................................................. 15 10.2 Change Order Tracker ....................................................................................................... 15 10.3 Risk Register ..................................................................................................................... 16 10.4 Performance Metrics ......................................................................................................... 16 2
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY 11.0 Stakeholders .......................................................................................................................17
11.1 ADEQ/ADOA ................................................................................................................... 17 11.2 Karsun Leadership team .................................................................................................... 17
3
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
1. Project Background and Description ADEQ is currently developing myDEQ, a web portal that will enable its customers to do permitting, billing and payments and data submission online. myDEQ will benefit over 18,000 businesses across Arizona. Currently, ADEQ conducts most of its business with customers using manual processes. It receives permit applications, bill payments, notifications, and compliance data via paper form for roughly 140 different business process types. These paper processes require non-value added time on the part of both ADEQ customers and ADEQ staff. Elapsed time from the customer beginning a paper creation to receiving final answer from ADEQ ranges from weeks to months. ADEQ anticipates savings in elapsed time ranging from 75% to 95% for each business process by implementing these processes on-line via a customer portal. In addition, ADEQ is designing the web applications to include error mitigation by walking customers through a series of questions rather than simply deploying on-line fillable forms. A reduction in elapsed time and errors for regulatory submissions will allow the regulated community to focus on creating jobs while also helping ADEQ keep the environment clean. In myDEQ Phase I, ADEQ has been building the foundational infrastructure and initial webapplications required to deliver the customer portal. Although some progress has been made in a relatively short amount of time during Phase I, ADEQ is approaching Phase II with a best value approach. ADEQ is seeking a subject matter expert to better avoid, predict and quickly address challenges associated with the prescribed middleware package, WSO2, as deployed within the ADEQ network environments. ADEQ is very new to deploying and hosting web-based applications and is looking for a Best Value Contractor to provide the requisite expertise for success of the myDEQ portal. Karsun Solutions submitted a proposal to ADEQ in response to the myDEQ Phase II RFP and participated in the interview process. Following the interview process, Karsun was determined the best value contractor and began the clarification phase. The clarification phase allowed the best value contractor and opportunity to clarify Karsun’s proposal, address any issues or risks, allow ADEQ to add any concerns and to prepare a Clarification Phase document. Karsun submits this Clarification document in addition to a risk management plan, risk register, detailed project schedule and the schedule of values.
2. Implementation Strategy Overview Karsun team will utilize the GoLean, a lean development and lean operations methodology, for the implementation of the myDEQ portal to deliver end-to-end agility. The GoLean methodology consists of a set of process, procedures, integrated tool-chain and rules. These will be tailored to implement a pipeline that will enable ADEQ to achieve continuous delivery and deployment whereby functions can be delivered either one function at a time or as a set of functions at a time, both to meet planned sequence of deliveries and out of sequence maintenance changes.
4
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
Karsun will also tailor its GoLean pipeline to mirror target environment being designed by ADEQ & ADOA for myDEQ Portal. The target environment deployed in AWS Cloud will have connections to ADEQ backend systems including AZURITE, jBilling, and SharePoint. The myDEQ portal is developed using the WSO2 suite of products including the Application Server, Business Process Server, Identity Server, and Data Services. These WSO2 products will run on WSO2’s Stratos that enables elastic scaling and management for these product instances. Karsun’s strategy is to mirror this environment as closely as possible during the development phase. We will use the same WSO2 products to build development and test environment in AWS Cloud and match their configuration as close as possible. However, this environment will mock interfaces to ADEQ/ADOA systems. Our approach will support iterations by functional sets from two weeks to four weeks based on business process targeted for that iteration. Our Continuous Integration (CI) strategy will use the following key principles to create the automation process with respect to software development and integration testing: ● Common Code Repository: A single Git repository will be setup for all project components. ● Build Automation: The capability to build and deploy the entire project using a single command will be provided. ● Deployment Automation: After a build finishes, the project will be deployed automatically to the test server. ● Test Automation: Once the project is deployed, all integration tests will be run automatically to confirm that it behaves as implemented and that no bugs/defects have been introduced. Most of the steps involved in software development and testing are automated. Automation allows integrating frequently, detecting errors quickly, and significantly reducing back-tracking to discover bugs/defects. Our Continuous Delivery (CD) strategy is closely related to CI and refers to the release of software iterations that pass the automated tests from test environment to a higher environment such as integration, user acceptance or production. We will implement the CD process to follow the change management process established by ADEQ and ADOA. By adopting GoLean pipeline, we significantly reduce risks, identify bugs quickly, and allow quicker deployment of software into production. Karsun will execute this contract by delivering business processes in six (6) project iterations. The iteration zero (0) will consist of a prototype to validate the environment and backend connections. This prototype will inform the final design decisions used in the data layer. The iteration one (1) consists of Phase I transition-in, migration of Phase I code for ADOA Platform as a Service (PaaS) and release into production on ADOA PaaS. Following four (4) iterations (#2, #3, #4, and #5) will deliver specific business processes in product increments, as listed in “Milestone Schedule” section later in this document. These product increments will be deployed 5
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
to production as the next three (3) releases (soon after iterations #2, #4 and #5). Karsun will provide full O&M support after release #1 is deployed to production. Additionally, Karsun has provided three value added capabilities described in section five.
3. What’s In The clarification process allows the contractor to define the specific scope included in their price. The high level scope of this project is as follows: ● Prototype to test the ADOA environment and external systems connections ● Transition-in Phase I including migrate Phase I to ADOA and deploy to production ● Develop, test, integrate and deploy business process listed below into the myDEQ Web Portal UAT environment ● Operate and Maintain myDEQ web portal in production (including Phase I and Phase II releases) through June 30, 2014 ● Perform Transition-out by training ADEQ staff to sustain the implemented business processes 3.1 Phase I Transition-in, Code Migration & Deployment to Production Karsun will transition-in the current Phase I code and migrate it to WSO2 Stratos so it can create an integrated myDEQ portal product that can be deployed, operated and maintained on the ADOA environment. Transition-in: A series of knowledge transfer sessions will be setup to gain understanding of the Phase I product. Below is the list of required sessions and transfer activities by which the transition will occur. Transition In EXDEP: Phase I requirements (User Stories) EXDEP: Phase I GUI Walkthrough and access EXDEP: VPN Access to ADEQ Resources including SVN EXDEP: Phase I Code walkthrough EXDEP: Phase I Technical Documentation and Walkthru EXDEP: Interfaces Documentation and Access EXDEP: Code Freeze and known Defects in ADEQ UAT EXDEP: Working UAT Environment in ADEQ and Access
Date required Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14
Code Migration: Karsun will restructure Phase I implementation code packages to group similar packages into a single folder. Currently, modules are split over several mismatched folders within SVN. Karsun will move logically common packages (e.g. web, service, utils etc.) into a single folder with single build deliverable. This will help with automation of deployment using GoLean pipeline and streamline deployment across different environments. 6
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
Karsun will re-factor Phase I code to enable its deployment into WSO2 Stratos, as configured in ADOA. Karsun will be careful to not introduce any regression in functionality seen in ADEQ UAT environment at the time of code transfer. However, Karsun will heavily depend on ADEQ UAT testing on ADOA environment to detect any regression. During ADOA UAT, if any issues or defects are detected in the Phase I code base that can be replicated in the Phase I UAT and they are required to be fixed before deployment to the production, then the change order process will be initiated for the resolution of these defects/issues. However, should a defect/issue of Phase I code base be detected and cannot be replicated in the Phase I UAT environment, Karsun will responsible for its resolution before deployment to production. For this reason, the current ADEQ UAT Environment should be up and running until the migration of Phase I code is complete and operational on ADOA environment to continue to test for discrepancies. Deployment into Production: Karsun will work with the ADOA team to support deployment of the Phase I code into production. Karsun will also work with ADOA team to establish the needed operational procedures for myDEQ portal on ADOA environment. Karsun will implement a process to enable escalation of Tier 1 user support to Tier 2 and Tier 3. Karsun will provide Tier 2 and Tier 3 support for the deployed Phase I code. Karsun will also establish a backlog of known defects and change request to be worked on by the O&M team. The initial backlog will contain all defects from UAT conducted on the ADEQ environment. 3.2 Phase II - Business Process and User Stories The following list identifies the business processes that are included in the myDEQ Web Portal Phase II project: 1. Global Standards User Stories 2. myDashboard and Phase II Landing page 3. RCRA - Get New EPA ID 4. RCRA - Edit EPA ID Registration Information 5. RCRA - De-activate EPA ID 6. RCRA - View Detail EPA ID 7. Single place selection 8. C&S - Get ATO and FOG 9. C&S - Terminate ATO 10. C&S - Submit Compliance Certification 11. C&S – Move/Add/Delete Business processes targeted for implementation in Phase II are estimated to be approximately 545 function points, as defined by International Function Point Analysis User Group (http://www.ifpug.org/). These 545 function points will be delivered in four iterations, with approximately 135 function points per iteration.
7
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
3.3 GoLean Pipeline Continuous Integration/Delivery Platform Karsun will provide a tailored GoLean Pipeline that includes the following tool-chain: Workflow – JIRA, JIRA Agile, Confluence Quality - Crucible, SonarQube, Fortify Integration Alerts/Hooks – Git, Jenkins, JIRA, ANSIBLE Dashboard - JIRA 3.4 Artifacts Karsun will create the following artifacts for Phase II. Prototype Results Document: This document describes the scope of prototypes architectural scenarios, findings of tests and alternative approaches to failed scenarios System Architecture Specification: This document describes the architecture of the Phase II application. This will be presented as conceptual, logical, implementation, data and deployment views of the design and rationale behind the design decisions Given-When-Then Acceptance Test scripts and test scenarios: Clarity on our understanding of requirements and business scenarios for testing Release document: Deployment documentation with list of new/changed functionality, installation, configuration, and performance monitoring, and tuning parameters Transition Documentation: This will include Operational Guide, Configuration Management Guide, and GoLean practice guides. Code: Karsun will fix known high and medium defects that are found prior to June 30, 2015. Defect Severity levels are as defined as: High: Any acceptance criteria not met Anything that causes data integrity issues (joint responsibility with ADEQ on external systems) Infrastructure (joint responsibility with ADOA & ADEQ): Server Errors, 404 and 500 Errors, connection issues. Anything that will stop the users from completing the business process Medium: Allows business process to be done with acceptable workaround Low: Cosmetic 3.5 Operations and Maintenance Support Karsun will provide ongoing application support and maintenance to ADEQ in support of myDEQ portal from release 1 on January 30th, 2015 to ADOA through June 30th, 2015. In particular, Karsun will accept O&M responsibility for the Phase I code base once it is deployed into production in the ADOA environment. In the event of changes, Karsun will execute software testing and configuration management efforts. Karsun will coordinate with the client ADOA and ADEQ - regarding system outages and hardware/firmware or interface issues.
8
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
The scope of operations and maintenance support through June 30th, 2015 is estimated to be 3985 hours. The following activities will be performed as part of operations and maintenance support. Maintenance Defect repairs Corrective Modifications to keep the software working in the face of changes in the Adaptive underlying infrastructure, interfaces, and so on Application changes to improve the usability of the application without Perfective adding new business functionality Minor changes to existing functionality Enhancements Operations Job execution, backup, restore, system monitoring. Housekeeping Tier 2 Help Desk Tier 2 is the first level of escalation (no code change) Tier 3 Help Desk Tier 3 is the second level of escalation (only code changes) 3985 hours (from Phase I code deployment through June 30, 2015) O&M Labor 3.6 Transition-Out Karsun will provide transition out services for myDEQ portal to ADEQ team to take over the O&M responsibilities at the end of contract term. The transition-out services are as follows 1. Provide skills & knowledge requirements for the ADEQ O&M team, expectedly three (3) months before the O&M training 2. Enable shadowing of Karsun’s O&M team by ADEQ O&M team through ad-hoc and non-disruptive interactions, expectedly a month before O&M training 3. Conduct two (2) weeks of co-located on-the-job training using training documents (see section 3.4 Artifacts) at ADEQ office in Phoenix, AZ 4. Karsun will develop and provide a “known-defect” qualification test to check the readiness of new ADEQ O&M staff. The “known-defect” test will imbed/identify known defects into the code base to test basic competency in different functional areas and compare the performance to average response and resolution time. If new staff need further training, Karsun will commit to providing additional dedicated training up to one week after June 30th 3.8 Warranty The warranty applies ONLY to the code base that Karsun Solutions created or modified and is not applicable for any code base created or modified by any other team. Karsun will adhere to quality processes to meet or exceed industry standard on defect density, which is 3 or less defects per function point. Karsun will provide warranty coverage for defects that exceeds the above quality threshold.
4. What’s Out The following items listed below are specifically not included in myDEQ Phase II project.
9
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
4.1 Business Process The following business processes are not included in scope for implementation during Phase II project. 1. Concrete Batch Plant - Get ATO and FOG 2. Concrete Batch Plant - Terminate ATO 3. Concrete Batch Plant - Submit Compliance Certification 4. Business process - “Hot Mix Asphalt - Get ATO & FOG” 5. Business process - “Hot Mix Asphalt - Submit Compliance Certification” 6. Business process - “Hot Mix Asphalt - Terminate ATO” 7. Customer - Manage Account 8. Landing Page – View SMRF Alerts 9. Landing Page – View My Notices 10. View Bills 11. Pay Bills 12. View Invoice Transactions History 4.2 Production Environment Release Management ADOA & ADEQ will be responsible for deploying to the production environment. This will be done by ADOA & ADEQ staff. 4.3 Phase I Functionality and Technical Debt Re-factoring of Phase I source code is not part of base contract. If any issues or defects are required to be fixed before Phase 1 code is deployed to production and it can be replicated in the Phase I UAT, then the change order process will be initiated for the resolution of these defects/issues. However, should a defect/issue of Phase I code base is detected and cannot be replicated in the Phase I UAT environment, Karsun will responsible for its resolution before it goes to production. 4.4 System Interfaces Karsun will perform analysis of currently available interfaces to external systems listed below. If there are modifications required, Karsun will collaborate with ADEQ team to document and provide to appropriate ADEQ team. Any such modification to external systems required to support Phase II business processes will be performed by ADEQ team. “Client Actions” section contains the dates by when these updated interfaces are required to be provided by ADEQ. As Karsun completes analysis of business requirements, Karsun may revise these dates. Here is list of external systems required for Phase II: AZURITE RICS jBilling CROMERR 10
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
AFIS EPA SharePoint AZMapper
4.5 Help Desk Karsun is not responsible for providing Tier 1 help desk support.
5.0 Client Actions The Client Actions are categorized into two groups: (a) Pre-planned actions with known dates (b) Actions that are needed on an ad-hoc basis depending on the project situation. Pre-Planned Actions Task Name Transition-In EXDEP: Phase I requirements (User Stories) and Walk-thru EXDEP: Phase I GUI Walkthrough and access EXDEP: VPN Access to ADEQ Resources including SVN EXDEP: Phase I Code walkthrough EXDEP: Phase I Technical Documentation and Walk-thru EXDEP: Interfaces Documentation and Access EXDEP: Code Freeze and known Defects in ADEQ UAT EXDEP: Working UAT Environment in ADEQ and Access Architecture/Environment EXDEP: ADOA support to Install WSO2 on Karsun AWS EXDEP: Joint Responsibility Matrix (JRM) between Karsun, ADEQ & ADOA Iteration #0 EXDEP: DOA Environment for Development and Access EXDEP: ADOA to DEQ Connectivity EXDEP: Acceptance - Iteration 0 Iteration #1 EXDEP: Phase I Code transfer to Karsun EXDEP: ADOA UAT Environment with connectivity to external interfaces EXDEP: UAT Test EXDEP: Deploy to Production Business Analysis #1 EXDEP: Baseline Iteration 2 User Stories Iteration #2 EXDEP: AZURITE & External Interfaces changes for EPA ID
Finish Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14 Mon 12/1/14 Tue 11/25/14 Thu 11/20/14 Thu 12/4/14 Wed 12/24/14 Fri 12/19/14 Thu 1/8/15 Wed 1/28/15 Thu 1/29/15 Mon 11/24/14 Wed 12/24/14 11
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
EXDEP: UAT Test EXDEP: UAT Acceptance - Iteration 2 EXDEP: Deploy to Production Business Analysis #2 EXDEP: Baseline Iteration 3,4,5 User Stories Iteration #3 EXDEP: AZURITE & External Interfaces changes for C & S -Part 1 EXDEP: UAT Test EXDEP: UAT Acceptance - Iteration 3 Iteration #4 EXDEP: AZURITE & External Interfaces changes for C&S - Part2 EXDEP: UAT Test EXDEP: UAT Acceptance - Iteration 4 Iteration #5 EXDEP: UAT Test EXDEP: UAT Acceptance - Iteration 5 EXDEP: Deploy to Production Transition-Out EXDEP: ADEQ to secure O&M resources Ad Hoc Actions Action Address clarification requests on user stories/non-functional requirements Provide review comments on submitted artifacts (see section 3.3) Set up complete environment access for new project team members Set up risk-escalation meetings with the right stakeholders Arrange access and set up meetings with requested product owners Resolve requests for ADOA exceptions
Wed 3/4/15 Wed 3/4/15 Thu 3/5/15 Mon 1/19/15 Thu 2/12/15 Tue 4/14/15 Tue 4/14/15 Wed 2/18/15 Wed 5/13/15 Wed 5/13/15 Tue 6/23/15 Tue 6/23/15 Thu 6/25/15 Fri 5/15/15 Due in 2 days 2 days 2 days 1 days 2 days 3 days
6.0 Value Added Capabilities 6.1 O&M after Last Iteration (Value Add #1) This includes three (3) months of operations and maintenance support after June 30th, 2015. This will help provide fast response for unexpected operational or user adoption issues. We will provide Corrective, Adaptive, Perfective, Enhancements support on all Phase I and Phase II implemented code Housekeeping, Tier 2 and Tier 3 Help Desk support 6.2 Function Breakdown Structure for Phase I and Phase II (Value Add #2) Our GoLean Function Breakdown Structure (FBS) as method for grooming the backlog leads to identifying missing requirements and aide development of domain-based service-oriented API 12
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
systems. GoLean FBS involves deep problem analysis with domain colored model using domain-neutral archetypes such as moment-intervals, party-place-thing, role, and catalogdescription. This value-add will provide: Enhanced visualization of the problem domain which in turn helps to uncover missing links across problem space Aide cohesive grouping of functionality into tiered level of granularity as follows: Level 1 Function/epic, which lies the foundation for baseline metric for product into function points, Level 2 - Fractal breakdown of each function into user stories, Level 3 - API specifications 6.3 Implementation Iterations after June 30th 2015 (Value Add #3) Karsun will implement the following Business Processes, estimated to be 48 Function points, as part of this value add: 1. Landing Page – View SMRF Alerts 2. Landing Page – View My Notices
7.0 Milestone Schedule The following milestone schedule is based on project start date of 11/17/2014. Each Milestone aligns with our schedule of values and identifies the scope that will be delivered and acceptance tested. Should any completed product not be testable in the ADOA environment due to external issues outside of Karsun control, a demonstration of the product capabilities will occur in the Karsun’s development environment. Once the product is deemed acceptable, ADEQ will allow Karsun Solutions to invoice and be paid 90% of the payment due for that scheduled value. The remaining 10% will be invoiced and paid once the acceptance testing is completed in the ADOA environment. Iteration
0
1
2
Scope Prototype to validate ADOA environment and connections to external systems including myDEQ Database, AZURITE, RICS, jBilling, CROMERR, SharePoint, and AZMapper Migration of current Phase I code from ADEQ WSO2 platform to ADOA managed WSO2 PaaS. Phase I Restructure: This includes restructuring of Phase I source code directory structure and migration to Git Integrate the code base between Phase I & II on a single configuration repository Refactor the Phase I code to technically enable to deployment into WSO2 Stratos. This will include code change to meet any mandatory ADOA PaaS rules/policies consideration GoLean Pipeline Continuous Integration/Delivery
UAT Start Acceptance 12/24/2014 12/24/2014
01/22/2015 01/28/2015
02/26/2015 03/04/2015 13
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
3
4
5
Platform Business process - “myDashboard and Phase II Landing Page” Business process - “RCRA - Get New EPA ID” Global Standard user stories applicable to Phase I functionality and above two business processes Business process - “RCRA - Edit EPA ID” Business process - “RCRA - De-Activate EPA ID” Business process - “RCRA - View Detail EPA ID” Business process - “Single Place Selection” Global Standard user stories applicable to above business processes Build Selenium based GoLean test automation to prevent regression to Phase I functionality Business process - “C&S - Get ATO & FOG” Global Standard user stories applicable to above business process Business process - “C&S - Submit Compliance Certification” Business process - “C&S - Terminate ATO” Global Standard user stories applicable to above business processes Business process - “C&S – Move/Add/Delete” Global Standard user stories applicable to above business processes
04/08/2015 04/14/2015
05/07/2015 05/13/2015
06/17/2015
06/23/2015
8.0 Schedule of Values The following table provides cost breakdown for the base contract and the three value adds:
Phase II (Development Cost + Phase I Migration + Risk Mitigation) O&M for 5 months (February, March, April, May, June) Total Base Value Add #1 - O&M post June (3 months) Value Add #2 - Domain Model & FBS Value Add #3 - Iterations to Complete Remaining Business Processes Grand Total #
1 2 3 4 5
Product/Deliverable
Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4
Date 12/24/2014 1/28/2015 3/4/2015 4/14/2015 5/13/2015
% of Total 6.2% 20.8% 13% 17% 13%
$5,178,931 $880,953 $6,059,884 $410,017 $ 83,040 $456,965 $7,009,905 Amount ($) $375,710 $1,260,456 $787,785 $1,030,180 $787,785 14
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
6 7 8 9 10 11
Iteration 5 O&M February O&M March O&M April O&M May O&M June
6/23/2015 2/28/2015 3/31/2015 4/30/2015 5/31/2015 6/30/2015
15% 3% 3% 3% 3% 3%
Total Base
$908,983 $181,797 $181,797 $181,797 $181,797 $181,797
$6,059,884
9.0 Risk Management Plan and Risk Register Karsun Solution’s Risk Management Plan (RMP) is provided in the clarification document package and is in alignment with CMMI best practices. This will also contain the initial risk register of all external risks that have been identified throughout the clarification phase. For each risk, a mitigation plan is outlined as well as a contingency plan and estimate of the cost of the contingency. If an identified risk materializes due to external factors beyond Karsun's control such that a proposed solution cannot work without significant modification, the additional measures required will be considered a change of scope. In such case, Karsun will identify and price out the additional requirement as the basis for a change order. Each change order will have defined acceptance criteria and will be approved by ADEQ before beginning work. Once the work in the change order is complete and accepted, the contractor will invoice for the full amount of the change order. The risk register and change order log will be updated and included in the weekly reports.
10.0 Weekly Reporting Karsun Solutions will provide a weekly report to ADEQ on Friday COB of each week. The weekly report will highlight accomplishments made by the team for the previous week. Additionally, the weekly report with track change orders, risks status and provide performance metrics. 10.1 Milestone Schedule Accomplishments The milestone schedule will be tracked and reported weekly. This will include the % complete, the initial schedule and the actual schedule. Should any deviation from the initial schedule occur, the risk associated with the deviation will be listed as the explanation for the deviation.
10.2 Change Order Tracker Change orders (CO) resulting from risks will be tracked and reported each week in the change order tracker (COT). The COT will include the initial award amount and all change orders that are estimated, waiting approval or approved. Each CO will be associated with the risk occurrence
15
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
and will include the CO number, description, date approved, days to complete, value and invoice status. 10.3 Risk Register The initially submitted risk register will be updated each week. The risk register contains a description of the risk, risk number, type of risk, impact and probability, mitigation plan, trigger, contingency plan should the risk materialize and the estimated cost of the contingency plan. If a risk materializes, the change order process will be initiated. 10.4 Performance Metrics Karsun will track and report weekly two metrics which will be key indicators for ADEQ to assess our progress and quality of our work. Quality Metric: Goal
Metric
Sub Metric
Definition
Source
Frequency
Show the Quality
Defect Removal efficiency
Severity 1, 2, 3, 4
JIRA Issue Log
End of each iteration
Identify the source of the defect External Risk Management
Defect Source
(Total defect found internally / total (Internal + external) defects found) in % Platform, Design, Test Script, Code
JIRA Issue Log
End of each iteration
Turnaround time for responding to vendor request
JIRA Issue Log
Event Driven Basis
Client Response
Response Time
Progress Metrics: Goal
Metric
Sub Metric
Definition
Source
Frequency
Demonstrable capability over time
User Story burn-down
Function points
JIRA Issue Log
Weekly
Uncertainty of estimates to complete over time Operations & Maintenance Support
Variance of Target date
Number of completed function points per unit time (throughput) over project duration ((Estimated target – initial planned target date ) / 5) * 100
Operations & Maintenance
Service Level Agreement (in hrs) Service Level
Response Time
Turn-around time for responding to Production support calls Resolution Turn-around time for Time resolving Production
Estimation Weekly Tool
Help Desk Tool / Defect Log Help Desk Tool /
Monthly
Monthly
16
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY
Support
Agreement (in hrs)
support calls
Defect Log
11.0 Stakeholders 11.1 ADEQ/ADOA Name Adams, Thomas (Tom) Adda, Sudhakar Cabrera, Misael Crowfoot, David (Dave) Heller, Gary Holt, Susan Kiran Chinnagangannagari Konuru, Raghu Mallick, Khursheed Marshall, Matthew (Matt) Matas, Randall (Randy) Russell, Glenn Shivnani, Suresh Tardiolo, Joseph (Joe) Tsen, Edward Vaddireddy, Manohar Vaidyanathan, Balaji Kashiwagi, Jacob
Role Product Owner (Customer, Place) ; AZURITE SME Deputy CIO Deputy Director, ADEQ (Executive Sponsor) Technical Architect (Infrastructure) CIO
Email
phone - office
[email protected]
602-771-4122
[email protected]
602-771-0360
[email protected]
602-771-2203
[email protected]
602-771-4796
[email protected]
602-771-2365
Procurement Officer Chief Technology Officer & Assistant Director Applications Architect Phase I Development Manager (Phase I Project Mgr.)
[email protected]
602-771-4526
[email protected]
602.542.2250
[email protected]
602-771-5346
[email protected]
602-771-4377
Infrastructure Engineer
[email protected]
602-771-4637
[email protected]
602-771-4849
[email protected]
602-771-4756
[email protected]
602-771-4653
[email protected]
602-771-4408
Product Owner (RCRA EPAID) Product Owner (Financial Bills, Transactions, Payments) Program Manager (Phase I) BA, UI Lead - Phase II User Stories and Mockups Applications Architect AZURITE - Technical SME Product Owner (C&S, CBP, Hot Mix Asphalt) Best Value Expert
[email protected] [email protected] 602-771-4183
[email protected]
602-771-4527
[email protected]
480 727-0753
11.2 Karsun Leadership team Name Mecheri, Kartik
Role Co-Founder Karsun Solutions
Email
phone - office
[email protected]
703.348-2990 17
ARIZONA DEPARTMENT OF ENVIRONMENTAL QUALITY Vaidyanathan, Sundar Gaudaen, Jan
Co-Founder Karsun Solutions Project Manager
Bham, Samir Sriraman, Badri Siddaraju Srikanthaiah
[email protected]
703. 589.0215
[email protected]
703.348.2992
Development Manager Software Architect
[email protected] [email protected]
571.217.5832 703. 348.0165
Application Lead
[email protected]
571-337-4858
18
Risk Management Plan Version 1.0
Corporate Office & Development Center Karsun Solutions LLC Headquarters 13655 Dulles Technology Drive, Suite 110 Herndon, VA 20171
Risk Management Plan
QMS/RMP/PRC/RMP-02
Document Information Author(s)
:
Document Status
:
Compliance Status
:
Badri Sriraman
Initial Release Information Role Reviewed By
Date
Name
Sign
Samir Bham
Approved by Released By
Document Control Information Total Pages
:
13
Review Period
:
As needed
Distribution
:
myDEQ team
Revision History Version No.
Release Date
Description of Change
1.0
10-Nov-2014
Baseline
Confidential to ADEQ
Approved By
Page 2 of 9
Risk Management Plan
QMS/RMP/PRC/RMP-02
Table of Contents 1.0 Purpose...................................................................................... 4 2.0 Entry Criteria ............................................................................. 4 3.0 Input.......................................................................................... 4 4.0 Responsibilities and Authorities ................................................. 4 5.0 Tasks ......................................................................................... 5 6.0 Validation .................................................................................. 9 7.0 Exit Criteria ................................................................................ 9 8.0 Output/Work Products............................................................... 9 9.0 Reference Documents ................................................................ 9 10.0 Risk Register (Clarification Phase) ............................................ 9
Confidential to ADEQ
Page 3 of 9
Risk Management Plan
1.0
QMS/RMP/PRC/RMP-02
Purpose The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving the objectives. Other objectives are:
Define Risk Management
Identify & Analyze the risks
Determine Risk sources and categories. Determine Risk Parameters Establish a Risk Management Strategy
Identify Risks Evaluate, Categorize & Prioritize the risks
Mitigate Risks
Develop Risk Mitigation Plan Implement Risk Mitigation Plan
In GoLean methodology, some risk management activities are inherently embedded in the method used. For example, some technical risks can be addressed by encouraging experimentation (early “failures”) or by executing a “spike” outside of the routine iteration. However, the Risk Management area encourages a more systematic approach to managing risks, both technical and non-technical. Such an approach is integrated into typical iteration and meeting rhythms; more specifically, during iteration planning, task estimating, and acceptance of tasks. 2.0
Entry Criteria
3.0
Starting of Project Planning activity (Clarification period) Whenever a risk is foreseen
Input The inputs for the Risk Management Plan are listed below:
4.0
Project Proposal Requirement Specification
Responsibilities and Authorities Role PM/PL
Confidential to ADEQ
Activity
Page 4 of 9
Risk Management Plan
QMS/RMP/PRC/RMP-02
1. To ensure that Risk Management implemented as defined in this procedure.
Senior Management
SQA
Relevant Stakeholders
5.0
is
1. To review the Risk Management on a periodic basis as per the SMR plan defined in the PMP & on event driven basis whenever risk factor is equal to or greater than 16
1. To verify compliance to Risk procedure during process audits
Management
1. To review the Risk Management / Mitigation plan as defined in this procedure.
Tasks When the project plan is prepared PM/PL shall examine all the factors that are likely to impact the ability of the project to meet its objectives. Such risks shall then be Identified, Categorized, Analyzed & a mitigation plan should be put in place. These Risks shall be monitored on a continuous basis throughout the development phase. In addition, Project Leader / Project Manager shall examine the changing situation over time to uncover circumstances that impact the ability of the project to meet its objectives. Such new risks shall also be updated in the project plan / risk management plan, whenever they are identified. The following guidelines give more details of the Risk Management process: 5.1
Prepare for Risk Management, identify & analyze the risks The first step towards Risk Management is to prepare a Risk Management plan & record the risk management strategy in the Integrated PMP. Risk management plan includes identifying the Sources of Risk, categorizing, analyzing & controlling the risks. 5.1.1 Identifying risk sources The risk sources are the fundamental drivers that cause risk within a project. These are the common sources from where
Confidential to ADEQ
Page 5 of 9
Risk Management Plan
QMS/RMP/PRC/RMP-02
the risks could origin. These sources of risk may be either internal or external to the project. 5.1.2 Evaluate, Categorizing and Prioritize the Risks Categorize the above sources & impact area of the risks into any of the following categories:
Internal (Project-Cost, Project-Effort, Project-Quality, Project-Schedule, Project-Scope) External (Competitors, Contractual, Regulatory, Security, Supplier, Other) Organizational (People, process, resources, security, systems, other) Any other risk specific to the project’s situation at hand
Identify the context / condition in which the risk is identified. 5.1.3 Defining the Risk Parameters & Risk Management strategy PM shall document the parameters used to analyze and categorize risks so that they are available for reference throughout the life of the project because circumstances change over time. Using these parameters, risks can easily be re-categorized and analyzed when changes occur. One way of providing a common basis for comparing dissimilar risks is assigning monetary values to risks (e.g., through a process of risk monetization). Determine the following Risk parameters for the identified risks using the following techniques: 5.1.3.1
Risk Probability or Likelihood of Risk Occurrence For each identified Risk, determine the Probability or likelihood of occurrence as one of the following 0-Essentially None, 1-Very Low, 2-Low. 3Somewhat. 4-Moderate, 5-Significant, 6-High. 7Very High. 8-Extremely High. 9-Catastrophic
5.1.3.2
Risk Consequence For each identified Risk, assess the impact of the risk & determine the severity in one of the following 0-Essentially None, 1-Very Low, 2-Low. 3-Somewhat. 4-Moderate, 5-Significant, 6-High. 7-Very High. 8-Extremely High. 9-Catastrophic For situations, where it is not possible to quantify the risk, the decision to determine the severity may be done on qualitative factors.
Confidential to ADEQ
Page 6 of 9
Risk Management Plan
QMS/RMP/PRC/RMP-02
5.1.4 Thresholds for Monitoring Compute the Risk Score for each identified risks: Risk Score = (Likelihood of Occurrence + Severity) /2 Define the Metrics for each of the Risks. These thresholds serve as the trigger for taking up appropriate timely corrective actions for mitigating the risks at hand. The recommended Risk threshold is when the Risk factor is equal to 4 & above and / or when the severity is greater than or equal to 4. 5.1.5 Risk Management Strategy The Risks shall be monitored on a continuous basis throughout the project. Any changes in the status of the risks or any new risks identified during the project development phase shall be updated in risk management plan. Risk is considered to be no longer applicable and closed if the anticipated period of occurrence has passed without the occurrence of the situation identified for the risk. 5.2
Risk Mitigation Plan 5.2.1 Risk Mitigation Planning A critical component of risk handling is risk mitigation planning. It involves determining the costs and benefits of implementing the risk mitigation plan for each risk. Risk handling strategies could be any of the following:
Risk Avoidance: E.g. Changing or lowering the requirements while still meeting the end user’s needs. Risk Control: E.g., taking active steps to minimize the risks. Risk transfer: reallocating requirements to lower the risks Risk Monitoring: Watching & periodically re-evaluating the risk for changes to the assigned risk parameters. Risk acceptance: Acknowledgement of the risk but not taking any action.
Examples of Risk Mitigation Plan simulation, alternate design etc.
could
be
Prototyping,
The recommended Risk Strategy is Risk Weight 1. Risk Score less than 4 and Severity less than 4
Confidential to ADEQ
Risk Management Strategy Risk Acceptance & Monitoring
Page 7 of 9
Risk Management Plan
QMS/RMP/PRC/RMP-02
2. Severity equal to or greater than 4 3. Risk Score equal to or greater than 16
Identify Mitigation Identify Mitigation
& Implement Plan & Implement Plan.
Risk Risk
A contingency plan will be documented, as appropriate and contingency trigger is identified. Contingency scenario is escalate to Senior Management in advance before is plan is executed upon. Person or group responsible for addressing each risk is identified. Risks & Mitigation plan will be discussed regularly with all the relevant stakeholders. Tasks in brief:
S No.
Task description
1.
Risk Management per this procedure
as
Role
When \ How
PM/PL
Throughout the development process.
Relevant stakeholders 2.
Review of Risks & Mitigation plan with relevant stakeholders
Whenever identified
risk
3.
Contingency plan through escalation to senior Management
Senior Management
As per the risk management strategy defined in the Risk Management Plan
4.
Review of Risk Management activities
Senior Management
Periodic with weekly
5.
Review of Risk Management activities
SQA
During Process Audits
basis
is
along
5.2.2 Implement Risk Mitigation Plans PM shall monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.
Confidential to ADEQ
Page 8 of 9
Risk Management Plan
6.0
Risk Register
Reference Documents
10.0
Project deliverable are given to customer All the risks are tracked to closure or the project is completed.
Output/Work Products
9.0
Risk Management plan is reviewed by Relevant Stakeholders & the Risk Management plan is put under Configuration Management Periodic Review of Risk Management activities by Senior Management SQA verifies compliance to Risk Management activities during process audits
Exit Criteria
8.0
Monitor Risk status: PM shall periodically monitor the risks for thresholds occurrence. Thresholds are assessed to check for the potential execution of a contingency plan. Initiate risk handling options when monitored risks exceed the defined thresholds: Risk shall be monitored for threshold. Risk mitigation actions shall be initiated and mitigation actions should be taken as per plan. Update Risk Log for each risk that includes a start date and anticipated completion date. PM shall ensure that resources to allow the successful execution of the risk handling activities are available.
Validation
7.0
QMS/RMP/PRC/RMP-02
CMMI for development Ver.1.3 Requirement Specification (User Stories) Project Execution Plan Weekly report to senior management
Risk Register (Clarification Phase)
ADEQ Risk Register V2.xlsx
Confidential to ADEQ
Page 9 of 9
Qualitative Rating
ID
Description
Type
1 ADEQ on-premises resources may not be accessible from ADOA PaaS environment Threat
Network latency to access any on-premises resource may be too high to meet 2 acceptable performance requirements
There may be rework and refactoring as ADOA deployment governance and deployment procedures continue to evolve and change over the period of 3 performance
Threat
Threat
ADEQ may be delayed in accepting a deliverable because ADEQ is not yet able to complete the validation in time due to external dependencies beyond Karsun's control or ADEQ wants additional defects fixed beyond the High severity defects that Threat 4 were closed.
Source Category
External-Contractual
External-Contractual
External-Contractual
External-Contractual
Impact Category
Project-Cost
Project-Effort
Project-Effort
Project-Quality
Risk Owner
ADOA
ADEQ
ADOA
ADEQ
Creation Date
Status
11/6/2014 Open
11/6/2014 Open
11/6/2014 Open
11/6/2014 Open
Close Date
Prob
2-Low
6-High
Impact
Score
6-High
5-Significant
4-Moderate 5-Significant
Project-Schedule ADEQ
11/6/2014 Open
4-Moderate 5-Significant
Requirements volatility due to feedback during analysis, development and acceptance due to user stories provided are too specific too early without the benefit 6 of feedback as product is built.
Threat
External-Contractual
Project-Schedule ADEQ
11/6/2014 Open
7-Very High 4-Moderate
Platform volatility and potential limitation of WSO2 can lead to alternatives that do 8 not meet non-functional requirements as specified.
Threat
External-Contractual
External-Contractual
Project-Schedule ADEQ
Project-Effort
WSO2
11/6/2014 Open
11/6/2014 Open
1) Identify key resource accessed by key functions and the response time need (apply 80/20 rule) 2) Verify with Prototypes the round trip with average load Risk Metric 1: Plan dates in schedule Risk Metric 2: Client Action response times for requests 5.5 Risk Metric 3: UI response time requirements Unacceptable response time
1) Establish a defect density thresholds per functions 2) Share Product Defect results and trends over ietrations Metric 1: Client Action response time/Project plan date Metric 2: Defect Density Metric 3: Defect Severity and trend over time 4.5 Metric 4: Test Pass/Fail Results
External-Contractual
4-Moderate 4-Moderate
6-High
4-Moderate
Contingency Trigger
1) Identify every resource to access 2) Identify & escalate networking needs (parties, protocols, ports, bandwidth, perimeter security, DNS) 3) Imitate Infrastructure change request 4) Verify with Prototypes Risk Metric 1: Plan dates in schedule Access as requested is not Risk Metric 2: Client Action response times for feasible given technical or security or policy constraints 4 requests
3-Somewhat 4-Moderate
Threat
Threat
Risk Response (open/issue) or Closure Reason
1) Provide guidelines to ADOA on deployment procedures from GoLean pipeline 2) Identify a liaison from ADOA to continually follow up. 3) Be part of ADOA governance development activities and team Risk Metric: Client action response times for 3.5 ADOA support requests
Schedule had to be compressed by 25% to include the maximum scope possible, 5 this will force many overlapping parallel activities affecting the critical path
Depending on the code state of Phase I, refactoring may be required to run Phase I 7 code on ADOA PaaS which may take more time than scheduled.
Risk Response
1) Use the ExcelerPlan tool to apply the actuals every week to watch "Uncertainty of estimates to complete (ETC) over time" 2) Explore the opportunity to add more resources Metric 1: Uncertainty of estimates to complete (ETC) over time 4.5 Metric 2 : Demonstrable capability over time 1) Baseline requirements as they arrive in JIRA 2) Develop product in small increments of functionality allowing more time for requirements backlog to change 3) Use test automation to eliminate overhead of regression testing enabling faster feedback cycle 4) Use an acceptance team to develop acceptance criteria in a “given-when-then” constructs to allow for missing requirements before development starts Metric 1: Functional volumetric for every change after baseline 5.5 Metric 2: ETC and Target date change 1) Asses the Code gaps for deployment in Stratos 2) Assess the project deployment structure changes 3) Add resources if it will help keep the schedule 4 4) ETC date for Iteration 1
1)Capture clear non-functional requirements as a quality attribute so we can apply WSO2 experience to identify product extensions 2)Include non-functional scenarios including security and performance in our test automation harness and execute test suite at completion of each iteration. 3) Leverage WSO2 partnership to collaborate on product extensions solutions to meet nonfunctional requirements not supported in platform 4) Design alternatives if the issue is detected early Metric 1: Defect category or injection point Metric 2: WSO2 Ticket lead/response times 5 Metric 3: Plan date, critical path on Schedule
Contingency Cost Cost (Estimated % of Base)
Schedule (Estimated % of Base)
1) Identify alternative path of implementation for Phase I & II (a) Introduce a DB on cloud (b) Create Webservices on premises (c) Refactor data layer to use the webservices & cloud DB 2) Karsun will identify and price out the additional requirement as the basis for a change order
20%
20%
1) Investigate design change to remove the resource access from UI (Caching or virtual DB technology) 2) Implement caching mechanisms & asynchronous messaging with chosen technology 3) Migrate data as necessary 4) Karsun will price out the above additional requirement as the basis for a change order
20%
20%
Contingency Plan
Karsun determines that there is rework needed to meet the new procedure or change in procedure and cumulative impact of such changes in project has exceeded 2% of the effort
1) Estimate the rework based on trend 2) Karsun will identify and price out the additional requirement as the basis for a change order 5-10% 1) ADEQ agrees to pay Karsun for the deliverable, but shall withhold 10% of the agreed price pending completion of final testing and acceptance 2) If possible, make minor schedule and scope adjustments to meet the specific need without change to contract 3) If not, Karsun will identify scope $32,046/ day Client Action response date or change and price out the (based on per Project milestone date additional requirement as the work day cost on assigned to ADEQ is exceeded basis for a change order base)
10-15%
As delayed
ExcelerPlan target date shifts 1) Karsun will identify and price more then 5% of the remaining out the additional requirement as time to June 30 the basis for a change order
5%
5%
ExcelerPlan target date shifts 1) Karsun will identify and price more then 5% of the remaining out the additional requirement as time to June 30, 2015 the basis for a change order
5% each time
5%
ExcelerPlan target date shifts for Value add is more then 5% of the remaining time to February release
1) Initiate change to release plan 2) Alternatively consider, going production on ADEQ environment 3) Karsun will identify and price out the additional impact as the basis for a change order
5%
10%
WSO2 cannot resolve the issue or delay in response has a potential of 5% slip in project schedule
1) Identify alternative implementation strategy 2) Estimate the effort and change to plan 3) Initiate contract modification
5-10% depending on the severity
10% -15%
ADEQ Stakeholder/SMEs are not able to meet the client action response times 9 requested at the start
Threat
External-Contractual
Project-Schedule ADEQ
11/6/2014 Open
2-Low
ADOA may not be able to establish the required production monitoring harness (alarms, logging, access and recovery scripts) in order to provide needed 10 observability and debug ability required for level 2&3 support
Threat
External-Contractual
Project-Effort
11/6/2014 Open
4-Moderate 5-Significant
ADEQ may reverse its decision to deploy in ADOA and require deployment on ADEQ Threat 11 environment
External-Contractual
Project-Cost
ADOA
ADEQ
11/6/2014 Open
12 Integration with external systems may require more effort than initially estimated
Threat
External-Supplier
Project-Effort
ADEQ
11/6/2014 Open
O&M support may larger than initially estimated due to complexity in ADOA 13 environment or Phase I technical debt/code state transitioned-in
Threat
External-Contractual
Project-Schedule ADEQ
11/10/2014 Open
Phase I code will be deployed initially without automated test harness, there may be 14 regression and/or peformance issues post production
ADEQ stakeholder team may want to monitor and control details of project planning and execution than weekly meetings and hence cause disruption to development 15 team
Planned ADEQ O&M team may not be suffciently skilled and/or require more effort 16 from Karsun team during shadowing phase
ADEQ stakeholder team may want to dictate or change design decisions of product 17 that may not be suitable and cause rework/disruption to the development team
Threat
Threat
Threat
Threat
External-Contractual
External-Contractual
External-Contractual
External-Contractual
Project-Schedule ADEQ
Project-Schedule ADEQ
Project-Schedule ADEQ
Project-Schedule ADEQ
11/14/2014 Open
11/17/2014 Open
11/17/2014 Open
11/18/2014 Open
4-Moderate
1-Very Low 7-Very High
1) Track the response times by requests to identify potential sources of issues 3) Replan development of different functions if necessary 2) Track the impact to critical path on the schedule (if any) $32,046/ day 3) Utilize the weekly status meeting to resolve ExcelerPlan target date shifts 1) Initiate change to reduce Scope (based on per Metric 1: Stakeholder response time more then 5% of the remaining of the project. Karsun will price out work day cost on on basis for a change order base) 3 Metric 2: Critical Path and Target date change time to June 30 1) Identify alternative way to 1) Identify early the needed monitoring achieve the observability and harness and level of access debug ability in the design 2) Provide advisory input by being part of 2) Estimate the change in effort, ADOA activities ADOA does not provided the cost and scope and price out the 3) Test the capability made available for needed monitors or needed additional requirement as the 5-10% depending access basis for a change order on the severity 4.5 monitoring
4
ADEQ decides to revert its decision to go to ADOA due to external reasons to the project
1) Initiate change to release plan 2) Karsun will identify and price out the additional requirement as the basis for a change order 3) Initiate plan to deploy Phase 2 on ADEQ
3-Somewhat 4-Moderate
1) Engage the external stakeholder to identify the required APIs, data structures and nonfunctional technical constraints 2) Prioritize development of the integration user stories as soon as possible to allow for timely resolution of any interface issues 3) Use tools to mock the interface to delink dependency on external system during development as much as possible 4) Separately track and manage integration testing and release coordination with external teams as required ExcelerPlan target date shifts 1) Karsun will identify and price Metric 1: Uncertainty of estimates to complete more then 5% of the remaining out the additional requirement as time to June 30 the basis for a change order 3 (ETC) over time based on actual effort 1) Identify alternative ways to achieve the support ADOA unable to afford 2) Estimate the change in effort, changes/flexibility to make cost and scope and price out the Obtain intput on clarification document before environment the environment additional requirement as the changes basis for a change order 3.5 weekly meeting and resolve them
4-Moderate 5-Significant
1) Utilize performance test harness from ADOA to check basic access 2) Stop Phase II code changes after UAT freeze on December 19th Performance is deemed 3) Utilize Phase II development team to make unaccptable in limited basic testing 4.5 any fixes during manual tesing by ADEQ
5-Significant 5-Significant
1) Jointly establish the length and details of the weekly meeting between ADEQ and Karsun project team 2) As much as possible, provide online access to important metrics relating to risks 3) Use email and/or JIRA to track any request made by ADEQ 3) Engage leadership of ADEQ, Karsun & PSRG to escalate/resolve improvements to When client-initiated requests communication with out disruption to are higher than client action requests in an iteration 4.5 development team
2-Low
4-Moderate
4-Moderate 4-Moderate
1) Provide the required skills during hiring by ADEQ 2) Identify external traning needs based on identified individuals 3) Capture source and effort for client-initiated request in this regard to understand better ways to provide with out disuption to development team 4 Metric: Client Request ticket (source & effort)
4-Moderate 4-Moderate
1) Document the rationale in the architecture document 2) Include WSO2 expertise during 4 architectecture analysis
5%
As delayed
10% -15%
10%
5% -10% 5% -10% depending on the depending on the interface interface
2% - 3%
0%
1) Change the release schdule 2) Build selenium test harness 3) Conduct performance test and fine-tune the ADOA PaaS environment
10%
15%
1) Identify if new metric on JIRA can meet most of client need with little effort to development team 2) If not, estimate the change in effort, cost and/or scope and price out the additional management need as the basis for a change order
10%
10%
60% of O&M
0%
10%
10%
1) Engage leadership of ADEQ, Karsun & PSRG to escalate/resolve educate needs When effort to meet clientwith little disruption to dev and initiated requests causes delay Ops team to deployment or development 2) If not resolved, recommend activities value-add for post-june support 1) Identify alternative ways to achieve the concurrence When architecture or design is 2) Estimate the change in effort, not accepted and require cost and scope and price out the rework based on alternatives additional requirement as the arrived basis for a change order
ID
Task Task Name Mode 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Start
Finish
Duration
Aug 3, '14
Sep 21, '14 S
Project Start Date Transition-In EXDEP:Phase 1 requirements (User Stories) and Walk-thru EXDEP:Phase 1 GUI Walkthrough and access EXDEP:VPN Access to ADEQ Resources including SVN EXDEP:Phase 1 Code walkthrough EXDEP:Phase 1 Technical Documentation and Walk-thru EXDEP:Interfaces Documentation and Access EXDEP:Code Freeze and known Defects in ADEQ UAT EXDEP:Working UAT Environment in ADEQ and Access Architecture/Environment EXDEP:ADOA support to Install WSO2 on Karsun AWS EXDEP:Joint Responsibility Matrix (JRM) between Karsun, ADEQ & ADOA
Wed 11/19/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14 Wed 11/19/14 Fri 11/21/14 Tue 11/25/14
Wed 11/19/14 Fri 12/19/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14 Thu 12/18/14 Mon 12/1/14 Tue 11/25/14
0 days 15 days 0 days 0 days 0 days 0 days 0 days 0 days 0 days 0 days 20 days 5 days 0 days
Tailor GoLean Pipeline Setup Karsun AWS, WSO2 environment Iteration #0 EXDEP:DOA Environment for Development and Access EXDEP:ADOA to DEQ Connectivity Develop Prototype Testing in ADOA Dev Environment Prepare Prototype results document EXDEP:Acceptance - Iteration 0 Iteration #1 EXDEP:Phase 1 Code transfer to Karsun Phase 1 Code Analysis Phase 1 Project Restructure EXDEP:ADOA UAT Environment with connectivity to external interfaces
Wed 11/19/14 Wed 11/19/14 Thu 11/20/14 Thu 11/20/14 Wed 11/26/14 Wed 11/26/14 Fri 12/12/14 Tue 12/23/14 Wed 12/24/14 Thu 12/11/14 Fri 12/19/14 Thu 12/11/14 Wed 12/24/14 Thu 1/8/15
Thu 12/18/14 Thu 12/18/14 Wed 12/24/14 Thu 11/20/14 Thu 12/4/14 Thu 12/11/14 Mon 12/22/14 Tue 12/23/14 Wed 12/24/14 Thu 1/29/15 Fri 12/19/14 Wed 12/31/14 Thu 1/8/15 Thu 1/8/15
20 days 20 days 22 days 0 days 5 days 10 days 7 days 1 day 0 days 31 days 0 days 13 days 8 days 0 days
Mon 1/5/15 Wed 1/21/15 Thu 1/22/15 Wed 1/28/15 Thu 1/29/15
Tue 1/20/15 Wed 1/21/15 Wed 1/28/15 Wed 1/28/15 Thu 1/29/15
12 days 1 day 5 days 0 days 0 days
Phase 1 Code Changes for WSO2/Stratos Deploy to UAT EXDEP:UAT Test EXPDEP:UAT Acceptance - Iteration 1 EXDEP:Deploy to Production Page 1
S
ID
Task Task Name Mode 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
Start
Finish
Duration
Aug 3, '14
Business Analysis #1 EXDEP:Baseline Iteration 2 User Stories Build Given-When-Then #1 Identify Business Scenario #1 Prepare Test data/Mock Interfaces #1 Iteration #2 EXDEP:AZURITE & External Interfaces changes for EPA ID Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 2 EXDEP:Deploy to Production Business Analysis #2 EXDEP:Baseline Iteration 3,4,5 User Stories Build Given-When-Then #2 Identify Business Scenario #2 Prepare Test data/Mock Interfaces #2 Iteration #3 EXDEP:AZURITE & External Interfaces changes for C & S -Part 1 Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP: UAT Test EXDEP:UAT Acceptance - Iteration 3 Iteration #4 EXDEP:AZURITE & External Interfaces changes for C&S - Part2 Build Automation Script Develop Function Page 2
Mon 11/24/14 Mon 11/24/14 Mon 11/24/14 Tue 12/9/14 Tue 12/16/14 Fri 12/19/14 Fri 12/19/14 Mon 12/29/14 Fri 1/9/15 Wed 1/14/15 Wed 2/11/15 Wed 2/25/15 Thu 2/26/15 Wed 3/4/15 Thu 3/5/15 Mon 1/19/15 Mon 1/19/15 Mon 1/19/15 Fri 1/30/15 Fri 2/13/15 Mon 2/9/15 Mon 2/9/15 Fri 2/13/15 Fri 2/27/15 Wed 3/4/15 Wed 3/25/15 Mon 4/6/15 Wed 4/8/15 Tue 4/14/15 Fri 2/13/15 Fri 2/13/15 Mon 3/30/15 Mon 4/6/15
Tue 1/13/15 Mon 11/24/14 Mon 12/8/14 Mon 12/15/14 Tue 1/13/15 Thu 3/5/15 Wed 12/24/14 Tue 1/6/15 Thu 2/5/15 Tue 2/10/15 Tue 2/24/15 Wed 2/25/15 Wed 3/4/15 Wed 3/4/15 Thu 3/5/15 Thu 3/26/15 Mon 1/19/15 Thu 1/29/15 Thu 2/12/15 Thu 3/26/15 Tue 4/14/15 Thu 2/12/15 Thu 2/26/15 Thu 3/19/15 Tue 3/24/15 Fri 4/3/15 Tue 4/7/15 Tue 4/14/15 Tue 4/14/15 Wed 5/13/15 Wed 2/18/15 Fri 4/3/15 Fri 4/17/15
Sep 21, '14 S
31 days 0 days 9 days 5 days 17 days 50 days 4 days 5 days 20 days 20 days 10 days 1 day 5 days 0 days 0 days 49 days 0 days 9 days 10 days 30 days 47 days 4 days 10 days 15 days 15 days 8 days 2 days 5 days 0 days 64 days 4 days 5 days 10 days
S
ID
Task Task Name Mode 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85
Start
Finish
Duration
Aug 3, '14
UI/UX Testing Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 4 Iteration #5 Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 5 EXDEP:Deploy to Production Buffer Days Transition-Out Skills and Knowledge Requirements for ADEQ O&M Team EXDEP: ADEQ to secure O&M resources Training Transition
Thu 4/9/15 Thu 4/23/15 Tue 5/5/15 Thu 5/7/15 Wed 5/13/15 Tue 4/28/15 Tue 4/28/15 Tue 5/5/15 Fri 5/8/15 Thu 6/4/15 Tue 6/16/15 Wed 6/17/15 Tue 6/23/15 Thu 6/25/15 Tue 6/23/15 Fri 3/20/15 Fri 3/20/15 Fri 5/15/15 Mon 6/15/15 Wed 6/24/15
Page 3
Wed 4/22/15 Mon 5/4/15 Wed 5/6/15 Wed 5/13/15 Wed 5/13/15 Thu 6/25/15 Mon 5/4/15 Fri 5/29/15 Wed 6/3/15 Mon 6/15/15 Tue 6/16/15 Tue 6/23/15 Tue 6/23/15 Thu 6/25/15 Tue 6/23/15 Tue 6/30/15 Fri 3/20/15 Fri 5/15/15 Tue 6/23/15 Tue 6/30/15
Sep 21, '14 S
10 days 8 days 2 days 5 days 0 days 41 days 5 days 18 days 18 days 8 days 1 day 5 days 0 days 0 days 0 days 72 days 0 days 0 days 7 days 5 days
S
'14 S
Nov 9, '14 M
T
Dec 28, '14 W
T
F
Feb 15, '15 S
11/19 11/25 11/25 11/25 11/26 12/1 12/2 12/19 12/19
11/25
11/20
12/24 12/19
1/8
1/28 1/29 Page 4
S
Apr 5, '15 M
T
May 24, '15 W
T
Jul 12, '15 F
S
'14 S
Nov 9, '14 M
T
Dec 28, '14 W
T
F
Feb 15, '15 S
S
Apr 5, '15 M
11/24
3/4 3/5 1/19
4/14
Page 5
T
May 24, '15 W
T
Jul 12, '15 F
S
'14 S
Nov 9, '14 M
T
Dec 28, '14 W
T
F
Feb 15, '15 S
S
Apr 5, '15 M
T
May 24, '15 W
Jul 12, '15 F
T
5/13
6/23 6/25 6/23 3/20 5/15
Page 6
S
ID
TaskTask Name Mode 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
Project Start Date Transition-In EXDEP:Phase 1 requirements (User Stories) and Walk-thru EXDEP:Phase 1 GUI Walkthrough and access EXDEP:VPN Access to ADEQ Resources including SVN EXDEP:Phase 1 Code walkthrough EXDEP:Phase 1 Technical Documentation and Walk-thru EXDEP:Interfaces Documentation and Access EXDEP:Code Freeze and known Defects in ADEQ UAT EXDEP:Working UAT Environment in ADEQ and Access Architecture/Environment EXDEP:ADOA support to Install WSO2 on Karsun AWS EXDEP:Joint Responsibility Matrix (JRM) between Karsun, ADEQ & ADOA Tailor GoLean Pipeline Setup Karsun AWS, WSO2 environment Iteration #0 EXDEP:DOA Environment for Development and Access EXDEP:ADOA to DEQ Connectivity Develop Prototype Testing in ADOA Dev Environment Prepare Prototype results document EXDEP:Acceptance - Iteration 0 Iteration #1 EXDEP:Phase 1 Code transfer to Karsun Phase 1 Code Analysis Phase 1 Project Restructure EXDEP:ADOA UAT Environment with connectivity to external interfaces Phase 1 Code Changes for WSO2/Stratos Deploy to UAT EXDEP:UAT Test EXPDEP:UAT Acceptance - Iteration 1 EXDEP:Deploy to Production Business Analysis #1 EXDEP:Baseline Iteration 2 User Stories Build Given-When-Then #1 Identify Business Scenario #1
Start
Finish Sep 21, '14Nov 9, '14 Dec 28, '14Feb 15, '15 Apr 5, '15 May 24, '15Jul 12, '15 S S M T W T F S S M T W T F S
Wed 11/19/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14 Wed 11/19/14 Fri 11/21/14 Tue 11/25/14
Wed 11/19/14 Fri 12/19/14 Tue 11/25/14 Tue 11/25/14 Tue 11/25/14 Wed 11/26/14 Mon 12/1/14 Tue 12/2/14 Fri 12/19/14 Fri 12/19/14 Thu 12/18/14 Mon 12/1/14 Tue 11/25/14
Wed 11/19/14 Wed 11/19/14 Thu 11/20/14 Thu 11/20/14 Wed 11/26/14 Wed 11/26/14 Fri 12/12/14 Tue 12/23/14 Wed 12/24/14 Thu 12/11/14 Fri 12/19/14 Thu 12/11/14 Wed 12/24/14 Thu 1/8/15
Thu 12/18/14 Thu 12/18/14 Wed 12/24/14 Thu 11/20/14 Thu 12/4/14 Thu 12/11/14 Mon 12/22/14 Tue 12/23/14 Wed 12/24/14 Thu 1/29/15 Fri 12/19/14 Wed 12/31/14 Thu 1/8/15 Thu 1/8/15
Mon 1/5/15 Wed 1/21/15 Thu 1/22/15 Wed 1/28/15 Thu 1/29/15 Mon 11/24/14 Mon 11/24/14 Mon 11/24/14 Tue 12/9/14
Tue 1/20/15 Wed 1/21/15 Wed 1/28/15 Wed 1/28/15 Thu 1/29/15 Tue 1/13/15 Mon 11/24/14 Mon 12/8/14 Mon 12/15/14
Page 1
11/19 11/25 11/25 11/25 11/26 12/1 12/2 12/19 12/19
11/25
11/20
12/24 12/19
1/8
1/28 1/29 11/24
ID
TaskTask Name Mode 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
Prepare Test data/Mock Interfaces #1 Iteration #2 EXDEP:AZURITE & External Interfaces changes for EPA ID Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 2 EXDEP:Deploy to Production Business Analysis #2 EXDEP:Baseline Iteration 3,4,5 User Stories Build Given-When-Then #2 Identify Business Scenario #2 Prepare Test data/Mock Interfaces #2 Iteration #3 EXDEP:AZURITE & External Interfaces changes for C & S -Part 1 Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP: UAT Test EXDEP:UAT Acceptance - Iteration 3 Iteration #4 EXDEP:AZURITE & External Interfaces changes for C&S - Part2 Build Automation Script Develop Function UI/UX Testing Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 4 Iteration #5 Build Automation Script Develop Function UI/UX Testing
Start
Finish Sep 21, '14Nov 9, '14 Dec 28, '14Feb 15, '15 Apr 5, '15 May 24, '15Jul 12, '15 S S M T W T F S S M T W T F S
Tue 12/16/14 Fri 12/19/14 Fri 12/19/14 Mon 12/29/14 Fri 1/9/15 Wed 1/14/15 Wed 2/11/15 Wed 2/25/15 Thu 2/26/15 Wed 3/4/15 Thu 3/5/15 Mon 1/19/15 Mon 1/19/15 Mon 1/19/15 Fri 1/30/15 Fri 2/13/15 Mon 2/9/15 Mon 2/9/15 Fri 2/13/15 Fri 2/27/15 Wed 3/4/15 Wed 3/25/15 Mon 4/6/15 Wed 4/8/15 Tue 4/14/15 Fri 2/13/15 Fri 2/13/15 Mon 3/30/15 Mon 4/6/15 Thu 4/9/15 Thu 4/23/15 Tue 5/5/15 Thu 5/7/15 Wed 5/13/15 Tue 4/28/15 Tue 4/28/15 Tue 5/5/15 Fri 5/8/15 Page 2
Tue 1/13/15 Thu 3/5/15 Wed 12/24/14 Tue 1/6/15 Thu 2/5/15 Tue 2/10/15 Tue 2/24/15 Wed 2/25/15 Wed 3/4/15 Wed 3/4/15 Thu 3/5/15 Thu 3/26/15 Mon 1/19/15 Thu 1/29/15 Thu 2/12/15 Thu 3/26/15 Tue 4/14/15 Thu 2/12/15 Thu 2/26/15 Thu 3/19/15 Tue 3/24/15 Fri 4/3/15 Tue 4/7/15 Tue 4/14/15 Tue 4/14/15 Wed 5/13/15 Wed 2/18/15 Fri 4/3/15 Fri 4/17/15 Wed 4/22/15 Mon 5/4/15 Wed 5/6/15 Wed 5/13/15 Wed 5/13/15 Thu 6/25/15 Mon 5/4/15 Fri 5/29/15 Wed 6/3/15
3/4 3/5 1/19
4/14
5/13
ID
TaskTask Name Mode 75 76 77 78 79 80 81 82 83 84 85
Integration Testing Deploy to UAT EXDEP:UAT Test EXDEP:UAT Acceptance - Iteration 5 EXDEP:Deploy to Production Buffer Days Transition-Out Skills and Knowledge Requirements for ADEQ O&M Team EXDEP: ADEQ to secure O&M resources Training Transition
Start
Finish Sep 21, '14Nov 9, '14 Dec 28, '14Feb 15, '15 Apr 5, '15 May 24, '15Jul 12, '15 S S M T W T F S S M T W T F S
Thu 6/4/15 Tue 6/16/15 Wed 6/17/15 Tue 6/23/15 Thu 6/25/15 Tue 6/23/15 Fri 3/20/15 Fri 3/20/15 Fri 5/15/15 Mon 6/15/15 Wed 6/24/15
Page 3
Mon 6/15/15 Tue 6/16/15 Tue 6/23/15 Tue 6/23/15 Thu 6/25/15 Tue 6/23/15 Tue 6/30/15 Fri 3/20/15 Fri 5/15/15 Tue 6/23/15 Tue 6/30/15
6/23 6/25 6/23 3/20 5/15