To borrow a line from an excellent book: “Hope is not a strategy”. Some companies will, often out of necessity, take a “build the aircraft as you fly it” approach to project execution. As daring as that sounds, it is rarely easy and always turbulent. Frankly, I would love to have an aeronautical engineer in the room when someone used that expression, just to see how hard their brow furrows.
The software can often fall into the same trap. Companies will create a Minimum Viable Product (MVP, but not to be confused with the sporting acronym) and start to market it as a full solution. I understand the reasoning here – creating a new product is costly and time-consuming, and you want to start generating revenue as quickly as possible.
But now put your customer hat on and picture the same concept: you are paying for incomplete software that doesn’t do what you need and often doesn’t even do what it says. You get flooded with PowerPoint presentations and artful graphics, but if you look closely enough you can see that there is not a lot of actual content or tangible product behind it.
This is what we mean when we talk about Vaporware – something that purports to be or do something that it does not. In many cases, this should be qualified by adding the word “yet”. The company fully intends to plug the gaps in its offering, and might even wow you with its long-term vision and development plans. But frankly, that does you no good in the short term.
If you end up signing the deal, you will quickly discover that the product you have can’t perform to your level of expectation. By then, it can often be too late to do something to change it. Or even worse, you plow hundreds or thousands of hours of resources into helping to try to improve it and find yourself heavily in a ‘sunk cost’ conundrum.
So how can you protect yourself against this:
It isn’t enough just to say “We want software that does AWP”, because that is a very loose definition. You need to have a clear and detailed understanding of EXACTLY what you need. This doesn’t mean you need to be a software genius – you aren’t stipulating how it should be done, just what the end result is.
O3 is in the process of publishing a series of deliverables about AWP on our website, called the AWP Implementation Toolkit. One of these deliverables is a technical specification for what AWP software should be able to do, which can be used as the basis for your assessment of software providers. Let them know that you have exacting standards, and see which ones can meet them.
This one is very standard but certainly worth noting: Get references. Talk to people who are using the tool, and do so without the vendor in the room or on the call. Get an honest assessment of the strengths and weaknesses. But always bear in mind that the person you are speaking with will have been named by the software provider.
It can be very easy for software companies to create slick presentations and demonstrations using canned data such as 3D models. These are often files that they have tested, scrubbed, and made presentable. The real acid test comes when you hand them your files and say “Show me your product with my data”. See how quickly they can turn it around, and how willing they are to take it. If it sounds like a Herculean effort on their part just to import your model file, for example, chances are that your implementations will not be smooth.
The last good option, especially if this is your first AWP implementation, is a proof of concept. Agree on a scope of work for test implementation. Import your model, perform the initial configurations, and integrate the software with your other tools. Prove that it all works, and agree on what success looks like. It might cost to do this, but the peace of mind is invaluable, and it means you can hit the ground running on your first project implementation.
