TECH A Look at Software Development Analyze Phase Date: 11/13/2013 Team members: Travis W. Gillison

Brief Review of Project Charter The goal of this project is to reduce the amount of time it takes to develop a software solution from an awarded bid to a deliverable. Projects are too lengthy, and we are taking too much time for a project and also spending too much, resulting in a low ROI. We want to significantly decrease the amount of time for a project’s completion, without sacrificing quality.

CTQ Trees KPOVSKPIVS

Data Collection Recap A major project was analyzed from award date to official delivery to customer and handed off to support Key points of measurements taken: Amount of time (in days) for DP to be created Amount of time (in days) for DP to be prioritized Amount of time (in days) DP sits in queue Amount of development time (in days) Amount of time for “push” (in hours) Amount of QA time (in days) Amount of documentation creation time (in days) Amount of time to implement (in days) Amount of time to conduct hand-off (in days) Record number of support calls after project over 6 month window

Project Planning Target = 17 days Actual = 28 days; lag time of 11 days

Project Deliverables Target = 180 Actual = 249 days; lag time of 69 days

Project Finalization Target = 10 days Actual = 14 days; lag time of 4 days

Support Calls 1st shift calls = 13.28% 2nd shift calls = 9.15% 3rd shift calls = 8.74%

Pie Chart – Total Time

Fishbone Diagram 1 – Code Completion Time CODE COMPLETION TIME Documentation Amount of Billable HoursAmount of SCRs Misunderstood Requirements Rework High pricing Poor estimate of development time Exceeds Contracted amount Errors in Document Misunderstood Features Bad Design

Fishbone Diagram 2 – Test Case Creation and Execution TEST CASE CREATION AND EXECUTION Builds/Installations Length of Time for QA ProcessNumber of Reported Defects Delays in Defect Processing Rework verifying new builds Poor communication with development Test Cases do not follow ISO structure Misunderstood functionality Software does not install properly Broken builds Incorrect usage of features resulting in false defect reports

Fishbone Diagram 3 – Implementation Time IMPLEMENTATION TIME Support Hand-off Number of Calls Taken by SupportLength of Installation Time Delays with ISP and telecom provider Customer’s environment not up to specifications Misunderstood implementation requirements Engineering Special development Defects reported in the field Internal environments do not match customer specs Insufficient training Customer has insufficient bandwidth or network bottlenecks

Conclusion After looking at the data, it appears that implementation times and support hand-offs are the closest to being on target in the project structure as a whole. There is still much room for improvement. Call volume for this project was under 15% of total calls, but still high considering the number of customers in the field. By far, the biggest amount of time was development and development rework. Requirements documents were poor and translated badly into the design/architecture of the final product causing large defect quantities. The number of SCRs for this project totaled 126. QA time was over estimate, so there is also improvement needed there. One of the big factors was misunderstood feature purpose/functionality.