Alan Pelz-Sharpe at Deep Analysis is on a mission to prevent organizations from making mistakes by backward thinking, whether it is from taking a “technology first” perspective or relying too heavily on simplistic frameworks to make vendor selections, there are a lot of worst practices to avoid.
Even in an age where there is a lot of great information online, it’s really hard for organizations looking for solutions to navigate all of the options and there’s, not surprisingly, some skepticism toward vendor-supplied information. Gartner (and many other organizations) continue to tout that by the time buyers engage with a vendor, they’ve already educated themselves.
But, as Alan says, enterprise software is complex stuff and I think it’s unreasonable to expect organizations to get the level of education they need to really understand what path to take. We see this time and time again when talking with prospects – they know they have a problem to solve, and that it involves document-based information. But outside of that, there is not a lot of knowledge on what is possible in terms of automation and what really needs to be considered. Because it’s complex.
But rather than seek out advisory firms such as Doculabs or Deep Analysis to assist with an effort, it seems that, once there is general acknowledgment that some type of technology is required, there is a rush to get an RFP or evaluation started. And that mentality to rush to a solution actually slows things down and significantly increases the likelihood of a failed project (or at a minimum, a very expensive one).
One area that almost always seems to fall short is the proof-of-concept (PoC). In theory, a PoC is supposed to provide an unbiased and verifiable path forward. You set the requirements, invite vendors to participate, and then do an apples-to-apples comparison of each vendor’s solution to meet your needs. But the key criteria that leads to a successfully-run PoC is often given short-shrift: the business problem analysis and the requirements for solving the problem. And as I’ve said many times, IDP is not CRM – you’re looking for the most comprehensive amount of transformed data at the highest levels of accuracy; but too many PoCs are focused on comparing features/functionality, not actual performance.
That’s why we worked with Doculabs to create a no-nonsense guide on how to conduct a PoC including the thinking that is required before you even start to put together a shortlist of vendors. We’ve also created a Learning Center that is unbiased and free of BS to help you understand what IDP is, scope your process problems, requirements, and successfully implement a high-performing document automation project all while reducing cost and risk. Get it here and get #insightful IDP.