2. TECH581 Fall 2008 Measure Presentation Date: 10/24/08 Team members: xxxxx Sound Removed

3. Summary of Project Information Technology Department of major Insurance Company attempting to collect metrics on business requirements changes throughout application project lifecycle. If collected, measure is taken at the end of the project, amounting to 8 hours of work for a project manager. Tracking and recording the changes throughout the lifecycle of a project and the associated process that can be implemented across the organization can be a significant improvement to a maximum of 1 hour total for each project. The process of requirements counts/metrics can be used to further analyze and estimate future projects. Goal: To understand current processes for requirements metrics gathering to identify and eliminate non value add steps. Identify value added steps performed inefficiently and implement improvements.

4. SIPOC Supplier(s)InputsProcessOutput(s)Customer(s) Gather Requirements Metrics Consolidate Requirements Metrics Analyze Requirements Metrics Communicate Requirements Metrics Business Analysts Systems Analysts Enterprise Project Office Project Management Office Executive Management Quality and Process Improvement Enterprise Project Office Project Management Office Executive Management Quality and Process Improvement Business Requirements System Requirements Process Standards Reporting Requirements Quality Standards Requirements Metric Report Project Status Report Internal Project Metrics

5. Stakeholder Analysis

6. Voice of Customer Analysis Strength – All projects must have business requirements as a project artifact before implementing. Business requirements drive scope, schedule, and budget for a project. Weakness – No current process for counting the number of changes that occur to business requirements is in place. PMs are collecting information across the lifecycle at the end of the project. Opportunity – Changes to business requirements may lead to changes in scope, schedule, and budget of a project. Implementing a process to count changes to requirements during the lifecycle of the process can lead to later improvements in estimating future projects. Threats – Stakeholder involvement – Lack of process – No standard repository for business requirements across the organization.

7. Return on Investment (ROI) Current Project Time/Cost to gather requirements change counts at end of project: – 7.625 hours X $75/hour base = $572 per project. – Estimate per year AMIT completes 100 New Development Projects. – 100 X $572= $5,720 per year. Project is expecting to reduce time per project to count requirements changes to 1 hour. – 1 hour X $75/hour base = $75 – 100 X $75 = $750. Investment: – 2 PMO Staff at $75 40 hours each =$75 X 80 = $6,000. Potential return on investment= – $5,720 - $750 = $4,970 yearly savings. (Take project initiation cost of $6,000 = - $1,030 first year which will recoop within the first year of process.).

8. CTQ, KPOVs, KPIVs

9. Current State Process Map

10. Proposed Future State Process Map

11. Sampling Commercial Lines of business projects only Historical Data – random sample of completed projects stratifying by tier (project size) and tool used for requirements storage. Data for process/class project – random sample of in flight projects. Stratification by tier and tool.

12. Measurement Analysis Tree

13. Process Observation Worksheet – Historical Information at End of Project Estimated time to collect was an approximation by project manager for the project that was sampled.

14. Pivot Tables - Historical Data Data by stratification factors Historically, Tier 2 projects took longer to count requirements changes at the end of the project lifecycle. Historically, requirements kept in MS Word took longer to count changes at the end of the project lifecycle.

15. Process Observation Worksheet for New Process, Investigation at Stage Gates – Data Collection in Process

16. Next Steps Continue data collection Analyze data Through analyzed data, propose new process.