Blog Technical posts

Bridging the Gap Between Theory and Real Projects

8 April 2024 Alessia FD · Social media manager

An Interview with Matteo Forni, Product Designer

Alessia: Let’s talk about how to bridge the gap between theory and the world of real projects. Matteo Forni, our product designer, will provide some context for us. Matteo, when does this gap occur?

Matteo: This gap mainly occurs in the B2B industrial sector, particularly when the supplier and client are two large, structured organizations. In both organizations, there are roles that have developed over time where individuals believe – often backed by substantial experience – that they possess the knowledge to design and develop a new product; in our case, a technological product. These roles, which we might call “centralizing,” hold both current knowledge – what is needed to carry out the development process of the new product – and previous knowledge, which often includes design methodologies that the client wants to maintain. There is also a forward-looking aspect, focusing on where the technological product should go.

In practice, the gap occurs between those who conceptualize and plan the design of the technological product and those who have to implement it – bringing to life everything derived from the preliminary design phase.

To align these two internal silos of the two organizations (client and supplier), a “manual” or specification document is often created. Both the supplier and client are confident that this document contains all the information needed to perfectly build a desirable, sustainable, and feasible technological product.

At this stage, there is no strategy between the parties that aims to consider the contributions of multiple stakeholders during the project analysis phase, which risks remaining incomplete.

Alessia: Why is it believed that this specification document is sufficient to carry out a project?

Matteo: It’s almost automatic, maybe even physiological, to think that you can convey information just by writing or representing it. This urgency to document is very characteristic of the environments I just described and is closely tied to hierarchical organizations, where these centralized figures rely solely on writing specifications to communicate with those who actually make the product. Few people who provide insufficient information.

Alessia: So, if I understand correctly, you’re saying that there are issues that create this gap. In summary, what are the main problems?

Matteo: We identify the first problem as the almost total absence of stakeholder management. When designing a new product, first of all, there is no selection of people who could bring value with their knowledge, and only a few “experts” are relied upon. This lack of stakeholder management affects the experts’ work, who find themselves having to handle a multitude of tasks, including drafting specifications and designing the functionalities of the new technological product.

In my opinion, this is a very important point, and where this gap exists, it is the designers’ duty to intervene at the start of the project: a project without stakeholder management cannot begin.

Another point, especially in the industrial world, is the tendency to consider design as an accessory that can help the development of a new technological product, but that is actually limited.

In reality, the design process offers a range of activities and opportunities to bridge the gap we are talking about. It is the supplier’s job to demonstrate that, with a specific approach, these issues can be reduced or at least limited.

Alessia: From what you’re saying, the specification document seems to cause more issues than actual benefits. Have you seen so many “document-centric” situations?

Matteo: In the B2B industrial sector, the “manual” for the technological product is prevalent, and yes, I have seen many of them, and I can attribute the gap between the two sides of the project to it. The specification document brings with it countless risks that put the relationships between those involved in the project in jeopardy.

A technical document needs to be understood, which takes time and must be analyzed. The final blow comes when, along with the technical document, an estimate is also requested. It is impossible to think that even the best technicians in the world, who might want to work in an agile manner, can make an accurate estimate that adds value to the project in terms of sustainability just by reading a technical document.

Negotiating some functionalities, and suggesting technological or usability solutions becomes very difficult when there is a detailed specification document involved.

Moreover, in the technical document, in my opinion, there is also an ethical issue.

Alessia: What do you mean?

Matteo: The ethical issue arises when people who plan do not implement procedures to adhere to a set of information that some stakeholders, who are not initially involved, could have provided.

For example, a stakeholder working in sales or customer service can bring a wealth of information to the project that genuinely protects the end-user. In the preliminary phase of the project, their involvement is invaluable because, in the B2B or B2B2C environment, the end user is not always immediately accessible.

The information lost in this very early phase creates an ethical issue that becomes apparent when the product is finished, because the product will not be able to meet some of the key characteristics that are crucial for the end user who will have to use the product.

Alessia: Still talking about the drawbacks rather than the actual benefits, let’s play a little game: if the specification document were a stakeholder, how would it be in your opinion?

Matteo: Surely, if it were a stakeholder, I imagine it would be like a student at the blackboard, parroting a topic from a book they liked best while ignoring the others assigned. This limits the development of concepts and the ability to formulate alternatives that might be advantageous for the design.

It could also be a student who, instead of preparing a group research project, prefers to do everything on their own.

It would be someone who can describe how to do something but would have difficulty explaining why a particular path needs to be taken. In our opinion, the path to creating a functionality or the entire product must be built starting from the relationships between the supplier and the client.

A stakeholder embodying a specification document would always have a ready answer and might struggle to leave room for alternative paths. Moreover, and we often see this when new technologies are needed, this stakeholder could fall into contradiction because they would constantly have to renegotiate their beliefs.

Another example: in the specification document, the languages with which the technological product must be developed are often mentioned. After an analysis and a quick discussion, it often happens that more convenient alternatives are found – not necessarily more convenient in general but more appropriate because for that type of project, for that opportunity, and for that solution, a different approach might be considered. This kind of assessment would be challenging to initiate with a specification document.

A fundamental aspect, which always ties back to the gap between those who plan and those who execute, is related to the right balance that every product should maintain between three key concepts: product desirability, economic sustainability, and technical feasibility.

However, in the specification document, one of the three aspects is often favored over the others. Why? Because, going back to the initial point, the planners are few, who base their knowledge on past experience. Instead of being a way to open up a range of options, the specification document is a breaking point.

Alessia: So, I vaguely get the impression that the specification document is not your favorite. But you know what I’ve always been taught? If there’s a problem and you don’t provide a solution, you’re also part of the problem. So, in your opinion, how can this gap be bridged, which could be destructive to a good idea?

Matteo: In collaborative design, bringing problems, bringing evidence, and bringing them to a specific context can collectively help solve issues that ultimately affect the entire project.

Alessia: How so?

Matteo: Well, definitely at the start of the project, a stakeholder management activity that defines the team that will follow the design of the new technological product is essential. This already identifies which roles can add value.

The key to reducing the excessive centrality of the specification document – and ensuring quality relationships that lead to better results – is the workshop. By workshop, we mean a series of structured meetings that follow an activity agenda, and these activities aim to identify opportunities, ideate solutions to then implement them, validate them, estimate them, and put them into practice. In this phrase I’ve said, if you think about it, there’s a bit of the whole process.

So, if initially, the opportunities were those defined by our big organization’s decision-maker, the workshop brings them to a more horizontal discussion level, where all stakeholders participate.

That’s why we conducted stakeholder management. Stakeholders who can discuss and negotiate what our decision-maker proposes and then work together to define a solution that includes the three fundamental points: the desirability of the finished product, economic sustainability, and technical feasibility.

This is practical. Because the objection could be: “Well, yes, all very nice. But after the workshop, what is the practical result equivalent to the specification document? Because even if the specification document as a concept is wrong, it still tells me a bit about where to go.”

The result of the workshop is the definition, collection, and gradual drafting of functional requirements that is tackled collectively.

This then allows those who develop and create the product to read the instructions and start the actual construction of the final technological product. These are some aspects.

With experience, we have realized that the workshop also has a significant impact from an economic point of view.

Writing a specification document that might have gone through three, four, or five versions and consists of 100, 200, or 300 pages, no matter how complex and complete it may be, takes a lot of time. We have found that the workshop is a slightly less precise and specific approach, but in a short time, it resolves more questions than the time needed to draft our specification document.

Even when organizing multiple workshops, each lasting 2 or 3 hours, the benefit remains significant. I usually try to estimate the cost of drafting a potential specification document and compare this cost with that of holding workshop sessions. Generally, even if the two methods result in different levels of detail, collaborative workshops prove to be more effective in achieving the final product objectives efficiently.

Alessia: Could artificial intelligence help us in these processes, which are quite simple but still carry great risks?

Matteo: As far as I’m concerned, the success of implementing processes like collaborative design relies on people rather than machines. What could be useful in this context is having a system for assessing the selection and gathering of requirements, which is something we are currently studying.

Let’s imagine being able to give artificial intelligence some context about the project we are starting; imagine that this context could also be enriched with numbers because, let’s be clear, we are not creating works of abstract art. We know very well, if our Tech Leaders are sufficiently experienced, how much it might cost to implement a core feature in the new type of technology product.

I think using artificial intelligence to assist with this evaluation, especially when making estimates that then define a project roadmap, can be extremely helpful.

Can this reduce the gap between planning and implementation, between these two environments that seem to be disconnected? Well, certainly not, because it is inserted in a fairly final stage of the process we have described.

However, it could reveal the errors that this disconnect generates, and revealing these kinds of errors at a stage where the actual construction machinery has not yet started can provide numerous advantages.

Alessia: So, I understand that we are still placing this experimentation in a final stage of the process. But what if it were done in the initial phase?

Matteo: In the initial phase, artificial intelligence could help uncover information and insights that could support those central figures in large organizations we talked about at the beginning. Of course, it would need to be “tamed” by a process; otherwise, it would have the same purpose, the same goal, and even the same terms of usability as a search engine.

We are experimenting with the involvement of artificial intelligence both in the pre-ideation phase and in the roadmap definition phase, trying to understand how to provide artificial intelligence with information packaged in a certain way, to then get responses that can be useful to the entire process. So, both in the initial phase and the final phase. However, it is important that there is a process, and the process must be defined by people. This is fundamental.

Alessia: So, I understand that we are still placing this experimentation in a final stage of the process. But what if it were done in the initial phase?

Alessia: I know we have already done a course in Florence, a course in Bologna, and we have more editions planned. Anyone interested in participating can sign up for the course waiting list and stay updated on upcoming dates.