SERIES: The Art of Effective POC – Part – 2

      Comments Off on SERIES: The Art of Effective POC – Part – 2

In Pre-POC, We have identified business requirements; analyzed features of products, budget vs. cost analysis and analyzed product architecture. Success of POC is depended on meeting Pre-POC requirements.

SUCCESS DOES NOT MEAN SELECTION OF PRODUCT, SUCCESS MEANS CONFIDENTLY CONCLUDEWHETHER PRODUCT IS GOING TO MEET ORGANIZATION’S REQUIREMENT OR NOT.

Test Users

Careful selection of test users is also an important aspect of project. At the end you want few users to test identified product requirements and provide a feedback. Test users should not be identified just for the formality. I would prefer to have one session with test users to explain what to do and what is expected. Test users should have below qualities:

  • Test users should have clear understanding about requirements identified in Pre-POC.
  • Test users should have techno-process background to provide feedback both in terms of technology as well as process aspect.
  • Test users team should be compress of IT and Business. It is good to involve few users from business as well. In certain product POC, it is idea to have test users team from business only.

Test Scenario

Test scenario is derived from business requirements identified in Pre-POC. Test scenario is converted version of business requirements. The difference is, Test scenario would be technical in language. Test scenario is written for each business requirements identified. One business requirement can have multiple test scenarios. Lets take a example of EndPoint Security

Sr. Requirement Weightage Category Test Scenario (Example)
1 Virus Scanning 30% CRITICAL Virus scanning for following platform:
-) Windows

-) Mac

-) Linux & Unix

-) Virtual Servers

-) NAS & SAN box

·         Schedule & Manual scanning

System utilization during Full Scan

·         Virus Found auto Alert (e-mail, SMS)

·         Virus Treatment (Delete, Quarantine, Clean)

·         Virus signature auto update

2 Device Control 20% HIGH ·         Block USB

·         Block CD/DVD

·         White list of certain system.

3 App. Blocking 15% MEDIUM ·         Allow only white listed SW on system.

·         Auto alerts in case unauthorized SW found

·         SW Inventory

4 Patch Mgmt 10% MEDIUM ·         Patch management for all platform

-) Windows

-) Mac

-) Linux & Unix

-) Virtual Servers

-) NAS & SAN box

·         Report Patch wise

·         Report system wise

·         Patch release auto alter

5 Reporting 10% MEDIUM ·         Audit log of each virus detected
6 HIPS 10% MEDIUM Product does not have HIPS feature
7 NAC 5% LOW Product does not have NAC feature
TOTAL 100%    

*Above test cases are only example, this list has be quite extensive and needs series of meetings between IT and Product Vendor.

Simulate Test Scenario

Test scenario should be very simple & specific. Once scenarios are prepared, floor should be given to Test Users for simulation. During simulation, every day meeting between project manager and Test user is recommended to discuss progress and share test experience within team.

Test user should be given template/format in which output needs to be recorded, certain cases test user should preserve evidence e.g. screen shot of config file, system utilization, abnormal system behaviour etc. Idea is to share instant feedback with vendor to further fine tune system for effective POC.

Please note that every business has a unique requirements, product/technology needs some amount of customization during POC as well as during product implementation (Post procurement).

My next blog “The Art of Effective POC – Part 3” would focus on Post-POC. Post POC is most import phase. In this phase Team has to present the facts and management has to take decision. The KEY is we need to present sufficient information to management to take decision without any stress.

Hope this would be useful…