Successful IT products are a result of harmonious teamwork. The technological competence of the contractor is only one element of the puzzle. Proper coordination of activities, substantive communication and appropriate selection of people influencing the shape of the project are also essential for final success. How to ensure that things go well and the project is successful?

Two heads are better than one. And three, are better than two. But does a greater number of "heads" make it easier to achieve goals? It can be quite challenging to take into account multiple opinions and reconcile different interests. Especially when creating advanced IT projects for large organizations.

These three factors are key to overcoming or avoiding difficulties:

• proper selection of project participants-stakeholders,
• reliable, substantive communication,
• a thoughtful sequence of actions. So little and yet so much.

A simple recipe for obstruction

While working on the project, each participant should be able to express their opinions freely. Even if this means going beyond their own competence and commenting on the opinion of a colleague from a neighboring department. Of course, the exchange of opinions should be appropriately moderated and the final decisions should be made by the "owners" of particular areas. Different types of methodologies, e.g. Scrum, serve to maintain order during work on the project. However, sometimes even they fail, or they fail because they are not applied conscientiously enough.

One of the unpleasant effects of poor project management is a slowdown of work progress. To put it simply: obstruction. This usually occurs when someone uses their right to express an opinion to block a project. Such situations tend to occur when an opinion, which should be expressed at the right time and place, is not expressed or is ignored. The reason for this usually lies in the lack of a clear decision-making path and inadequate organization of (team)work.

The consequences of such events can be severe. They force adjustments, slow down work, generate costs. In extreme cases, they expose the project to failure. Example? Let's assume that we are conducting a pre-implementation analysis prior to launching the CRM system. We managed to precisely define business objectives, but we somewhat neglected issues related to document circulation or IT security. The legal or IT department raises objections that block the project. The team must go back a few steps and take these reservations into account. Otherwise, the product will be a failure containing system gaps or creating legal risks. The number of man-hours increases, the planned start of the system is delayed, the company incurs additional costs.

The right person in the right place

What went wrong? We have already written about it. It is about three key factors that can basically be put into one simple sentence: We did not talk to the right person early enough. It is simple and complex at the same time. For example, in terms of responsibility. It lies both with the agency as a product developer and with the client as the product owner. Of course, the scope is different in both cases. The agency is responsible for the coordination of work on the product, cooperation with the client in defining the product and managing the project from the conceptual stage. It should also support the client in organizing its activities, but not necessarily poach on its territory. So what is the client's role? Strategic and yet “personal” at the same time. The idea is to select competent individuals and decision-makers who will be able to participate in the project on behalf of their departments. In such a way that the opinions they formulate take into account strategic issues and best serve the interests of the client. So little and yet so much.

Product workshops: in search of a common goal

What's next? A conversation. A lot of discussions. The client indicates the right persons (let's call them stakeholders), the agency asks them questions and listens to what they say. This stage of work is known as product workshops. There is no role model for conducting such meetings, however, there are several good practices that facilitate reaching a common goal. Once the agency knows who it will discuss the project with, it must fill the interlocutors in. Stakeholders should, therefore, be properly briefed in advance. So that they know what the project is about and what issues need to be clarified. It is worthwhile to ensure that communication is concise and informative. Overwhelming stakeholders with a pile of data or thoughts will not encourage them to cooperate and react quickly.

Properly selected stakeholders familiarized with the topic are usually willing to help. They are usually people with initiative who simply want to support their company's project in the best possible way. During the product workshops, stakeholders assess the problem from the perspective of their "domain" and present the position of their departments. In this situation, it is crucial that stakeholders enjoy the full confidence of their colleagues and superiors. If a junior employee gives an opinion on the project, it may happen that his or her comments will be questioned by the person in a higher position. Result? Delay in the work and even the need to make major modifications to the project. On the other hand, if a head of the department is engaged as a stakeholder, it is worth making sure that he or she will have time to get involved in the project and react without delay.

Why, why, why?

Once the stakeholders have addressed the issues outlined in the brief, which they have previously studied, we can move on to a question and answer session. The idea is to explain the individual issues and to resolve the relevant concerns. The "X whys" method works well here. It consists in asking the question "why" several times in an attempt to determine the causes of the problem or reasons for proposed solutions. It is based on the 5 Whys or 5W method, which involves five steps in the identification of the root cause of a problem. However, the number of "whys" is a matter of convenience. You can get to the heart of the matter even the second time. It is important to follow a cause-effect logic and not jump to conclusions. Example? Stakeholder: It is important that users receive all documents by e-mail. Agency: Why? Stakeholder: Because we have to meet the information obligation. Agency: Why? Stakeholder: Because that is required by law. And everything is clear.

Deductive reasoning

This type of approach helps to capture important dependencies and details. However, it should be used prudently to avoid fastidiousness. The product workshops should result in a coherent vision and a structured action plan. Therefore, the most important issues are addressed first. We ask stakeholders about the key requirements. Then, about limitations. Next, about the possibility of overcoming constraints or alternatives. The next step is simulation: an attempt to create an ideal version of the product and indicate its optimal features. Even if not all suggestions can be implemented, they can provide inspiration for designers.

Once you know what is important and what is not, you work out the details. Marketing team asks about conversion tracking and traffic sources, lawyers list the clauses that need to be included in the documentation and developers identify possible security gaps. Keeping the right sequence of actions protects against chaos and prevents disorder in the work on the project.

The man in power

We have not yet mentioned the most important person: the product owner. It is a kind of grey eminence, present but "invisible". Such an individual listens, notes, analyzes, but does not interfere in the process of collecting and discussing data, presenting ideas, formulating suggestions. However, when the workshop comes to an end, the product owner makes a huge effort of "great synthesis": summarizes the work, draws conclusions, integrates partial observations and comments into a coherent vision of the implemented IT product. At this stage, of course, he or she can also benefit from the agency's support, but it is the product owner who ultimately decides on the final shape of the project.

If you are looking for a partner who will implement your project in a thoughtful and efficient way – let's talk!