{"id":1842,"date":"2023-01-13T14:32:14","date_gmt":"2023-01-13T12:32:14","guid":{"rendered":"https:\/\/dam-evangelist.blog\/?p=1842"},"modified":"2023-01-13T15:01:43","modified_gmt":"2023-01-13T13:01:43","slug":"in-3-schritten-zur-agilen-software-auswahl-1-die-stakeholder-und-ihre-stories","status":"publish","type":"post","link":"https:\/\/dam-evangelist.blog\/en\/2023\/01\/13\/in-3-schritten-zur-agilen-software-auswahl-1-die-stakeholder-und-ihre-stories\/","title":{"rendered":"In 3 steps to agile software selection – 1. The stakeholders and their stories"},"content":{"rendered":"

\"Agile
\nThe stakeholders and their user stories is the first part of my three-part series on agile software selection. In my following posts, I would like to go into the three phases that are passed through in this process. Since my blog is known as a DAM blog, I will of course do this on the basis of the selection of a DAM system.
\nThe start of this selection process presupposes that the need for a DAM system has already been recognised. In practice, this part, convincing companies and users that they need a DAM system, is often the most difficult, but here I assume this hurdle has already been taken.<\/p>\n

For many companies it is a big step to find a “handy” entry into a software selection process<\/p>\n

How should be proceeded?<\/h4>\n

Do I just invite the usual suspects that I find through the first Google search (thus finding the providers that are happy to pay a lot for Google AdWords, but not necessarily the one that is best for me)?<\/br>
\nFor example, do you use the environment of your CRM\/ERP partner (usually SAP…), or do you even write long lists of requirements that usually make little sense?<\/br>
\nDefinitely none of these methods are effective and efficient!<\/br>
\nManufacturers or future partners such as integrators are not invited to an individual demo until they are clear about the path they want to take with the new system and the core benefits they want to derive from it. Drawing up lists of requirements, on the other hand, is a pure time killer that unnecessarily delays a project. Moreover, these lists usually contain requirements such as “It must be possible to load files in the original.” A necessary and important function, but a DAM that does not fulfil this, is not a DAM.<\/p>\n

From my years of practical experience in agile software development, I decided some time ago to adapt parts of this process for the selection of a DAM system. Regardless of the industry and the requirements, this selection process can always be used, it is goal-oriented, takes little time and is implemented very quickly.<\/p>\n

The first step in this process is the selection of stakeholders. Stakeholders are persons\/users who want to\/will benefit directly or indirectly from the use of the DAM system.<\/p>\n

On the side of the future DAM client, there should also be a role similar to that of the product owner in the Scrum process. It makes sense to complement the internal product owner with an external partner who has sufficient experience in the selection of a DAM system, who knows the DAM market well enough, who can accompany and evaluate the introduction of the system and who, above all, has knowledge of the “usual” pitfalls of such a process.<\/p>\n

Identification of the stakeholders:<\/h4>\n

An immensely elementary and important point. The stakeholders will later work with the system or want to see that time and money can be saved by using the system. This choice has to be made very carefully.<\/p>\n

Here, too, is the question at the beginning:<\/br>
\nAre there also external stakeholders? This is especially important for agencies or media service providers who want to use the DAM together with their customers or even offer it as a hosting solution. In many cases, the focus is on the wishes of the (end) customer and it is important to address the right people as soon as possible.<\/p>\n

Once the individual, I’ll call them stakeholder groups have been identified, it is important to get them on board when creating their user stories.
\nSome examples of common stakeholder user stories in the DAM selection process can be found here:
\nDAM selection process: Five typical user stories you should know<\/a>!<\/p>\n

\"Agile<\/p>\n

When it comes to formulating and implementing user stories, the devil is often in the detail:<\/h4>\n

Some product owners believe they know exactly what their stakeholders’ requirements are, but unfortunately this is not always the case. Often, requirements only differ marginally at first glance, but their implementation is completely different. The only solution to this problem is to get the stakeholders on board and work out the most important user stories together with them.<\/p>\n

Basically, in the process of a selection procedure, it is not absolutely necessary to create user stories that are to be set in stone (this is rarely the case with user stories in general, as they are subject to iterative development), they rather serve to identify the most important stories of the stakeholders and thus to accelerate the selection procedure on the one hand and to qualify future partners on the other.
\nThe first step, identifying the stakeholders, working out the user stories together with the stakeholders is the elementary prelude to the agile selection of a DAM system. It is essential that this step is carefully planned and executed, as it will form the basis for the entire selection process.
\nIn my next article I will deal with the selection of the right partner (software vendor and\/or integrator) for the upcoming project!<\/p>\n

Do you have questions about the selection process in general, or about step 1?<\/p>\n

Please contact me, I will be happy to help you:<\/p>\n

 <\/p>\n

\n