The Art of Effective POC – Part 3 (Post-POC)

Before I start on Part 3, till now we have seen:

Sr	Phase	Steps
1	Pre POC	Identify business requirement and its weightage Multiple products & feature analysis Organization’s budget Vs Cost Product in Architecture
2	During POC	Test users Test scenario Simulate test scenario in

This is my last blog on this series of “The Art of Effective POC”. The focus of this blog is on POST-POC activities.

Many IT professional believes, Once Simulation (activity at During-POC) is completed, POC is completed. Answer is NO, a very BIG NO.

Before you conclude on completion of POC, make sure you have answer of below questions:

• Are you confident that Product is meeting your BUSINESS REQUIREMENT?
• What would be the BUSINESS IMPACT, if we go ahead with product?
• What would be the BUSINESS IMPACT, if we do not go ahead with product?
• Does this product going to meet / support my future BUSINESS GOALS?
• If we are going ahead with product, what RISK are we carrying? Is these RISKS acceptable to organization?

Q: How do I get an answer of these questions?

A: Follow Phase 3 (Post POC)

Sr	Phase	Steps
3	Post POC	Evaluate weightage score Walk through to CISO Risk communication Decision

Evaluate weightage score

Let’s recall our Pre-POC phase where we had documented BUSINESS REQUIREMENT along with weightage and category. Now it’s time for qualitative analysis. Based on your “Test Scenario Simulation and analysis” in Phase 2, apply simple mathematical analysis to calculate weightage. Calculate Weighate for each BUSINESS REQUIREMENT and arrive at final score for each product.

Though this method is quite subjective but if followed effectively, could be helpful for CISO to take quick decision. The reason or objective behind weightage is to help management to take quick decision.

Walk through to CISO

This is extremely important. At least Project Owner should take CISO walk through for BUSINESS CRITICAL requirements. Reasons are:

• CISO would be able to take decision with firm confidence.
• To take feedback / input
• CISO can relate product features from future BUSINESS GOALS perspective
• Identify risks

Risk Communication

Companies where Information Security is discussed at Board level, this becomes mandatory requirement.

Q: What is Risk Communication?

A: Process of acknowledging that RISKS have been understood and accepted.

There might be gaps between “what are our expectations” Vs “What product is offering OR what we are procuring”. These gaps could be non compliance against business requirement or information security policy. In simple terms, these gaps are RISKS

These RISKS must be assessed by company’s TOP MANAGEMENT to conclude whether RISKS are acceptable OR not acceptable.

Decision

In give scenario, Decision is “Acknowledging whether product is meeting business requirements or not meeting business requirements”. Decision is taken considering many factors e.g. weightage, CISO’s feedback / input, Risks , future capability and could be many more depend upon size and type of organization.

With This I would like to END this series on “The Art of Effective POC” As promised, please download POC-Template Excel File.

Hope this would be useful.. 

The Art of Effective POC – Part 2 (During-POC)

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 CONCLUDE WHETHER 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…