Archive

Archive for May, 2014

PoCs – are they really an inefficient use of time and money?

This blog post is meant to be an answer on one of the latest blog posts of Identropy, „IAM Proofs of Concepts (POC) – An Inefficient Use of Time and Money“, written by Luis Almeida (btw: congratulations and all the best for your new job). It took me a while to gather all my arguments to reply to this blog post.

The first argument that Luis brings up, is that PoCs are costly and deliver very limited value.

The cost effect is an interesting one. Typically (at least for the majority of PoCs i did in my career), costs are beared by the vendor or integrator that is attending the PoC at the customers site. It’s in the interest of the vendor or the system integrator to show capabilities of their product within the customers environment. This is why most vendors or system integrators do not charge their potential customers for PoC attendance. The only cost effect (and i do agree that this should not be underestimated) on the customer site is to define the PoC scenario and to establish an lab environment to do the PoC in. Typically there are already testing environments beside the production network of the potential customer where development effort and software testing is driven before moving IT systems to production. The PoC scenario should already be defined (at least in parts) by the daily processes of the potential customer that are used to onboard, update or offboard employee identities. If the customer is a green field customer (having no legacy IDM solution in place), the approval processes are mostly kept in request forms that are available in the potential customers intranet or as printouts that can be leveraged to gather the currently used information for request fullfilment. I’ve also experienced PoCs where it was part of the PoC to demonstrate the conceptual approach of migrating manual process into an request driven, automated workflow in order to let the customer gain some inside on the used approaches and the way they are implemented into the solution.

The delivery of limited value is a bit tricky. For sure, the teams sent by vendors or integrators to do PoCs are mostly pure pre-sales consultants with a dedicated skill set in order to deliver a successful PoC in order to sell the product. Mostly, but not every time. In smaller organizations PoCs are delivered by project proven consultants and architects. Depending on what background the PoC delivery team of the vendor or integrator has, PoCs do deliver different outcome. It should be a duty of the vendor or integrator to set up a team of pre-sales consultants as well as professional services consultants to not only demonstrate the solution but also make the customer aware of potential pitfalls, arising complexity of the solution that is going to be implemented but also identify strategies to mitigate the risk that is about to be affect the upcoming implementation project.

The next argument that Luis brings up is the handover of responsibility from the sales / pre-sales team to the services team after the PoC in order to deliver a successful project.

Indeed, this is the most complex part of the transition of an IAM implementation project. Information might get lost, the SOW that is created by the pre-sales team might not fit into the customers requirements and the services team might get caught in an financial frame that is to tight to do the project in a safe way. But there is an solution out there to solve this problem: Integrate the services organization into your pre-sales cycle as soon as possible. What’s that good for? They can assist the pre-sales consultants onsite during the PoC by bringing in real life experience instead of pure trained pre-sales knowhow of how to achieve goals in a short amount of time to get the PoC scenario done. They services organization can also assist in creation of the SOW by bringing in real life experience from ongoing or former implementations and to justify potentially higher project cost by their experience of with pitfalls, complexity and data driven issues of implementation projects.

The third argument that is brought up by Luis is the significant opportunity to gain better outcome of an product evaluation phase by engaging a services partner. I totally agree to this approach as this allows the customer organization to focus on their needs and living processes while having partner in place that is dedicated to the IAM implementation and the search for the perfect product for the customers situation, their architecture and their team. The only thing i do have to mention for this scenario: are service provider or solution integrators really unbiased? They a probably a bit more unbiased than a vendor sales and pre-sales team, but not completely unbiased as they are typically partnering with a couple of vendors to distribute and customize their solutions. From a customers perspective, the best approach would be to engage a service provider for the product evaluation phase and the definition of use cases and requirements, but to have another service provider or solution integration, maybe the the vendor itself doing the project implementation.

The last argument that comes up in Luis’ blog post is „If POCs were an effective means to evaluate IAM solutions, there would not be so many failed implementations in the market.“.

For sure, there are failed implementations out there that came through PoCs and a suboptimal handling of the transition from the sales cycle into the implementation phase executed by services organizations. The implementation might also fail if the product evaluation was done by a service provider as there are so much factors that can be a source for project failure.

As an final conclusion out of both blog posts, i think we do agree in the fact that things have to be changed around the product evaluation process. There have to be things changed on the customer side as well as on the side of vendors or system integrators. And last but not least: this does not only affect IAM projects.

Categories: IAG, IAM, IDM, Strategy