How to kickstart a proof-of-concept IT project (original) (raw)

Like any IT initiative, operations staff need a clear vision for a proof-of-concept project. From the justification to reporting stages, knowing the steps can bolster PoC success.

Organizations initiate software projects quicker and with more complexity than ever before. Business resources are finite and new initiative can be costly, which is where proof-of-concept projects can help.

IT teams increasingly turn to PoCs to test and validate new initiatives. When used judiciously, a PoC can refine ideas, spot problems, spark creativity and maximize project success. When teams consider the tradeoffs and implement specific steps, they can boost the benefits of PoC projects.

What is a proof of concept?

In IT, a proof of concept -- also known as a proof of principle -- is a limited effort that demonstrates, tests or validates essential elements of a proposed business technology project. The project itself could involve developing and deploying new software, adding or replacing hardware, trying out a new business service, or even changing business workflows or platforms.

Successful PoCs can ascertain important information, including the following:

User acceptance. PoCs can gather user acceptance and feedback. Results can point to new features or important changes that will enhance acceptance, boosting product competitiveness and market share.
Operation/methods. A business developing new software might want to try new methods. PoC projects prototype the functional code and hardware infrastructure on a limited scale to validate new methodology, ensure security, benchmark performance and formulate practical scalability plans.
Compatibility/interoperability. A business planning to update enterprise software might implement a PoC to ensure the new platform can interoperate with current infrastructure, identify exceptions, determine workarounds and gauge the overall compatibility of the new element.
Performance. Businesses can use PoCs to validate performance. For instance, a PoC can prototype an API and its hardware infrastructure under simulated load to validate performance or evaluate the replacement of an aging server to ensure mission-critical workloads will perform adequately on the new server.
Workflows. A business planning to implement a new workflow can run a PoC to validate the provider's availability, test functionality of backups and recoveries, and gather essential information.

Proof of concept benefits

PoCs are useful to all elements of the business: users, stakeholders, investors and the project team. A well-considered PoC can yield a range of benefits:

Risk mitigation. The expense of modern IT-related projects has made many businesses risk averse. It's easier to spend money when the expectation of success is high. PoCs ensure that a project will be successful before the actual undertaking. This can help business leaders justify the investment in mission-critical or high-risk projects.

Early feedback and redirection. Some PoC results indicate that the proposed project has problems. This offers opportunities to correct problems before significant resources are invested in the full project. If the project isn't salvageable, teams can shelf it, redirect it to a new PoC or abandon it entirely.

Identify new opportunities. PoC projects can lead to innovation. For example, evaluating a new software function might spawn a complete rethinking about how to implement the function. Some PoCs demonstrate new technologies and prototypes, which can be valuable for investor discussions, like for securing the budget for a new technology initiative.

Proof of concept drawbacks

For all their potential benefits, PoC efforts can also carry possible drawbacks:

Cost. PoC projects cost staff time away from other projects, related support, and the purchase of tools and cloud resources. Although PoC costs should only be a small fraction of the costs associated with a fully realized IT project, they are still a consideration that the business must budget for.
Creativity limitations. Stakeholders and PoC team members can easily fall into the trap of only supporting the PoC -- "X is what we wanted to see, so X is the only thing we're going to discuss." Such limits waste valuable opportunities for creativity.
Scope creep. PoC projects could experience scope creep as projects evolve in response to new and unexpected stakeholder demands. Scope creep moves the goalposts of PoC project completion, leading to more resource consumption than expected.

Steps to a successful PoC project

PoC initiatives typically share six common steps:

1. Justification

The first step in any PoC approach is determining need, allocation of tools, talent and time necessary. Some business and IT leaders may ask whether the risks of forgoing a PoC are greater than the PoC investment required.

2. Scope

The next step focuses on goals, specific criteria for success and metrics that the team can review and share with stakeholders. Scope discussions also focus on building a working PoC team that involves the right stakeholders and technical staff capabilities.

3. Design

This is the project planning phase. Design converts the PoC project scope into an actionable plan that can be reviewed, approved, budgeted, executed and evaluated. The design phase is often short, but it's important to involve stakeholders and PoC team members to develop trust with the plan.

4. Execution

This is where the team builds and executes the PoC project in accordance with the project plan. It might be as simple as getting a graphic designer to draw mockups or as complex as establishing a functional operational environment for a comprehensive platform evaluation. An execution phase could last anywhere from hours to weeks depending on the scope and complexity of the PoC project.

5. Feedback

Execution generates feedback, which teams can then use in this course-correction phase. Feedback from user opinions, metrics, benchmarks and other measures can be addressed in the PoC itself. This lets team members revisit scope and design steps to make changes. For example, if a new UI or feature doesn't make sense to users, the team can tweak the design and seek new results.

6. Reporting

Once the PoC concludes, its findings and testing data can be presented to stakeholders. Reporting often includes cost and budget data that can be applied to full project implementation. Any concerns or problems can be discussed, potentially leading to new or alternative PoC efforts. Stakeholders typically use the final reporting as the basis for full project planning and approval. PoC failures could lead to project reconsideration, delay or cancellation.

Proof of concept best practices

PoC projects require proper planning and execution in a controlled environment typically isolated from production operations. Consequently, there are certain PoC best practices that demand careful consideration.

For software-based PoCs, best practices include the following:

Duplicate data/applications. Modern software typically relies on access to business data. Therefore, PoCs need duplicate data and even software platforms, such as duplicate SQL or NoSQL databases, to ensure operation without touching actual production data.
Duplicate infrastructure. PoC software requires installation on servers and access to the enterprise network. This means duplicating infrastructure so that PoC network traffic does not interoperate with production traffic. Developers regularly use DevOps techniques or work with IT operations staff to implement the required environment elements.
Acquire new tools/workflows. New software requires new development, testing and deployment tools. Teams must acquire and deploy these elements as a prerequisite.
Understand metrics/KPIs. PoC planners must understand the software metrics and KPIs that will be involved in the PoC project and ensure that any software instrumentation needed to measure and document software behaviors are in place.

Hardware PoCs also have a range of best practices:

Understand system requirements. New enterprise hardware might carry power, cooling, mounting, connection or other physical requirements. Teams should ensure the PoC deployment environment meets those requirements.
Understand the environment. New hardware serves a specific purpose. A PoC must be able to ensure that the new hardware is testable. For example, if the enterprise wants to test PoC on a PCIe NVMe storage device, there must be a nonproduction server available with a suitable internal interface where the new device can be installed.
Bench test. Once an operational environment is established, IT staff should test new hardware to gain familiarity with hardware management. Then, test for integrations with existing management platforms and other major enterprise applications to validate interoperability. Finally, examine the hardware for operation, performance and fitness for purpose.
Ensure hardware isolation. PoC testing should never touch production operations, so plan for duplicate hardware support that will exist outside of production, such as an isolated server, storage and network segment.
Understand benchmarks. As with software metrics and KPIs, hardware performance is often quantified through software-based benchmarking tools. Suitable benchmarking tools should be available for hardware testing and validation.

Not every best practice applies to every PoC. However, PoC projects will be more effective when these factors are considered ahead of time.

Editor's note: This article was originally written by Adam Bertram in 2020. Steve Bigelow revised and expanded upon it in 2023.