Willem BisschoffOperation Manager (Specialised Project Delivery)| First DigitalCenturion, Gauteng, South Africa
Hi PMI Peers
I would like to get an expert opinion on the cut-over process in software project implementation.
What is the acceptable percentage of issues during project cut-over to move into a live run? Bearing in mind non of them are critical processing issues Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In our case after creating a piece of the solution we perform UAT. After the UAT the piece of solution is moved to live run and we have defined what we call hypercare period where the people that created the piece of solution is taking the operation instead of the operation group. We have a set of exit criteria from the UAT. We have a classification of defects in level 1, 2 3 and 4. No defects levels 1 and 2 are allowed. Defects 3 and 4 are allowed if they have a plan to fix them. So, in our case, is not about the amount of issues. Is about the class of them
...
1 reply by Willem Bisschoff
May 27, 2021 3:47 AM
Willem Bisschoff
...
Hi Sergio, thanks for the reply.
Our standard practice is well aligned to the P1 to P4 issue identification. We deem the sign-off of UAT and movement to cutover acceptance of open P3 and P4 issues to be resolved post cut-over.
The amount of issues is secondary to if the core deliverables are met and key business functions and objectives can be achieved during the cut over.
This is usually defined as part of the acceptance criteria for a cutover and will vary based on the criticality of the end result and how important other project constraints are in relation to quality. In a perfect world, the answer would be zero, but if the delivery process is at a lower level of maturity and there are time & cost constraints affecting the ability to achieve this, then a compromise similar to what Sergio has suggested would be needed.
I don't understand how you would calculate a percentage of issues; by lines of code, the customer's functional requirements, against the total number of issues identified?
It boils down to a risk management question, which means probability and impact must be considered. To expand on Sergio's comment, there are many types of potential software issues. Product safety issues should be zero, blue screen of death issues should be very low, and there are a whole range of other types, some of which may be invisible to the customer, may have work-arounds until the issues are resolved, and some that merely provide you with internal performance metrics.
Rather than a percentage of some larger statistical population, I would consider a burn-down to acceptable thresholds based on risk types, mitigation paths, an risk tolerance levels of both the team producing the software, and the end-users. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
I think that based on the response you have gathered that it is not really possible to quantify the with a percentage. The severity or impact of an issue is yet another metric that should be used when considering acceptance i.e. 10 low severity issues might be acceptable while 1 high severity issue not. Typically cosmetic issues are low severity while functional issues are higher. But again it would depend on the type of system e.g. in a game a cosmetic issue will be higher than in a LOB system. Saving Changes...
Willem BisschoffOperation Manager (Specialised Project Delivery)| First DigitalCenturion, Gauteng, South Africa
May 25, 2021 7:25 AM
Replying to Sergio Luis Conte
...
In our case after creating a piece of the solution we perform UAT. After the UAT the piece of solution is moved to live run and we have defined what we call hypercare period where the people that created the piece of solution is taking the operation instead of the operation group. We have a set of exit criteria from the UAT. We have a classification of defects in level 1, 2 3 and 4. No defects levels 1 and 2 are allowed. Defects 3 and 4 are allowed if they have a plan to fix them. So, in our case, is not about the amount of issues. Is about the class of them
Hi Sergio, thanks for the reply.
Our standard practice is well aligned to the P1 to P4 issue identification. We deem the sign-off of UAT and movement to cutover acceptance of open P3 and P4 issues to be resolved post cut-over.
The amount of issues is secondary to if the core deliverables are met and key business functions and objectives can be achieved during the cut over.
...
1 reply by Sergio Luis Conte
May 27, 2021 7:47 AM
Sergio Luis Conte
...
Hi Willem You are welcome. Exchange information helps me to learn and to improve myself and/or the process I am using today. Then we are in the same page Here our exit criteria for UAT. The first one assures 100% coverage of solution requirements. The second one is about test cases that was successful executed. Severity 1 is the highest rating for a defect. We use the same no matter the type of approach we use (Agile, Lean, "Traditional", etc) 1-100% of test cases in scope executed 2-Pass percentage 95% or greater 3-Traceability Matrix is complete (test cases to requirements) (Yes/No)…........................................... 4-No opened Severity 1 or 2 defects 5-Action Plans approved by the business for any open severity 3 or 4 defects 5-Action Plans completed and approved by Business. (Yes/No / Not Required)…..........................
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
May 27, 2021 3:47 AM
Replying to Willem Bisschoff
...
Hi Sergio, thanks for the reply.
Our standard practice is well aligned to the P1 to P4 issue identification. We deem the sign-off of UAT and movement to cutover acceptance of open P3 and P4 issues to be resolved post cut-over.
The amount of issues is secondary to if the core deliverables are met and key business functions and objectives can be achieved during the cut over.
Hi Willem You are welcome. Exchange information helps me to learn and to improve myself and/or the process I am using today. Then we are in the same page Here our exit criteria for UAT. The first one assures 100% coverage of solution requirements. The second one is about test cases that was successful executed. Severity 1 is the highest rating for a defect. We use the same no matter the type of approach we use (Agile, Lean, "Traditional", etc) 1-100% of test cases in scope executed 2-Pass percentage 95% or greater 3-Traceability Matrix is complete (test cases to requirements) (Yes/No)…........................................... 4-No opened Severity 1 or 2 defects 5-Action Plans approved by the business for any open severity 3 or 4 defects 5-Action Plans completed and approved by Business. (Yes/No / Not Required)….......................... Saving Changes...
