Six Guiding Principles To Create a Proof Of Concept

Software product companies chalk out POCs to test concepts for creating proof points before getting into the act of building a portfolio of software solutions. POCs can be done as small assignments or projects. Some examples of POCs are:

a.)    Building an add-on for an existing product

b.)     Testing out a new technology adoption

c.)     Product migration

d.)     Architecture change

e.)     Mobile enabling a platform

f.)      Cloud enabling a platform

POCs are mostly executed by forming a special project team or by setting up a center of excellence (CoE) which caters to special projects. Regular releases are complex on their own because they deal with new functionality and technology. It can become quite challenging to add new concepts to an existing release. POCs pave a nice path to test new concpets before they are factored into a regular release.

POCs also provide an excellent platform to try out partners who can help companies scale their product teams. When enagaging partners for outsourcing or offshoring, it is best to follow a few guidelines.

1)      Setup a steering team to oversee the project

Steering team should consist of members with decision making abilities from both your company and the partner company together. Product ownership should be driven by you as you know more about the functionality than anybody else. Project management, architecture (orchestrated by your architect) and delivery can be with the partner. Steering group should be setup on the same lines as your project teams in your own company.

 2)      Engage in brainstorming sessions:

Always start the engagement with brain storming sessions that help the outsourcing company understand your business at an in-depth level. The initial interaction and communication should be directed at ensuring that both parties are viewing the problem from the same dimension and are looking forward to craft the right solution context by engaging in a partnership model that funnels the relationship to deliver the desired value.

3)      Craft a release plan:

After an initial agreement has been reached on the modalities of carrying out the POC, the offshore team members should be brought in direct contact with your team members to discuss the context of the release.

Establishing direct communication lines between the offshore team and counterparts from your organization helps in detailing a release plan which outlines the process for converting the new idea to reality.

4)      Start the ‘Pre-Game Phase’

Upon agreement of the Release Plan, the “Pre-Game” phase should be initiated with both parties detailing every aspect related to the Release. The pre-game phases consist of the following sub-phases:

a.)     Release Backlog

b.)     Backlog for the initial sprint

c.)      Software Factory Tooling

• Development tooling
• Progress Reporting
• Build Process
• Version Control repository
• Build Automation
• Test Management & Automation

d.)     High Level Architecture

5)      Implement Scrum

Scrum should be the preferred way of development as it helps retain flexibility in building the solution/concept in the right way and at the same time gives the team freedom to build the product in the chosen approach during a sprint without being hindered by changes. A step-by-step approach would be:

a)      Build the product backlog

b)      Define the sprints

c)       Schedule the sprint planning and sprint review meetings at a fixed date and time everymonth (or as per the sprint duration). Ex: Sprint planning on the first working day and the sprint review on the last working day of the month.

d)      Ensure that everyone particpates and contributes in the planning and review meetings

e)       Define a done criteria for the sprint

f)        Define the checklists to have quality built-in

g)      Have checklists and measurement criteria for code coverage, test coverage etc.

h)      Factor in time for test automation of the developed code. This eliminates manual testing for approved backlog items.

i)        Ensure that the ownership of tasks or requirements, rests with the people that can deal best with them

j)        Let the members of the sprint team choose the tasks and agree on the goal for the sprint

6)      Monitor and Review. Constantly.

The entire project should be governed by an Offshore Steering Committee process model.  Having a visible and transparent progress reporting system in place helps get a view of team achievements on a daily, weekly and monthly basis.

Setup a project portal to collaborate effectively, collect project artifacts, and provide for progress updates on a timely basis.

Apart from monitoring and reviewing the progress, the steering group should also focus on orchestrating and encouraging collaboration between teams from both companies. There are a few ways to do this:

a)      Celebrate every milestone achieved.

b)      Provide quality feedback to improve consecutive iterations.

c)       Shun ‘my team vs. your team’ approach, (which is a situation often created when the outsourcing company is located in a different country) and instead view it as a project team working towards executing a great idea that will help shape future versions of your product.

While following these guidelines will smoothen out the process of crafting great POCs, it’s also essential to keep in mind that your company and the outsourcing company are both unique and hence a relationship between the two should be treated with patience and integrate operations involved accordingly.