Almost three months ago, Jean-Francis Ochs and I reached a simple conclusion: across many client engagements, the problem does not immediately come from the technical solution. It starts much earlier, when the need must be understood, challenged and formalized.
01A recurring problem across many projects
With each new engagement, we often encounter the same difficulties: requirements that are too broad, insufficiently detailed documents or important decisions that have never really been formulated.
Clients generally know their business and the problem they want to solve. But they do not always identify every implication of the request: exceptions, user roles, necessary data, management rules, dependencies with existing tools or even the criteria that will allow the project to be considered successful.
In certain cases, better scoping could have reduced the cost of the engagement. It could also have prevented some of the frustration that arises when the team discovers too late that a request was poorly worded, incomplete or interpretable in several ways.
This is not necessarily the fault of the client, the AMOA or the developer. The need evolves naturally over the course of the discussions. The problem appears when this development is not sufficiently structured and the gray areas are not identified before implementation begins.
02The search for a solution
Once this observation was made, we started looking for a solution capable of helping the people responsible for collecting and formalizing the need.
Our goal was not to replace the AMOA, the functional analyst or the project manager. On the contrary, we wanted to provide them with a tool capable of supporting their work: helping them to ask the right questions, identify missing information and delve deeper into subjects that seem obvious at first glance.
We naturally turned to artificial intelligence. A conversational model is particularly suited to this type of situation: it can analyze an initial formulation, ask for details, question certain assumptions and help to gradually structure the need.
03An assistant for AMOA teams and business analysts
The idea of AskLeopold is simple: to act as a companion to the AMOA team or analyst throughout the scoping phase.
The tool must be used from the first exchanges, when the need is still imperfectly defined. Its role is to ask useful questions, including those that may seem uncomfortable or premature:
- what problem are we really trying to solve?
- which users will be affected?
- what are the exceptions to the standard process?
- what data is needed and who is responsible for it?
- what technical or regulatory constraints must be respected?
- how will we measure the success of the project?
These questions may seem simple. However, their absence is often the cause of the most costly misunderstandings.
04Why create a real tool?
At the start of the project, we considered two options. The first consisted of producing a best-practice guide: a method, a list of questions and some document templates intended for those responsible for scoping.
This approach would have been simpler and faster. However, it had an important limitation: a guide remains a static document. It may be forgotten, partially applied or fail to adapt to the particular context of an engagement.
The second possibility was more ambitious: developing a tool capable of truly supporting the user, adapting to the answers obtained and refining its questions as the discussion progresses.
As is often the case in our joint projects, we chose the most complex path: building the product that we would have liked to use ourselves.
05Why vibe coding?
For several years, Jean-Francis and I have been working on what we call our evening and weekend projects. These are projects developed for ourselves or for some of our clients, outside the usual formats of large IT projects.
Their scale rarely interests large IT services firms. However, these applications can bring strong added value to the companies that use them. They often respond to a specific need, with a limited budget and a strong expectation of speed.
AskLeopold is not a small project, however. Without the support of AI-assisted development tools, we would not have had the capacity to produce an application of this scale in the evenings and at weekends. The project would probably have required much more time, to the point of becoming incompatible with our other professional activities.
Vibe coding allowed us to accelerate development while maintaining control of the design. We were able to define the architecture, formalize the development rules, control the technical choices and direct the agents towards the product we had in mind.
The important point is this: we did not ask an AI to decide alone what AskLeopold should become. We gave it a framework, requirements, a product vision and a working method.
06Three months to make the idea a reality
In three months, we went from a shared observation to an application available online. We had to transform a general idea into a user journey, design the assistant's behavior, structure the project and build an interface simple enough not to add complexity to a scoping phase that can already be complex.
AI-assisted development allowed us to significantly reduce the time required for implementation. It also gave us the opportunity to iterate quickly: try an approach, evaluate it, question it and then improve it without waiting several weeks between each version.
We are proud to have brought this project to a first usable version in just three months. This doesn't mean the work is done. A product continues to evolve through contact with its users, their practices and their feedback.
We are nevertheless convinced that a tool like AskLeopold can change the way certain teams approach their projects. Not because it replaces their expertise, but because it helps them spend more time on the right questions before the wrong answers become costly.
07And now?
The next step is to test AskLeopold in more real-world situations, to listen to users and to gradually improve its support.
We want the tool to remain simple to use, demanding in its questioning and useful both to experienced professionals and to people who occasionally have to formalize a need.
The starting point remains the same: a few good questions asked at the right time can avoid weeks of unnecessary development.
Comments
0 commentsNo published comments yet. Be the first to respond.