In this article, you will discover the most common challenges encountered during business analysis – both in the context of ITSM and other recommended solutions for handling business processes; wherever there is a need to obtain requirements and understand them.
1. Lack of a unified glossary of terms
Many times I have been a participant in meetings where each participant uses the same words in a different context. Many terms have several meanings, moreover, each industry or field operates its jargon and words that are specific to it. This generates the risk of misunderstanding. And it’s not always about misunderstanding by an analyst or consultant. I often encounter misunderstandings within the organization I work with. The result of this misunderstanding can be the implementation of a system, or to narrow it down a bit – functionality that doesn’t meet expectations precisely because someone misinterpreted something or, worse, guessed its meaning. It is extremely important to create a dictionary (the earlier, the better) that we can refer to at every stage of the work. The dictionary should be widely available and kept up-to-date.
2. Stakeholder identification
Imagine that you are working for several weeks to gather requirements for a selected service. You already have a set of information, so you hold a meeting where the whole thing will be summarized and approved, so you can move on to implementation. And suddenly, out of the blue, a new person shows up at this meeting, who, hearing what has been worked out, grabs his head and turns everything upside down. Of course, I am exaggerating a little. As a rule, objections are to certain elements. Nevertheless, let’s consider: why wasn’t this person present at earlier stages? Why didn’t it occur to anyone that Arek or Marzena (random names) have relevant data on the selected topic? This is due to the earlier failure to include the person in the group that is to deal with the determination of pre-implementation requirements. So, from the inaccurate definition of the stakeholder group.
Another similar, situation is when, during a workshop, someone remarks that “this is something we need to ask Ark about,” or “probably Marzena knows how it works.” And it turns out that we can’t move on to the next steps because the key person is absent/not present. The result is that additional hours, days pass, and we don’t get any closer to the end, so before proceeding with the analysis, we need to think carefully about WHO should take part in the discussions and preparations. In my opinion, it is better to involve more people than to leave someone out. If a person contributes nothing to the arrangements, nothing bad will happen, while if someone of value is left out, the whole thing will drag on unnecessarily.
3. Misunderstanding of provisions in contracts
Another challenge relates to contracts and documentation. When analyzing documents with contractors/suppliers that support the organization, it happens that each party understands some issues differently. I know this sounds like the lack of an elaborate dictionary from point 1., however, it is worth isolating this part as equally relevant to requirements gathering. Document analysis is the best time to clarify and define terms. The system’s functionalities will relate to the requirements extracted just from these contracts, so it’s important to fully understand why the system works this way and not that way.
4. Availability of stakeholders, or rather, their inaccessibility
The work of gathering requirements and implementing an ITSM-type system does not involve the contractor developing everything himself, installing it, handing it over to the company to use. This way will work with simple applications that de facto a company can install on its own, “straight out of the box.” In the case of solutions that are supposed to streamline a company’s daily business processes, it is extremely important to have good ongoing contact between the contractor and the client organization. Unfortunately, there are situations when the customer asks for a meeting… in 2 weeks, or by phone “out of the blue.” Neither of these two options is good.
And here is a request: remember that, as a rule, the contractor will not deliver anything on his own. He needs support, cooperation, and contact with the principal. We like to work together on a partnership basis. We have a common goal and we strive for it. Everyone knows the scope of his responsibility and knows that what we are working on is of value to both parties. For us, it will be another successful project and experience that we can add to the portfolio. For the client, a new tool that streamlines and automates daily work and makes it easier.
5. A few words at the end
Implementing an ITSM platform is a project that requires planning activities and good coordination. ITIL, on the other hand, provides us with good practices but does not prohibit us from adapting them to our needs. All this is done so that the result is best adapted to the specifics of the organization. If you need support or consultation in building a service or implementing some process in your company, feel free to contact us!