Before heading off on maternity leave I was involved in looking at BPM products for a product we are developing. During this process I got a better understanding of how to go about selecting a product.
Understanding the Need
Before jumping in to looking at products it is important to understand the project or type of projects the product will be used in. This allows you to build up a feature list which the product must satisfy. Some of the questions I asked myself included:
- What functionality is required in the product?
- What are the non functional requirements? E.g. considering things like performance and reliability. Is the end solution a critical system?
- What is the budget for the product?
- What sectors do the companies we build these solutions for exist in? This can help to identify if there is any legislation which may affect product choice e.g. the meeting of certain accreditations.
- Will the end user need to use the product themselves? If so what is their technical level of skill?
- Are there any other systems it needs to interact with?
- What hardware and languages will be used in the rest of the system?
- What deployment options do I need to consider? Will it be deployed on the customer site or made available via the cloud
From this feature list you should be able to identify a number of make or break features which will help you move from looking at a wide range of products to identifying 2 or 3 to look at in more detail.
Identifying Possible Candidates
The next stage is to identify a range of products which could meet the brief. Analyst reports can be a useful source for learning which products are the front runners and up and coming products in a particular sector e.g. Gartner produces a report each year on BPM products. At this stage you want to look at a wide range of possible product solutions. I selected 10 BPM products which I thought could meet the brief. I then rated them against some key criteria I had identified when drawing up the feature list. This included cost, ability for an end user to create a form and ability to extend and integrate the product. I used the product’s website, analyst reports, online reviews and customer testimonials to determine how each product performed against the criteria. Summarising this into a few sentences allowed me to narrow down the number of products I was investigating to 2. At this stage I also looked at company history including:
- What is their experience was in this area? Is this a new or established product?
- Have they customers which operate in the same sectors as our end customers? Are there case studies and testimonials about their experience?
- What are their plans for the product going forward? Have they developed it over the past couple of years? Is it something they are investing in financially and in terms of resources or has the product reached end of life where the company is unlikely to develop or enhance it in the future.
Comparing Against the Wider Feature List
Now that the number of products has been reduced you can compare them against the wider feature list, breaking down any high level features into lower level features which are easier to measure. I used an Excel spreadsheet to let me compare the products side by side. This allowed me to see the products strengths and weaknesses. I used a colour coding scheme using red for unsatisfied, amber for partially satisfied and green if the product fully satisfied the feature to further enhanced the readability of the comparison.
At this stage more in depth analysis can be carried out of costings. Looking at the standard licensing models available and understanding which would be applicable to our projects.
The next stage after this is trialling the product. This is time consuming so ideally you want to limit the number of products you trial to one or two. Hopefully carrying out this more detailed comparison will have helped identify a front runner or perhaps ruled out a product due to missing features.
Trialling a Product
The final stage involves trialling a product. This allows you to get hands on experience with the product and more direct interaction with the company which created the product. This interaction with the company is also key as it can give you an insight into what is could be like working with them going forward e.g. requesting enhancements and investigating issues.
Most companies are willing to provide you with a trial version to test out the product. Sometimes this can be downloaded directly from their site but it can be useful to make contact with the company directly. I found working with the company directly useful as they demoed the product for me over the web. This along with samples from the company allowed me to get up to speed quickly with how to use the product and better understand the power and limitations of the features which were relevant to how we would be using the product. Remember they will never be more helpful than when trying to win your business so now is the time to get the maximum input out of them.
During the trial you want to quickly get a feel for how the product will meets your project’s needs. If the product is going to replace an existing product you could achieve this by reproducing an existing piece of functionality. If it is for a new project you need to think of a simple scenario which will allow you to experience a range of functionality.
It is also useful to get in contact with existing customers and partners of the company to understand what their experience is of working with the company. This will give you a more realistic picture of how it will be to interact with the company once a contract is signed and they no longer have to win you over.
This is also a good time to re-examine pricing and understand what flexibility there is around their pricing and licensing model.
Once you have carried the trial out you may be satisfied you have the correct product for your project or you may find the product does not fit your needs and you need to go back to a previous stage of the process and identify a new candidate.
Why Go Through This?
By carrying out due diligence you ensure that the correct product choice is made. Just as it is important to properly identify requirements when building a solution to avoid costly bug fixes further down the line selecting the correct product upfront helps avoid investing time and resources in a product which does not meet the project’s needs. Once a product is embedded in a solution it is more difficult to remove it and introduce a new product.