A scope that's never framed
The developer executes the request as stated, not the real need. The investment then rests on assumptions that were never challenged.
Business Analyst
Business
analysis.
An idea has never been enough to make a project. You don't improvise as a Business Analyst.
Coding an idea is not the same as designing a project. Between the intention and an application that actually holds up, there's work most business leaders never see: scoping the need, arbitrating with the technology, securing the project legally and operationally. Without that work, a project moves forward, then stops holding together.
The reality check
Why business analysis
is critical for your project.
Compliance handled too late
GDPR, data security: whatever wasn't anticipated upfront becomes a legal risk discovered during an audit — sometimes after an incident.
A budget that drifts
Without upfront scoping, every mid-project adjustment costs more than expected. Timelines follow the same curve.
A compromised return on investment
The product exists, but it was built for a target that was never clearly identified: an asset that doesn't earn back what it cost.
The engagement
What a Business Analyst engagement
with Pixel Étincelle covers.
Dialogue with the client
Surfacing the real need, beyond the initial request. A project owner doesn't always have a scoped project — often just an intention.
Dialogue with the technical team
Translating the requirements into realistic constraints, and feeding technical limitations back to the client.
Security & maintenance protocols
Identifying what needs to be protected, backed up and maintained over time, drawing on recognized standards (ISO/IEC 27001 for information security, ITIL for IT service management).
Legal & regulatory framework
Checking GDPR compliance and sector-specific obligations from the design stage — not as a reaction to an audit.
Technical oversight when needed
When there's no technical project lead in place, I also take on oversight of the development team. I don't just write specifications — I make sure the project stays executable and consistent with what already exists.
Method
Methodology
and working framework.
I work according to a PDCA logic (Plan – Do – Check – Act):
Plan
Scoping the need
Assessment of the existing setup, definition of objectives and constraints (budget, timeline, compliance).
🔍
01✏️
02Do
Discovery & specification
Requirements-gathering workshops, process mapping, drafting functional specifications and user stories.
Check
Cross-validation
Validation with stakeholders, adjustments, checking consistency between the business need, technical constraints and legal framework.
✅
03🚀
04Act
Delivery & oversight
Delivery of the artefacts (requirements document, specifications, user stories), and, if needed, oversight of the development team to ensure proper execution.
This approach makes it possible to move in short cycles, correct course quickly and secure the investment at every stage. Depending on the organization's context and constraints, this PDCA logic works just as well with Agile methods (Scrum, SAFe) as with more structured frameworks such as ITIL or HERMES (the Swiss project management method).
Case study
Rescuing a project
that was poorly scoped.
Context: a consumer mobile app, aimed at individual users, in the services sector. An investment committed without any prior needs analysis.
Diagnosis when the project was taken over
- Unanticipated security risks
- Regulatory non-compliance (GDPR, data protection)
- Budget significantly overrun
- App not operational, recurring bugs
- No SEO presence whatsoever
Actions taken
Called in urgently, I picked up the file starting from the diagnosis:
- Full technical audit: code review, database review, functional testing across multiple devices
- Redefining the app's purpose and its target audience
- Building a complete strategy to secure the ROI
Results
Decision: immediate shutdown of the app to limit losses.
A security incident was avoided.
Groundwork laid to restart on solid foundations, with a project genuinely aligned with the need and the legal constraints.
An intention has never been enough to secure an investment. That is exactly what business analysis guarantees.
Background
A Business Analyst expertise
built in the field.
A developer at heart
Code comes first. I know what a developer can deliver — and what they can't guess on the client's behalf.
Analyst-developer
Client needs analysis in direct contact with the technical team: already the bridge between the request and its feasibility.
Experience within a large international group
Five years within an international industrial group exposed me to complex projects, security and compliance challenges, and coordination across multiple teams and countries.
Engineering training, as a complement
An engineering qualification, pursued to be able to lead larger-scale projects through to completion, drawing on recognized business analysis frameworks (BABOK, IIBA).
Methodology & certifications
I work according to the PDCA methodology and Agile methods, drawing on recognized frameworks: SAFe (scaled agility), ITIL (IT service management), HERMES (the Swiss project management method), DevOps, and PMI (Project Management Institute).
Today, Business Analyst
Understanding the business, its constraints and its users before even touching the technology. And, when needed, taking the technical lead so the project doesn't drift.
Areas covered
Fields and areas
covered.
I mainly support companies in the following sectors, with on-site engagements across Eastern France and Switzerland — and remotely when needed for specific points.
Sectors supported
Industry
Services
SMEs & small businesses
On-site — Eastern France & Switzerland
Mulhouse
Strasbourg
Geneva
Lausanne
You can learn more about our automation and AI agent offerings to optimize your processes once the project has been scoped.
FAQ
Frequently asked questions
about business analysis.
A developer executes what they're asked to do. If the request itself isn't right, the result won't be either — no matter how well it's coded. Business analysis exists to make sure the request itself is the right one.
A requirements document describes what is wanted. Business analysis first questions the relevance of that request, and how it fits with security, maintenance and legal requirements. It then produces the requirements document or functional specifications that follow from that.
The cost of poor scoping scales with the project, not with its size. The earlier the analysis happens, the cheaper it is to fix. On a small project, a few days of analysis can save weeks of rework.
Both. The case study above is a rescue engagement: diagnosing an existing project, followed by a full restructuring. I work just as much on projects that are still just an idea as on applications already in production that aren't delivering on their promise.
Both setups happen. I can work in support of a business/technical project manager (MOA/MOE), or directly with the business owner when there's no project structure in place. In that case, I also take on oversight of the development team if needed.
Discuss
your project.
Do you have a project in mind, an existing product that isn't delivering, or need a full audit before getting started? Let's discuss your project and how business analysis can secure your investment.