Artificial Intelligence / Your Project
From Conceptualization to Day-to-Day Operations: How We Manage an Artificial Intelligence Project
Six stages, one deliverable for each, and two points at which the project can be halted—without it being considered a failure.An artificial intelligence project rarely fails because of the model. It fails because of a prototype that never leaves the lab, a server purchased before it’s needed, or a platform that no one maintains on Sundays. Our method is designed to avoid these three pitfalls: nothing is ordered before the prototype is ready, nothing goes into production without someone to operate it, and each step produces a deliverable that you keep.
Three ways to fail—and none of them is technical
We've seen these happen to others, and we've developed a method to prevent them from occurring. Each one corresponds to a step that's skipped.
The prototype that never leaves the lab
It’s up and running, it’s impressive, and it was presented to the committee. But it was built using selected documents, without the actual rights and without integration. Putting it into production would mean starting all over—and no one has budgeted for that. It remains a prototype, and then it fades away.
The prototype is built using your actual data, with your actual permissions.
The server purchased prior to use
Management wants local solutions, the supplier has a set configuration, and the equipment arrives three months before we know what it will be used for. Sized at random, it’s either too small for the upcoming project or too large for the one that remains. And it starts to become obsolete from day one.
We base our sizing on the prototype's measurements, not on a catalog.
The platform that nobody maintains
The project is delivered, the project team disperses, and six months later the model is out of date, the index is no longer backed up, and the responses have drifted without anyone reviewing them. It wasn’t the technology that failed—it was the absence of someone whose job it was to handle this.
Day-to-day operations are determined before the system goes live.
Six steps, one deliverable for each
They follow one another in this order, and two of them end with a decision that can be “we’re stopping.” That’s what makes the other four possible.
The Framing
The use case written according to our twelve-point model: the problem, the human element, the data and its quality, writing constraints, integrations. The status of rights and standards. Baseline metrics, recorded before anything changes.
Two to four weeks, depending on the number of departments involved.
Architecture
At Microsoft, at your premises, in a hybrid environment, or on-site—the decision depends on data sensitivity, volume, latency, connectivity, and the cost threshold over three years. Technology comes last. If hardware is required, it is sized here—and ordered after the next step.
The prototype and the first decision
Using your actual data and your actual permissions, for about 20 users, over three to four weeks. On existing or borrowed equipment when physical space is a factor. We measure accuracy, latency, actual usage, and actual costs—against the initial metrics.
This is where the project can end. If the measures don’t hold up, we document it, along with the reasons why and what needs to be changed. A prototype that concludes “not now” has done its job.
Testing and Validation
Any hardware, if present, has been installed and connected. Integration with Teams, SharePoint, Dynamics 365, theERP , or industrial systems. Access rights have been tested: a person without access rights to a specific area must not be granted any. Human interaction has been tested. Logging has been verified. And validation must come from users, not from the committee.
Industrialization
A phased rollout, department by department. Training by job role, not by tool. On-site supervision: someone who notices when response times drift, latency increases, or resource usage exceeds limits. An operations log that can be used by a team other than our own.
Second decision: Who will operate the system—us, as part of our managed services, or your team, whom we will train? This decision is made now, not later.
Day-to-Day Operations
Templates updated according to a set schedule, tested against your questions before being replaced. Flagged responses reviewed. Permissions reviewed. Backup and rollback procedures tested. The invoice reviewed every month by someone whose job it is to do so. And the quarterly review that outlines what the next steps should be.
Estimated timeline from the first “ assessment ” to production deployment: two to four months for a use case at Microsoft without hardware; four to six months when on-premises hardware is required, including delivery time. These are rough estimates, not commitments: measurement is part of the process. The first use case isn’t profitable; the third, built on the same foundation, is.
Governance and Security at Every Step
They are not a separate stage: they cut across all six. These four elements are established right from the first “ assessment ” and are put into practice right through to day-to-day operations.
Managing Agents as Digital Collaborators
Enterprise-wide agent management, what Agent 365 changes, and the decisions to make before implementing the third agent—three articles that cover the topic in detail.
Three Ways to Get Involved
The same as for all our projects, because an artificial intelligence project is an IT project: a scope defined in writing before we begin, the same team members throughout the project, and a clearly stated limit.
One stage, one scope, one price
Assessment, prototype, production: each phase is contracted separately, with its own deliverable. You decide on the next phase once you know the outcome of the previous one.
An engineer on your team, for as long as you need
When your team is leading the project but lacks a specific skill—such as literature review, integration, or sizing. Authorized LSE since 2018.
We stand by what we have built
Templates, monitoring, costs, backups, quarterly reviews, with a commitment to meeting deadlines. As part of our managed services—and we also maintain systems we didn’t build ourselves.
What we’re asked to do before we begin
Five questions that come up at the first meeting, and our answers.
How long does it take, and how much does it cost?
Two to six months, depending on the architecture, and a cost that’s determined in stages, not for the entire project: a assessment provides a quote at the first meeting; the rest depends on what they find. What we refuse, above all, is a flat rate assessment —it would be inaccurate one way or the other.
What if the prototype doesn't hold up?
The project wraps up with a report explaining why it ended and what needs to be changed. You keep this initial assessment, the data map, the reviewed terms of reference, and the baseline indicators—which will be used for the next project. This is specified in the scope from the very beginning.
Who operates it next?
You or us. The decision is made at the time of implementation, not afterward, and it comes with a price tag. If you choose to do it yourself, we’ll train your team and remain available as a second line of support. If we do it, it’s a managed services contract with a guaranteed timeline.
Who owns the deliverables?
It’s up to you. The use case document, the architecture, the rules, the operations manual, the metrics—everything is written so that another team besides ours can use it. That’s the key to ensuring you remain independent.
Should we start with your offices or with Copilot?
Neither, as a matter of principle. It depends on the use case, and then on what the data dictates. Sometimes the answer is “Copilot in your licenses is enough; no infrastructure project is needed”—we state this when it’s true. The architecture comparison tool provides an initial answer in seven questions.
Related pages
What comes before the project, what fuels it, and the projects that have already been carried out.
Identify the right use cases
When the case has not yet been named: the five questions that define a process, and the workshop that asks them.
View the page ArchitecturesWhat kind of architecture is right for your project?
The criteria, a comparison of the four architectures, and a sample answer in seven questions.
View the page Use CasesThe entire library, organized by topic
Each case is written according to the same twelve-point template, while retaining what is human.
View the page ServicesHow We Work on All Our Projects
The nine areas, the three ways to get involved, and what’s left on your desk at the end.
View the page OperationIT Outsourcing: Maintaining What Has Been Built
Second and third tiers behind your team, with a time commitment—for an artificial intelligence platform as well as for everything else.
View the page ProjectsWhat We've Done So Far
Thirty published projects, including an CRM with support and classification, a connected contact center, and a standalone controller with Azure IoT.
View projectsLet's talk about your project
Describe your use case, and we'll get back to you with a scope and a price
The problem, the data, what shouldn't be disclosed, and what you've already tried. We'll come back to the scope of the first assessment, its duration, its cost, and what the subsequent prototype would allow us to measure.
What we offer is the opportunity to meet the engineers who will do the work. Assessment, prototyping, and industrialization are all part of the project. The initial discussion, however, costs nothing.
Renens, Sion, Châtel-Saint-Denis
Microsoft Solutions Partner and Dell Technologies Gold Partner. The same engineers who handled everything from the initial assessment to day-to-day operations, including software and hardware.
Renens VD +41 21 806 37 15
Sion VS +41 27 552 00 22
Châtel-Saint-Denis FR +41 26 322 59 05