Are customer(s) identified and segmented according to their different needs and requirements?
<--- Score
61. Is there a Software reliability management charter, including stakeholder case, problem and goal statements, scope, milestones, roles and responsibilities, communication plan?
<--- Score
62. What customer feedback methods were used to solicit their input?
<--- Score
63. Has a project plan, Gantt chart, or similar been developed/completed?
<--- Score
64. What are the rough order estimates on cost savings/opportunities that Software reliability brings?
<--- Score
65. Is Software reliability currently on schedule according to the plan?
<--- Score
66. Has the Software reliability work been fairly and/or equitably divided and delegated among team members who are qualified and capable to perform the work? Has everyone contributed?
<--- Score
67. Is the scope of Software reliability defined?
<--- Score
68. What gets examined?
<--- Score
69. Is there a critical path to deliver Software reliability results?
<--- Score
70. Is special Software reliability user knowledge required?
<--- Score
71. How have you defined all Software reliability requirements first?
<--- Score
72. Is scope creep really all bad news?
<--- Score
73. How do you gather the stories?
<--- Score
74. How will variation in the actual durations of each activity be dealt with to ensure that the expected Software reliability results are met?
<--- Score
75. Is Software reliability required?
<--- Score
76. Is the Software reliability scope manageable?
<--- Score
77. What is the scope of the Software reliability work?
<--- Score
78. What scope to assess?
<--- Score
79. What constraints exist that might impact the team?
<--- Score
80. Is there a clear Software reliability case definition?
<--- Score
81. What are the requirements for audit information?
<--- Score
82. How is the team tracking and documenting its work?
<--- Score
83. Has/have the customer(s) been identified?
<--- Score
84. What are the dynamics of the communication plan?
<--- Score
85. What is the definition of success?
<--- Score
86. How was the ‘as is’ process map developed, reviewed, verified and validated?
<--- Score
87. What are (control) requirements for Software reliability Information?
<--- Score
88. Is there regularly 100% attendance at the team meetings? If not, have appointed substitutes attended to preserve cross-functionality and full representation?
<--- Score
89. Who is gathering information?
<--- Score
90. What is in the scope and what is not in scope?
<--- Score
91. What is the worst case scenario?
<--- Score
92. Has the improvement team collected the ‘voice of the customer’ (obtained feedback – qualitative and quantitative)?
<--- Score
93. What sort of initial information to gather?
<--- Score
94. How do you build the right business case?
<--- Score
95. What are the core elements of the Software reliability business case?
<--- Score
96. What is out of scope?
<--- Score
97. How would you define the culture at your organization, how susceptible is it to Software reliability changes?
<--- Score
98. Is there a completed SIPOC representation, describing the Suppliers, Inputs, Process, Outputs, and Customers?
<--- Score
99. Does the team have regular meetings?
<--- Score
100. Are accountability and ownership for Software reliability clearly defined?
<--- Score
101. How do you manage unclear Software reliability requirements?
<--- Score
102. Are there any constraints known that bear on the ability to perform Software reliability work? How is the team addressing them?
<--- Score
103. How do you keep key subject matter experts in the loop?
<--- Score
104.
