When your organization buys a commercial modeling tool, there’s most likely a fairly standard procedure that you go through. You’ll research tools, you’ll probably have one or more demos. And then you’ll usually have a proof of concept where you try out the product for yourselves.
Seems reasonable enough, but when I was liaising with organizations that were performing their own proof of concept, I was often surprised by how often they would get their proof of concept set up, and then not manage to do much with it in the course of the trial.
I’m being a little harsh of course. Architects work in a pressured environment, and they have competing demands on their time. When you’re being hassled by project managers and the like for input, it becomes all too easy to push non-critical tasks on to the back burner. And then put it off again. And again. And again. The only problem is that this can make the execution of a proof concept a fairly pointless exercise – and risks selecting the wrong tool for your needs.
So how do you avoid falling into this trap? Here are three ways you might be doing your proof of concept, and how you can solve this to really make your evaluation work for you.
1. You don't have a project
A proof of concept should be based around a specific project. Basing it around a project provides focus – otherwise it’s all too easy to end up thrashing around trying to decide what to model... and then it becomes all too easy to put the decision to one side and focus on whichever fires are begging to be fought that particular day (and the day after, and the day after).
2. You don't have specific use cases
A model is intended to provide insight and a modeling tool is intended to provide analysis and reporting capabilities. This being the case, it's important that you use the proof of concept to check that the tool can meet your needs. All well and good, but once you're in the heat of things it's too easy to lose track of your objectives. So it's critically important to establish a set of use cases such as “search for an application across projects” or “show business functions in order of how many critical applications they use”. Otherwise the evaluation ends up being purely based on gut feel.
One good way to define use cases is to draw up a simple motivation model for modeling – and then trace through from higher level business goals to specific requirements.
3. You're not allocating or tracking time spent
The biggest challenge is actually spending the time on the proof of concept in the first place. And while the previous two ways to fail are very real, addressing them by themselves is not enough – you have to make sure that you spend the time to use this project that you've identified, and test these use cases. So it's important to track the time that you're spending on the proof of concept, otherwise other priorities always come to the fore.
At the end of the day, a proof of concept is an investment of time to reduce risk. But without avoiding these three pitfalls, you’re at risk of not getting what you really need from that valuable proof of concept, and inevitably ending up with the wrong tool for your needs.
Is an EA project on your horizon? iServer's Proof of Concept is specifically tailored to make sure you get the most out of it and answer all your questions. Watch this video to find out more!