Home
About Us
Site Map
Products
Services
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Links
Contact Us
BLOG

 

 

Testing Subphase

"The testing subphase consists of many different subtests. These include integration testing, functional testing, stress testing, regression testing, and system testing. The final step is acceptance testing, the results of which are shown to the project stakeholders for final signoff to proceed to deployment of the solution. Some of the problems you may encounter in this phase during a project rescue are as follows:
  • Going back to the old ways  For whatever reason, users may insist on using the functional requirements from the original attempt and may try to ignore the revamped, steamlined requirements that were agreed to for the project rescue. There should be an extensive audit trail of decisions made and directions followed. A set of test scenarios or test cases, that are agreed to by the executive sponsor(s), should be maintained so that everyone involved in the project understands how the solution is going to be evaluated.
  • Lack of business resources  The testing activities may be completed in the early-morning hours or at another time during which the business users are not available. The executive sponsor is empowered and required to make these resources available.
  • Lack of testing rescources  If there is a need to have additional hands-on resources, consider contracting with lower-cost contractors who can owrk with a detailed test script and are available 24/7 to be called upon when work is ready for them to test.
  • Lack of tools  Testing can be a tedious process that can be improved with the use of automated tools. These tools tend to be on the expensive side. Some open-source tools can be used as a lower-cost alternative.
  • Dealing with the results  There must be clarity on how to process the test results (e.g. defect identification and resolution). This includes recording the findings, prioritizing them, and fixing the ones that are urgent for launch."

Get signoffs

"You may get to the finish line and feel positive about the results of the project rescue, but three major activities still need to be completed before the project rescue can be deemed a success:
  • Get official signoff to proceed to implementation or rollout of the solution.
  • Successfully deploy whatever product that was being constructed.
  • Finish post-project cleanup"
 
"The fist two activities are part of the execution phase, while the third is part of the post-intervention review phase of the project rescue."
 
"The signoff process is different for every executive sponsor. Some mandate it to a stakeholder or users, otheres distribute the responsibility, and some want it to be the final gate. Clarifying the process was one of the objectives of the planning phase, so there should be a consistent understanding of what needs to be done."
 
"It would be unfortunate indeed to get this far successfully, only to miss the deadline because the final signoffs cannot be secured in a timely manner. Some problems with the singoff process can still arise for any number of reasons, as follows:
  • Looked good on paper  The designated acceptor may have thought everything looked good on paper, but may feel uncomfortable about making a commitment. Avoid this by keeping the designated acceptor, as well as the other stakeholders, apprised of the test results on an ongoing basis and listen to their concerns.
  • No one to sign off is available  The acceptance testing may be completed early in the morning and the person designated to sign off may not be available. The acceptance process should identify 24/7 coverage.
  • Fear of accountability  Get this cleared up with the executive sponsor before agreeing on the final signoff process. Also, get signature signoffs for the earlier test results to build comfort in taking this accountability.
  • Verbal approval, but not written  A verbal approval to launch should be avoided. But if it is a necessity, it needs to be followed up by an audit trail that signifies that verbal was acceptable and that it was give. This is a fuzzy area and needs further legal clarification if it is going to be pursued."

Deploy Solutions

"While this site has a strong information technology theme, the suggestions can apply to any type of deliverable, be it a report, restructuring of a department, reengineering, or offshore migration. Deployment planning needs to start in parallel with the launch of the execution phase. Here are some key considerations for this subphase:
  • Lack of contingency  Do not even try to launch a solution unless a contingency has been defined. Any number of things can go wrong. Business interruption cannot be allowed, so another strategy needs to be tested and ready to be implemented.
  • Testing the solution in production  After rolling the solution into production, be ready to test portions of the application in the production environment before it is available to others.
  • Availability of resources after launch  Publish a list of all the skills that are required for the production day, for the production week, and for a few weeks after. Contact information for 24/7 support is needed. The rescue manager may need to remain engaged until this sensitive period is passed."

Closing Perspective

"This section examined the project rescue execution phase in more detail. The focus of this section was to point out some of the things that can go wrong during a project rescue and to provide some mitigation strategies. This section also discussed ways to leverage some of the positive levers that become available in a project rescue. Activities and tasks for the subphases are described in a book by the same author: High-Value IT Consulting: 12 keys to a Thriving Practice (McGraw-Hill/Osborne, 2003)."