Our client, a major state owned enterprise (SOE) had invested heavily in an IT Program Management Office (PMO) along with supporting project development frameworks and processes. The underlying methodology at the program level was “waterfall” with numerous gates.

A key driver behind this approach was to provide governance and clarity on major IT projects. Since the introduction of the PMO and project frameworks they had not experienced any IT development failures. This was a considerable accomplishment considering the scope, complexity and cost of their recent program of work ($50M p.a.)

One area identified for improvement was the requirements gathering and analysis phases that fed into solution and vendor choices. There had been several instances of projects entering design or build phases with incomplete business and technical requirements.

The waterfall methodology as implemented by our Client didn’t provide for “proof of concepts” as part of the requirements validation or solution procurement phases.

The Objective

To provide practical guidance and advice on project process improvement that allowed for the introduction of proof of concepts - potentially prior to the finalization of a business case or vendor and technology selection

Our Approach

We undertook a consultative education process with the Client’s key IT stakeholders, including PMO, Architecture, Solution Centers and Operations.

What’s a Proof of Concept?

In information technology development, “proof of concept” (abbreviated POC) is often incorrectly used to describe three processes with different objectives and different participant roles.

A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements

By contrast, the objective of a proof of technology is to determine the solution to some technical objectie achieved with a given configuration. No business users need be involved in a proof of technology.

A pilot project refers to an initial roll out of a system into production, targeting a limited scope business processes affected, the business partners involved, or other restrictions as appropriate to the domain. The purpose of a pilot project is to test whether the system is working as it was designed while limiting business exposure.

What are the benefits?

The process of specifying, developing and evaluating a POC can provide many benefits including, among others:

A very clear understanding of the business and technical requirements.

The development of a POC can bridge the gap very effectively between how the solution is envisioned during requirements definition and how it is ultimately delivered to SWC

Understanding the capabilities and limitations of solutions by answering questions such as:

• Can the solution extract data in a timely manner?

• Can the solution reliably distribute data updates to distributed systems?

• Is the client application “usable” on the target platform

• What is the “footprint” of the solution against current requirements

• Do the products selected meet the mandatory requirements?

The ability to assess design decisions early in the process

The ability for the business user to visualize early on the look-and-feel of the solution

A reduction in the overall risk of project failure

• Requirements are not fully understood before the project begins.

• Users usually know what they want only after they see an initial version of the software

• Requirements change often during the software-design-construction process

• New tools and technologies make implementation strategies unpredictable

What needs to be considered?

When considering the scope of the POC thought is given to:

What key features must go into the POC? For example, the parts of the system that have many unknowns or represent increased risk.

• What features can safely be left out? For example, components of the system (I.e., integration) that are repetitive implementations of a given concept can be excluded.

• What aspects of the design must be evaluated and tested, to ensure that the correct decisions have been made? This provides us with the “footprint” of the POC relative to the full set of requirements.

Success Criteria

Accurately and clearly defining the success criteria of a POC is critical to its overall success. It is key to define the success criteria prior to a POC commencing.