Editorial
"The Innovator’s Hypothesis" by Michael Schrage stresses the importance of cheap experiments for innovation. CIOs find themselves today very much on the front lines of reimagining their corporations’ future. As part of this, they represent grand central station for the proof-of-concept (POC) process.
According to Rita McGrath, the problem POCs solve for enterprises is “untested assumptions taken as facts, leaders not personally committed to the project’s every detail .... and a damn the torpedoes full stream ahead operating model." McGrath says, “prototypes are a great way to get customer feedback about elements of a proposed innovation before you have to invest a ton of resources in them.” So how and when should CIOs deploy POCs?
What Types of Projects Should Use a POC?
A POC is helpful to make the case for investment in a new solution, said CIO Anthohny McMahon. "The POC should be low-cost and able to be stood down with little to no impact.”
For a POC to succeed, CIO Pedro Martinez Puig stresed the importance of getting stakeholder involvement. "Any great idea that requires buy-in from distinct stakeholders benefits from a POC. A POC is worth a thousand slides for both convincing and gathering significant feedback at early stages of the project." POCs of course must demonstrate that the proposed approach can work as well for a mostly remote workforce.
Former CIO Joanna Young suggested a simple rule for POCs: “the higher the impact to customer-facing products and services, the more important it is to do a robust POC.” In terms of aims, CIO Jonathan Feldman said, “a proof of concept should mitigate serious business risk.”
With this said, former CIO Tim McBreen believes “it is important to manage expectations and have a governance approach to POC, just like a real project.” Part of doing this, said analyst Dion Hinchcliffe is ensuring, “a POC can test the change capacity/appetite of the organization. A great CIO knows how to use a combination of gut and experience to determine this.” From Hinchcliffe’s perspective, “a POC is an invaluable pathfinder for requirements not just innovation projects, but any domain that is new, unknown, untested and unproven.”
Learning Opportunities
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
Conference
May
13
Gartner Marketing Symposium/Xpo Conference London 2024
Register
Tie POCs to Business Objectives, Demonstrating Appropriate Value
Along with stakeholder involvement, CIOs should agree up front on how they will measure the POC and potential rollout's success, said Katie Rose, head of IT strategy, planning and architecture. "This clarifies whether you have delivered the value you wanted. Those measures need to involve the end-user, the functional team, and technology. They should be derived from a thorough business case.” Hinchcliffe continued, stating, “the real, practical answer to a lot of ROI in IT is that the net value is readily obvious to observers. Or the POC won't move forward to rollout. But the gold standard is to measure the POC against the existing method with already captured business KPIs.”
Steve Jones, chief data architect at Capgemini stressed the importance of “proofs of value versus POCs. Proving the value is not a technology concept. You must have a business case not a technical ambition. Proving a technology is rarely worthwhile, the fact that others have already done it is unless you are a pure tech company.” Young agreed and said, “if I had a nickel for every time a POC uncovered something new or struck down existing requirements, I would have a large pile of nickels.” CIO Peter Nichol added it was important “that POCs validate the feasibility of a business case. If this fails, it doesn’t mean the technology or innovation doesn’t work. Instead, it means that application might not be the most optimal application of the business case.”
When Do You Ask Vendors for a POC and What Do You Want Them to Validate?
Young repeated herself for this topic and said, “again, the more customer impact, the more POCs are needed and should be clear in any contractual documents.” Hinchcliffe said a good time to ask the vendor to participate in a proof of concept when:
- Suitability is uncertain.
- Cost/ease-of-implementation is hard to estimate.
- Promise is high but perceived feasibility in question.
- The IT team needs to validate skills required.
- Tech is unproven.
Without the right stakeholders involved to the end, a POC can go through the motions without the needed insights being gathered. Sometimes, low visibility is desired in a POC, but this can backfire without the result being properly captured and shared.
Guidance for Successful POCs?
Young claimed, it is critical to “define the scope of a POC and ideally keep it small. It is also a good idea to iterate through multiple POCs rather than try to do a mega-POC. Measures of success are critical. Document well but don’t boil ocean.” Hinchcliffe added, “I'd ask at a minimum that a POC demonstrate the following:
- A yes/no on the hypothesis it was created to test.
- Time to value estimate if used more broadly.
- Does it improve the Iron Triangle over other methods?”
Parting Words
Several years ago, I met with the enterprise architect for a major Canadian bank. The architect told me a horror story about traditional waterfall project management. He said he worked on an analytics requirement with his business counterpart, but when the product was shown to the customer, the customer said this was not what they meant. The result was a six-month redesign. POCs in the digital era, should hopefully short circuit the difficulties of the waterfall era as well as result in solutions that deliver real business outcomes. Nichol stressed in the end, “POC validates feasibility and MVP is a full functioning product.”
Learn how you can join our contributor community.
