A guest blog post by Ulrich Leidl.
Many companies all over the planet are constantly facing that challenge: What is the best way to choose the software solution which fits the company’s needs best?
Let me give you a short example to describe a concrete scenario: Let’s assume that you are working for a retail company, which sells their products across the whole omnichannel chain. For various reasons your existing Digital Asset Management (DAM) System, that delivers your multimedia content across all channels no longer fits your needs. So it is time for a change!
As the principal Product Owner of your companys ominchannel process, you are responsible for finding the best DAM solution for your company!
But how will you proceed? How can you identify, in a fast and efficient way, which DAM solution will really fulfill the requirements of your users. Most likely you will start by writing down all of your suspected requirements in a huge Excel file. I reviewed many of these requirement lists, when I was working as CTO for a German DAM integrator. Surprisingly, most of these lists contained exactly the same or very similar requirements.
So could you draw the conclusion that nearly all companies have the same needs? No, that is not the case! It is more of a reflection, that the product owner does not exactly know what the needs of the different users are and thus, tries to define the requirements in a general way.
To be honest that is neither efficient nor correct! So I asked myself about ways to more efficiently and quickly evaluate software. For project management I have been exclusively using the scrum framework for many years. The success of my projects was massively improved by switching from classic project management to scrum, so why not try to adapt some of these methods for the evaluation process of software. The outcome was an agile software evaluation process that can be divided into three significant steps:
First step: Identify your stakeholders and create their most important user stories!
For each company stakeholders play a very important role. The stakeholders in our case are individuals or groups, who will directly or indirectly benefit from the use of the new DAM system.
Before you start your evaluation process you should carefully identify your stakeholders!
In case of our DAM evaluation process stakeholders could be:
– Purchasing Managers
– Creative staff
– Product Managers
– The board of directors
Once you have identified all stakeholder groups, you can start defining their most important user stories together with them.
A common user story for a Purchasing manager could for example be:
“As purchasing manager, who selects images for products in our Product Information Management (PIM) system, I need a method within the PIM interface to search for images in my DAM, select the ones I need, and link them up to products in my PIM. This spares me the additional effort of having to download images from the DAM only to then upload them into my PIM.”
It is not necessary for the evaluation process to define all of the user stories. In fact it is much better to just focus on the most important ones.
Second step: Choose the right partner:
These user stories are the base of the evaluation process. By defining these stories you want to make sure that the DAM vendors really understand your individual requirements.
Then, instead of sending out huge and largely meaningless Excel files, you will send the user stories to your potential partners (DAM vendors).
Based on the user stories the DAM vendors should prepare an individual demo for your company.
In some cases it might not be possible to demonstrate the whole user story within a demo, but the vendor has to give you a concrete idea how he would implement your story, using his product.
This procedure will also help you to get a feeling for the future cooperation with your potential partner.
– Does he really understand your requirements?
– Is he really reliable and interested in your individual needs?
– Can he offer solutions for your unique requirements, that possibly do not exist in the ‘out of the box’ solution?
Third step: Proof of Concept
Based on the outcome of the individual demos you select a vendor with whom you want to go on to the next step.
The third and last step is the proof of concept (PoC) of the system that you have chosen.
For the proof of concept the vendor needs to offer you a finished and “working ready” system! During that PoC it is very important that the stakeholders are able to use the system and that they test their user stories. It makes sense that you also define the acceptance criteria for your user stories at this point.
Let’s have a look at your user story again:
“As purchasing manager, who selects images for products in our PIM (product information management), I need a method within the PIM interface to search for images in my DAM, select the ones I need, and link them up to products in my PIM. This spares me the additional effort of having to download images from the DAM only to then upload them into my PIM.”
For our user story, we could define the following acceptance criteria:
– The search fields for DAM images in my PIM Interface need to have at least the opportunity to search for product numbers
– The images that have been found, need to have a preview
– It should be possible to link the images via drag and drop to the product in the PIM interface
The acceptance criteria help you to determine if a user story is fully implemented or not.
Upon successfully completion of the proof of concept the evaluation process has come to an end and you can proceed with the implementation process of your new DAM system.
Finally I would like to summarize the most significant advantages of the agile evaluation process:
The user stories are the heart of our process!
By carefully defining the user stories together with your stakeholders you ensure that the new software will really fit the user’s needs. The user stories are also a perfect tool to help select the right partner for your project. At the individual demonstration of the software, again based on your user stories, you will get a feeling if your potential partner really understands your needs and if he/she is really interested in fulfilling them. During the proof of concept you not only gather the first feedback from your stakeholders, but also get a good impression how your potential partners will work together with you during the implementation process.