olly - Fotolia


How to kickstart a proof-of-concept IT project

As with any IT initiative, operations staff should have a clear vision for a proof-of-concept project -- from technical requirements to the key stakeholders involved.

The design and development of tools and applications is a big undertaking for IT -- one that requires significant time and capital investment. That's why, before they expend the necessary resources, enterprises should conduct a proof-of-concept IT project to verify a new tool or app will meet users' long-term needs.

A proof-of-concept plan progresses through several steps. These steps ensure the new application or tool meets requirements, and that IT teams and the business don't overlook any constraints or shortcomings. A formulaic approach to application or tool design informs next steps for a production product.

Step 1: Define the need for the new application or tool

First, decide what the new tool or application will need to do, and why it requires a proof-of-concept IT project in the first place. Typically, there is a business need to streamline operations or increase reliability through the creation of an application or tool. For example, the business might request a new, automated time-keeping application to replace a manual system that is error-prone and slow.

This first step is critical: Without clearly defining the purpose of a new tool or app, a project becomes time-consuming and costly.

Step 2: Determine project stakeholders

Stakeholders are the individuals directly affected -- either negatively or positively -- by the proof-of-concept IT project.

Stakeholders are the individuals directly affected -- either negatively or positively -- by the proof-of-concept IT project.

The identification of stakeholders goes hand-in-hand with step one above, as IT staff must communicate with these stakeholders to understand the need for the project -- i.e., to address any shortcomings of an existing app or tool. To revisit the earlier example of the time-keeping system, stakeholders might include the finance department, organizational employees and system administrators. IT doesn't need to speak with every single stakeholder in the organization -- but it can't hurt.

Step 3: Map out application or tool requirements

After determining why the project is necessary and who it affects, define its requirements and necessary resources. These might be technology-specific requirements, such as certain databases, runtime environments or server architectures. Make a rough estimate, then further define and evolve requirements as the proof-of-concept IT project progresses.

With the time-keeping application example, requirements might include:

  • employee-entered timecards;
  • automated approval processes;
  • automatic calculations of leave; and
  • an export to the accounting system for automated check processing.

In addition to technical requirements, there might be business or staff requirements for the proof of concept, such as specific personnel or departments that must be involved. In the case of our time-keeping application, these might be the people involved in the approval process.

Step 4: Design a prototype

The next step in a proof-of-concept IT project is to build a prototype to understand what a viable product might look like. It takes a significant investment to create a widely used production application, so it's best to start with a prototype on which IT can iterate.

proof of concept vs. prototype chart

Again, to revisit the time-keeping application example, a prototype could include:

  • A low-code tool to experiment with the app's front end and user experience;
  • A user login system that uses SAML authentication and assigns users to the correct role, such as standard user or administrator;
  • A timecard entry screen that enables users to enter seven days of numeric values for a given week;
  • An automated email sent to the user's supervisor for approval;
  • The ability for the supervisor to approve the entry, or adjust the hours as necessary; and
  • The ability to generate and export a CSV for the finance department that can be loaded into an accounting program to generate checks.

Dig Deeper on Systems automation and orchestration

Software Quality
App Architecture
Cloud Computing
  • The 3 daily Scrum questions

    The 2020 Scrum Guide removed all references to the three daily Scrum questions, but does that mean you shouldn't ask them anymore?

  • Why WebAssembly? Top 11 Wasm benefits

    Latency and lag time plague web applications that run JavaScript in the browser. Here are 11 reasons why WebAssembly has the ...

  • Why Java in 2023?

    Has there ever been a better time to be a Java programmer? From new Spring releases to active JUGs, the Java platform is ...

Data Center