How to Ensure Feasibility, Viability and Desirability of a Digitization Project
Sclable Insights — Interview with Jan Hilmar, Business Design Architect
Talking to someone with such a rich background like Jan Hilmar, is always a great experience. Jan has a PhD in mathematics, started coding as a sidekick, turned it into his main job and thus helped to save Polaroid Film with what was known worldwide as The Impossible Project. Now he supports Sclable’s clients to succeed with their digital transformation efforts int the role of a Business Design Architect.
This story is about #BusinessDesignTechnology, #SolutionArchitect, #ProductOwnership
Hello Jan, please tell us about your background. What did you do before you joined Sclable?
Originally, I studied mathematics and have a PhD in the subject from Edinburgh university. During my studies, I tried to earn a little extra money on the side and started coding websites. The side job turned into the main job when, on returning to Vienna, I got a job at a company selling expired Polaroid Film — later to turn into The Impossible Project with the mission of saving Polaroid film from extinction. There, I was in charge of maintaining and further developing both the online shop and their home-grown “ERP” system, all hand-coded in PHP.
With the company quickly growing and moving towards standardized software, I then moved on to another photography-related business when I joined the LeicaShop team in Vienna. I was put in charge of replacing their outdated ERP system with a new solution — not an easy task, as they specialize in the sale of second-hand cameras and there were no off-the-shelf solutions out there that fulfilled their needs.
So, once again, I decided to get my hands dirty, gathering requirements throughout the entire company and turning them into a custom-tailored software, matching their needs exactly and driving efficiency in the company — a single-person effort, as they had no budget for a second-team member.
In order to save myself some work, I turned to a framework made for modelling business requirements that supplied a skeleton application very quickly — the vendor was called Sclable, a small Viennese startup. I received a lot of great support during my work at LeicaShop and built a good relationship with Martin Sirlinger — so good actually that he offered me a job once I had switched LeicaShop over to their new ERP system. They are, to this day, still using the custom-built solution, as they have yet to find a replacement that matches their requirements as well.
Your LinkedIn Profile tells me that you are a Business Design Architect. What a cool job title by the way 😉. But what is a Business Design Architect?
When I introduce myself with this job title, I always like to supplement it with a more understandable description: I am in charge of leading a project through the entire lifecycle, from strategy to scale. A BDA can be seen as an internal technical product owner, gathering business needs together with the customer, translating them into a concept in close collaboration with a UX Architect.
A BDA is responsible for formulating User Stories and getting the project ready for implementation. During implementation, he/she is in charge of representing the customer’s view towards the dev team, and the dev team perspective towards the customer.
The BDA is in charge of ensuring that agreed on features can be delivered in the agreed in time while maintaining a high quality of the product.
This does, however, not mean that the BDA is in charge of micro-managing the team — our Scrum teams work independently, supported by the BDA providing them with the input they need to understand what the customer needs and why and how to best implement the software.
That sounds like a very exciting but also an intense role. But isn’t this just a new name for project manager though?
A BDA is much more similar to a Scrum product owner than a project manager. More than just coordinating the team (which is not the BDA’s main task), the BDA is in charge of ensuring the success of the project. Together with the UX Architect and the development team, he/she is in charge of creating a concept together with the customer that produces a product that fulfils all three pillars of product development: the product needs to be desirable (fulfil high standards in usability), technically feasible (within the current limits of technology) and viable from a business perspective.
During implementation, the role of the BDA turns into an internal product owner. The BDA is not handing requirements from the customer down to the development team but continues to cooperate with the customer to formulate new feature requests, always keeping the goals of the project in view. In this role, it is not uncommon for a BDA to question or even reject feature requests formulated by users if they are not in line with the goals of the project.
So BDAs embrace a very complex system and the relationship between the project’s canvas and scope as well as the people involved. As high-end tech consultants, Sclable’s mission is to bridge the gap between the business and the design aspect and to navigate the technology to create real value for the clients and their customers. How do you master navigation in this triangle?
At Sclable, we always work as a team of a UX Architect and BDA on projects — in some larger projects, we also involve a Service Designer to keep the bigger picture in sight. Between the BDA and UXA, we have a clear separation of responsibilities, with the BDA ensuring the viability of the solution via market research and business analysis and the feasibility by falling back on his/her experience in software development.
The UXA, on the other hand, always takes on the user’s perspective. In the interaction between those roles (business vs user/technology vs user), the result is a concept that manages to fulfil on all three pillars.
We can’t obviously be experts in every technology, breathe every business aspect. How do you make sure you work on eye level with the client and create value right from the start of the project?
With new projects, the challenge is always to get into a new subject area quickly. As usual in the consulting business, the key is to always be one step ahead of the client.
The basics are to analyze the company and the market, trying to understand the ecosystem our client operates in before we speak to the client. We then do a series of focused workshops where we use various tools from Design Thinking to the client’s key processes and help the client understand their own business better — at the same time, gaining valuable insight into the company and the problems they are currently facing.
We then use our knowledge obtained from other projects too, in a second step, offer potential solutions to the problems we identified — on a UX, business and technological level.
So we need a way to really collaborate with our clients. That’s a shift from a classic client-service-provider relationship to a more collaborative model, right? How do clients react to that? Are they always ready for that when you start a new project?
It really depends on the client, and how much experience they had in the past with “classical” software development vs product development. In some cases, clients are already used to an agile mindset and happily embrace our way of working, including the need to make key people available for workshops and pull them out of daily business (which is a big investment our clients make).
In other cases, we need to do some onboarding of the client (usually the Product Owner) into our way of working, explaining why we want to talk to experts, conduct interviews, see the factory and even pull key people into workshops. Most of the time, our clients quickly understand why doing things the way we do will produce a better outcome and are happy to collaborate with us.
In the very rare cases where a client absolutely insists on a classical software development route with fixed requirements formulated by the business without talking to experts, we are not the right partner for them.
How can I imagine the role of the BDA in daily business?
Depending on the phase of the project, I spend my day doing research, preparing or running workshops with clients, or formulating user stories.
A lot of my day is spent in meetings, coordinating with clients of colleagues, or in front of whiteboards, drawing up concepts and visualizing potential solutions together with the UX Architect.
In later phases, I spend a lot of time preparing for and participating in Agile Ceremonies: User Stories need to be prepared for a backlog refinement session, experts need to be contacted to provide missing information, the Product Owner needs to be supported in prioritizing User Stories, the team needs my input in answering open questions that pop up during backlog refinement. Depending on the project setup, I may also do some QA on user stories and need to review accepted User Stories in order to complete them.
I use Sprint Reviews and Standups to stay up to date on development progress in the team and provide my input, trying to remove roadblocks for the team to ensure that they can work without impediments. On the other hand, I communicate the project status to the client’s Product Owner.
Your counterpart at the client’s side is the Product Owner, right? What makes a great relationship between you and the client’s Product Owner? How do you onboard with a PO?
The most central role on the client-side is undoubtedly the Product Owner. This one person can make or break a project. A good Product Owner is well connected inside the company, knows whom to contact to get at needed information and - most importantly - needed decisions.
Ideally, he/she has worked in an agile environment before and understands that software development is an iterative process. If the product is a ship, the client’s Product Owner is the captain of the ship who needs to decide the course of the ship. I can support him/her in the decision-making process, but ultimately, the decisions need to be made from inside the company by their Product Owner.
In a good relationship between BDA and PO, we have regular alignments. The PO is present in all workshops with experts and always keeps the “big picture” in mind. Our relationship is on eye-level, me supporting the PO in making decisions, outlining which decisions are needed and helping her/him formulate the decisions in a way so the key people at the organisation can make them quickly. I help the PO in structuring the required information for a smooth implementation, always looking two steps ahead in the product timeline.
As a start of the working relationship, it usually pays off to have a small onboarding workshop with the client’s PO. We introduce them to our way of working, outlining our product development process and the basics of lean startup and agile software development. At the same time, the PO has the chance to introduce his/her company to us and give us a deeper understanding of the environment and concrete challenges the company is facing.
If you’d need to describe the three topmost skills a BDA needs to bring to the table. What skills would that be?
The number one key skill is Communication: most of the work done by a BDA comes down to communicating with the PO and the development team.
Secondly, structuring information is incredibly important for a BDA: we are constantly translating between business needs and technical requirements and need to be able to translate one into the other. In workshops, we need to ensure that we guide the participants in a way to have a tangible result as an outcome.
Finally, flexibility and the ability to quickly get into a new environment, learn the ins and outs of the client’s line of work and understand their problems deeper than they do is key.
Our success is also defined by living lifelong learning if you like, a so-called Growth Mindset. What’s the next thing you want to learn?
I always strive to improve on my skill set. New workshop techniques, a deeper understanding of topics such as the application of artificial intelligence are only a few items on my list.
Currently, the most important topic is to quickly understand what the COVID-19 situation means for our clients and how what technologies will play a key role in a future where most of what we have taken for granted for years is suddenly uncertain.
This article was written for Sclable’s blog on Medium.
If you liked it, give it a clap and share if you ❤️
