17 days ago

What’s the difference between a POC, a Pilot and an Implementation project? Do you know how to support these projects?

Link: https://eapj.org/whats-the-difference-between-a-poc-a-pilot-and-an-implementation-project-do-you-know-how-to-support-these-projects/?utm_source=rss&utm_medium=rss&utm_campaign=whats-the-difference-between-a-poc-a-pilot-and-an-implementation-project-do-you-know-how-to-support-these-projects

Why are we talking about this in an Enterprise Architecture forum? As an architect, I have been involved in all three of these project types and it’s critical for us to understand what our role is in each, so that we understand what value we can offer to deliver the desired outomes. Customers assume that when they ask for a solution, we will magically just deliver it…no questions asked. That’s not how it works, does it?

It astounds me that some of my IT peers struggle to know the difference between the various stages a solution goes through before it can be implemented. The challenge is explaining what happens between the point when a request for IT services is made, and when a solution is embeded in the business environment.

What I am talking about is not just the various stages in a product development and launch, but the variety of projects that is required from idea through to go-live. It really is not as simple as the consumer apps you install on your iPhone or on your home laptop.

So, I hope this little blurb can help you understand, or help someone else understand, the iterations involved so you can contribute your expertise effectively and ensure the right solution gets delivered to your customers.

Adapted from: https://states-of-change.org/stories/proof-of-concept-prototype-pilot-mvp-whats-in-a-name

If your customer comes to you and says, “I need a new Asset Management App tomorrow”, how does your organisation typically respond? Do you just jump to mobilising a team and start building/buying and then implementing using an SDLC approach? We need to be able to explain to our customers that we want to incrementally work with them to firstly understand their request, and then rapidly work with them to deliver an MVP. So with speed, use an Agile (adaptive and responsive) approach to get your customers the right solution to address their challenge.

Below is a summarised table of the important aspects of each phase in the solution development cycle and aligns well with using agile methods such as SAFe and SCRUM. Have a look at the table below.

Table1: How to look at your projects and what you are trying to achieve.

A note…beware of the vendor that wants to jump straight into an MVP project with you.  Not having gone through the previous phases might end up costing you a lot of time, effort and dollars, and tie you into a costly solution that no one wants to use.

Now if you find you already use approaches like this in your organisation, then how about a share on the EAPJ website? What works well for you? We would love to learn from your great practices.