A programme manager at a mid-sized insurer has been given a task that fitted on one slide of the board deck: “new agent self-service portal, go-live in nine months”. The budget is approved, procurement keeps asking when the RFP will go out, and she has three things: notes from two workshops with the sales department, a spreadsheet of requirements written by IT, and a wish list from claims. The three documents do not agree. Nobody knows how many systems the portal has to integrate with, who owns agent data, or which requirements come from regulation and which from habit.
Sending that material to five software houses will produce five proposals that cannot be compared. Each vendor will fill the gaps differently: one prices the minimum, another prices everything with a buffer, and a third writes “to be clarified during analysis” and keeps a door open for change requests. The programme manager knows she needs something between the notes and the contract. That something is a pre-implementation analysis.
This article is for the person who has to commission one or convince the board it is worth paying for. We describe what should be produced, how the work runs, how long it takes, what drives the cost, who should do it, and what to put in the contract so the results belong to you rather than to the vendor. We have covered the difference between business and systems analysis and how to build a requirements specification in separate articles, so here we focus on the buying side: what you are purchasing and at what price.
What is a pre-implementation analysis, and how does it differ from a discovery workshop?
A pre-implementation analysis is a bounded stage before a system is built or rolled out, in which a team of analysts turns business goals and scattered expectations into a description that can be reliably priced, designed and built. It combines two perspectives. Business analysis answers why the system is being built, which processes it supports and how success will be measured. Systems analysis answers what exactly the system must do, which systems it connects to, what data it handles and which quality attributes it must have. We explain the split in more detail in business analysis vs systems analysis.
A discovery workshop is something different, although the terms get mixed up. Workshops are usually a few intensive sessions that settle the product goal, users, first-release scope and priorities. They are an excellent start, but their output is typically an agreed vision, a story map and a risk list, not documentation an RFP can rest on. We described how to run them well in our article on IT discovery workshops. In practice, workshops are often the first week of a pre-implementation analysis rather than a substitute for it.
A third notion is the fit-gap analysis used when implementing packaged software such as ERP or CRM. There the analysis compares the company’s processes with what the product can do and describes the gaps to be closed by configuration or development. The buying logic is similar, but the output differs: instead of a build specification you get a fit assessment. This article focuses on custom-built systems and notes differences for packaged software where they matter.
Why pay for analysis before you choose a vendor?
Because requirement errors are most expensive when they surface late, and without analysis they always surface late. The most frequently cited data comes from PMI’s 2014 “Pulse of the Profession: Requirements Management” report, based on a survey of more than 2,000 project practitioners and business analysts. It found that 47% of unsuccessful projects failed to meet their goals because of inaccurate requirements management, and that 5.1% of every dollar spent on projects and programmes is wasted due to poor requirements management (PMI, 2014). It is a survey, not an experiment, and it is a few years old, but the direction matches the experience of anyone who has run a project with a vague scope.
For a buyer the argument is even more practical. Without analysis you cannot compare proposals. Each vendor fills the gaps in your requirements with its own assumptions, so price differences between proposals usually reflect different assumptions rather than different efficiency. You end up choosing not the best vendor but the one that assumed the least.
Without analysis you cannot write a sound contract either. A fixed-price contract without a scope description ends in disputes over what was in scope, and a time-and-materials contract without one ends in a budget that grows unchecked. Analysis does not remove uncertainty, but it names it: what is known, what is an assumption and what still needs a decision.
Finally, analysis surfaces problems nobody wanted to see. Two departments have conflicting requirements for the same process. The source system you must integrate with has no API. Customer data lives in three places and differs in each. It is far better to learn this for a few thousand euros during analysis than for tens of thousands halfway through the build.
What should you receive at the end of the analysis?
This is the most important part of the order. An analysis without clearly defined deliverables turns into a series of meetings that leave the feeling that “we covered a lot”. Before you sign, make sure the proposal names specific documents. A typical set has eight elements.
Business context and goals. A short document stating why the system exists, who uses it, how success is measured and what is out of scope. It looks obvious, but it is what settles disputes during the project.
Process model. The processes the system supports, current and target state, usually in BPMN or a simpler form if the processes are straightforward. This is where conflicts between departments surface.
Functional requirements. What the system must do, written as use cases, user stories with acceptance criteria, or both. The key test is that every requirement can be verified. Our glossary entry on requirements analysis covers the technique.
Non-functional requirements. Performance, availability, security, regulatory compliance, digital accessibility, hosting and support expectations. Often skipped, yet they drive the architecture and a large part of the cost. See also non-functional requirements in our glossary.
Integration and data map. Which systems the new one connects to, which direction data flows, what the interfaces are and who owns them on the other side. Plus a conceptual data model and a decision on which system is the source of truth for which data.
Outline architecture. Not a detailed technical design down to the last class, but the main decisions: components, technologies or constraints on them, deployment approach and key technical risks. Without it vendors will propose five different architectures and you will be comparing apples with pears.
Prioritised backlog. Features ordered by value and dependency, with the first-release scope clearly marked, often as an MVP.
Estimate and risk register. An effort estimate expressed as a range rather than a single number, with its assumptions and the risks that could move it.
If the analysis is to underpin a tender or RFP, these documents usually come together as a requirements specification. Our guide to the software requirements specification (SRS) explains how to make one useful for vendors and testers. The reference point for its structure is ISO/IEC/IEEE 29148:2018, the international standard for requirements engineering processes and the content of requirements documents.
How do you check the quality of the documents at sign-off?
Sign-off is where weak work most easily slips through, because the documents are long and the deadline is close. Rather than reading everything cover to cover, run five simple tests.
The tester test. Pick ten functional requirements at random and ask someone from QA whether they can write a test case for each. A requirement such as “the system should be intuitive” or “the report shows the relevant data” fails this test and will come back as a dispute at build acceptance.
The new-vendor test. Give the documents to someone who did not attend the workshops, such as an architect from another team, and ask for their questions after an hour of reading. If there are dozens of questions about the basics, the documents describe conversations, not a system.
The conflict test. Check that every conflict raised during the analysis has a decision and a named decision maker next to it. A conflict marked “closed” without a sponsor’s decision will reopen during the build.
The integration test. Each integration should name the owner of the system on the other side, the direction of data flow and whether the interface exists or must be built. Missing any of the three is a gap in the estimate.
The assumptions test. The estimate should list its assumptions. Ask what happens to the range if the two most important assumptions turn out to be false. If the analyst cannot answer, the estimate is a number, not an analysis.
None of these tests requires technical knowledge from the programme manager, and together they take one afternoon. It is worth writing them into the acceptance procedure in the contract.
How does the analysis run week by week?
The flow depends on system size, but a good mid-sized analysis has a recognisable rhythm. Here is an example for a four-week analysis of a system serving several departments.
Week 1: goals, stakeholders, materials. A kick-off with the board or sponsor to agree the goal and scope boundaries. A review of existing documents: notes, procedures, descriptions of current systems, contracts with their suppliers. A stakeholder map and workshop schedule. If discovery workshops are planned, they happen this week.
Week 2: processes and requirements. Workshops with departments, usually two or three sessions per key area. Process model, first version of functional requirements, a list of conflicts for the sponsor to resolve. In parallel, the architect talks to IT about existing systems and constraints.
Week 3: integrations, data, non-functional requirements. Conversations with the owners of the systems to be integrated. Integration map, data model, non-functional requirements. Outline architecture and technical risk list. A second version of functional requirements once conflicts are resolved.
Week 4: priorities, estimate, sign-off. Prioritised backlog with first-release scope, an estimate as a range with assumptions, risk register. Document review with stakeholders, corrections, a presentation of results to the sponsor and formal acceptance.
Note that the analysts are not writing in isolation. Most of the work is conversation, and the critical resource is the time of people on your side. If sales can only make time for workshops in three weeks, the analysis takes three weeks longer, however many analysts you hire.
How long does a pre-implementation analysis take?
There is no single answer, but the factors can be named and assessed before the start. As a rough guide: a simple system with one main process, one department and a few integrations usually takes about two weeks. A system serving several departments with several integrations is more like four to six weeks. Large programmes that replace several systems, carry regulatory requirements or span several countries need two to three months, often split into phases. These are estimates based on a typical work structure, not market data.
For comparison, in ARDURA Consulting’s custom software development projects we start with a discovery phase of one to two weeks to define scope and architecture. That shorter form is enough when we build the system ourselves and turn the findings straight into team work. A full analysis for an RFP sent to several vendors needs more documentation, because its readers did not take part in the conversations.
Four things stretch the timeline most. First, stakeholder availability: the calendars of directors and subject-matter experts are usually the bottleneck. Second, unresolved conflicts: if two departments want different things and the sponsor does not decide, the analysis stalls. Third, undocumented systems: integrating with a system nobody has described means reconstructing knowledge from code or from conversations with its supplier. Fourth, a goal that shifts mid-way: if the board changes scope in week three, part of the work has to be redone.
What shortens it: a single sponsor with decision rights, workshop slots booked in advance, materials handed over before the start, and agreement that some details will be settled during the build, with the analysis only identifying which ones.
How much does a pre-implementation analysis cost, and what drives the price?
The cost is person-days multiplied by the rates of the roles involved. There is no credible public market price list for analyses that could honestly be quoted, so we show the arithmetic with explicit assumptions.
A typical team is a business/systems analyst for the full duration, an architect part of the time, a second analyst or UX designer on larger systems, and sometimes a project manager. For illustration, assume day rates of EUR 350–650. That range is close to senior and architect levels on ARDURA Consulting’s pricing page, where a senior project manager is EUR 355–485 and a backend architect or lead EUR 485–650 per day. The analyst role has no separate line on the price list and is quoted individually. Rates in Western Europe are typically higher.
- Simple system, about 2 weeks: analyst 10 days and architect 3 days, about 13 person-days, roughly EUR 4,500–8,500.
- Mid-sized system, about 4 weeks: analyst 20 days, architect 8 days, UX designer 8 days, about 36 person-days, roughly EUR 12,500–23,500.
- Large programme, 6–10 weeks: two analysts, an architect, UX and a project manager, about 80–120 person-days, roughly EUR 28,000–78,000.
Also check what the proposal leaves out. A clickable interface prototype, user research, a legal opinion on sector regulation or a technical proof of concept for a risky integration are usually separate items. Each may be worth its price, but it should be priced separately so it does not blur the scope of the analysis and so you can decide consciously whether you need it.
The spread is wide because several factors act at once. The table below sets them out. If you first want a sense of what the build itself might cost, our MVP cost calculator gives indicative ranges for typical products. A sensible analysis costs a fraction of the build; if a quote for analysis approaches the cost of building the first release, something is wrong with the scope of one or the other.
| Factor | Effect on time and cost | What you can do on your side |
|---|---|---|
| Number of departments and stakeholders | Each extra department means workshops, conflicts and alignment; cost grows faster than linearly | Appoint one sponsor with decision rights and book slots before the start |
| Number of integrations | Each integration needs talks with the system owner and an interface description | Prepare a list of systems, their owners and available API documentation |
| Regulatory requirements (GDPR, sector rules, accessibility) | Adds regulatory analysis and often a consultation with legal or the data protection officer | Name a compliance contact who can answer within a few days |
| Quality of existing documentation | No description of current processes and systems means reconstructing knowledge from interviews | Gather procedures, notes, tickets and system descriptions, whatever their state |
| Intended audience of the documents | Analysis for a tender or multi-vendor RFP needs fuller documentation than analysis for your own team | Agree at the start what the results will be used for |
| Level of detail | Describing every screen and rule costs several times more than describing features and acceptance criteria | Decide what will be refined during the build and record it in the analysis |
| Stability of the goal | Changing scope mid-analysis means redoing work | Approve the goal and scope boundaries in week one |
Who should do the analysis: your team, the future vendor or an independent firm?
Each option has a sensible use, and each has a cost that is not always visible at first.
Your own analysts. They know the company, the processes and the people, need no procurement process and stay after the project. This works if such a team exists, has the time and has experience with systems of this kind. The risk is that internal analysts are part of the company’s power structure, find it harder to arbitrate between departments, and lose time to day-to-day duties.
The future vendor. Many software houses offer analysis or a discovery phase as the first stage of a project. The advantage is continuity: the people who analysed then build, and nothing has to be explained twice. The drawback is a conflict of interest: a vendor writing the specification writes it for itself, its technology and its way of working, and you lose negotiating leverage because changing vendor after analysis feels like wasted money. The contract can rebalance this, as the next section shows.
An independent firm or external analysts. This gives the most freedom in choosing the builder, because the analysis is not written for anyone in particular. It does require a good handover to the vendor and usually a few days in which the vendor validates the analysis before bidding. It is the best option when you plan a competitive RFP or a public tender.
There is also a hybrid: an external analyst through staff augmentation, working inside your team under your direction, with results owned by you from day one. On our available experts page you will find, among others, a senior business/systems analyst with insurance, banking and finance experience, fluent in UML, BPMN and requirements engineering. This model combines independent results with a flexible resource.
How should you pay for the analysis, and what belongs in the contract?
Analysis is one of the few IT engagements that suit a fixed price well: closed scope, defined deliverables and limited time. If a vendor cannot quote an analysis as a lump sum, ask why. It usually means they do not understand the scope, or that the analysis is meant to slide into the build without a decision point. Time and materials makes sense for a very uncertain scope, but then with a cap on person-days and a weekly progress report.
Whatever the model, the contract should contain six clauses.
A list of deliverables with acceptance criteria. Documents named individually, with minimum content and an acceptance procedure. Not “analysis documentation” but “BPMN process models for processes X, Y and Z”.
Ownership of the results. A clear assignment of intellectual property in all documents, including the right to share them with other vendors and to modify them, valid under the governing law of the contract. Without it you may not be able to use the analysis lawfully in an RFP sent to the analyst’s competitors.
Delivery format. Editable source files, not only PDFs: process models in the tool’s format, the backlog exported from your work-tracking tool, diagrams in an editable format.
No obligation to continue. An explicit statement that the analysis is a separate engagement and gives the vendor no priority or exclusivity for the build. If the vendor will bid for the build, it is worth stating that its proposal will be assessed on the same terms as everyone else’s.
Client obligations. Stakeholder availability, response times, provision of materials. This protects both sides: if the analysis slips because people were unavailable, the reason is on record.
Change procedure. What happens if the analysis reveals that the scope is larger than assumed: who decides, how extra work is priced and how the deadline changes.
What does the analysis team need from your side?
Analysis is joint work, and its quality depends on the client at least as much as on the analysts. Prepare four things before the start.
A sponsor with decision rights. One person who resolves conflicts between departments and approves scope. A steering committee is good for keeping people informed, but poor at making a decision within two days.
Reserved time from subject-matter experts. Each key department should name someone who knows the process from the inside and has workshop slots blocked in their calendar. Typically two to four two-hour sessions per department across the analysis, plus short answers along the way.
Materials. Procedures, manuals, screenshots of current systems, reports people actually use, contracts with suppliers of systems to be integrated, API documentation. Even outdated material saves hours of interviews.
An IT and security contact. Someone who can state the company’s technology standards, where the system may be hosted, the security requirements and who owns the systems that need connecting.
If any of these is missing, tell the vendor before the start. A reliable vendor will extend the timeline or adjust the scope. An unreliable one will accept the order and explain the delay later.
What are the red flags in analysis proposals?
Some signals in a proposal should prompt extra questions.
No list of deliverables. The proposal describes meetings and workshops but names no documents. You are then paying for time, not results.
Analysis “included” in the build. The vendor offers analysis free or at a token price on condition that it builds the system. That is not a gift: the cost is buried in the build, and you lose the ability to compare proposals because the analysis is written for one vendor.
Architecture decided before the analysis. The proposal fixes the technology and architecture up front. Analysis should justify those decisions, not rubber-stamp them.
No non-functional requirements in scope. The proposal talks about processes and features and is silent on performance, security and support. Those requirements are what most often raise build cost, so leaving them out just moves the problem later.
A single number instead of a range. A reliable estimate at analysis stage has a range and assumptions. A single number without assumptions is either overconfidence or a number chosen to fit the budget.
Silence on ownership of the documents. If the proposal or template contract says nothing about intellectual property, ask before you sign, not after.
How do you use the analysis in the RFP and the contract?
A good analysis changes how you buy the build. Instead of asking vendors to “quote for an agent portal”, you ask them to price a specific first-release backlog with specific non-functional requirements, integrations and architecture. Proposals become comparable because vendors are pricing the same thing.
Attach the analysis documents to the RFP and ask vendors for three things: the assumptions they made beyond the analysis, the questions and risks they see, and a price broken down by backlog item or module. Differences in assumptions will show who understands the project and who priced the minimum.
In the contract, the analysis becomes the annex that describes scope. Under fixed price it is the basis for deciding what is a change and what was in scope. Under time and materials it is the reference point for tracking progress and budget. Either way, the prioritised backlog lets you agree what will be delivered if the budget runs out.
For public-sector buyers in the EU, pre-implementation analysis sits alongside a tool provided by the procurement rules: preliminary market consultations under Articles 40 and 41 of Directive 2014/24/EU, which allow a contracting authority to consult the market before launching a procurement in order to prepare it. Consultations do not replace the analysis, but they help check whether requirements are realistic and whether the market can price them, provided that equal treatment of bidders is preserved.
When is a pre-implementation analysis unnecessary, or can it be shorter?
A full analysis does not always pay off. In three situations a shorter version will do, or it can be skipped.
A small product that will change anyway. If you are building the first version of a product whose market you are still testing, a detailed specification will age faster than it can be written. A short discovery phase, an MVP scope and short iterations with a team you trust work better.
The same team analyses and builds, on time and materials. If you do not plan to compare proposals and the build team is already chosen, full documentation for an outside reader is unnecessary. A short discovery phase is enough, and the rest of the detail emerges sprint by sprint. That is how the discovery phase works in our custom software development projects.
Replacing a system with a packaged product without major process change. If you are adopting a standard product and adapting your processes to it rather than the other way round, a fit-gap analysis and a list of gaps are enough, not a full specification.
In every other case, and especially when you plan a competitive vendor selection, a fixed-price contract, a project spanning several departments or integrations with systems you do not control, pre-implementation analysis is the cheapest way to avoid overpaying for the build.
What should you remember when you commission an analysis?
A pre-implementation analysis turns scattered expectations into a description you can use to compare proposals, write a contract and build a system without constant scope disputes. Its value lies not in the page count but in naming the uncertainty: what is settled, what is an assumption and what still needs a decision.
Remember five things. First, buy deliverables, not meetings: a list of documents with acceptance criteria is the foundation of the proposal. Second, cost it as person-days times rates and compare it with the build cost; an analysis that costs as much as the first release has the wrong scope. Third, duration depends mostly on the availability of people on your side, so book their calendars before the start. Fourth, write ownership of the documents, an editable format and no obligation to continue into the contract, whoever does the analysis. Fifth, use the analysis in the RFP so that vendors price the same thing, and ask them to list their assumptions beyond it.
If you are preparing a project and want to start with a discovery phase, or you need an experienced business/systems analyst inside your team, see how we approach custom software development or book a scoping call. We will tell you how much analysis makes sense in your case and whether you need it at all.