Time-to-Value Is Not Your Date

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

I write an estimate the way I have settled on writing them. Two sprints is the floor for anything real: one to build the thing, one to test it and get it out. Six sprints is the practical unit: build and test, then expand and integrate, then publish and train. Then one more line at the bottom, a fifth of the whole timeline, added back and labeled as contingency.

Writing that last line takes a second or two. It is the smallest motion in the document and the only part of the document that is honest about the rest of it.

Every line above it is a guess. Not a lazy one — a guess, made before anyone has profiled a source system, before two departments have argued about what counts as a customer, before anyone has seen what the defaults do to the requirements. The line at the bottom is the one place where that is admitted, and it is admitted in the only form a plan can carry: days, booked in advance, visible.

Then the estimate goes into a deck. A deck carries a date. It has nowhere to put a fifth of a timeline that has not been spent yet, so what leaves the room is a number that survived the presentation. The room where that number fails is not the room it was presented in. It is the finance close, a quarter or two later, and by then the date is what the organization believes about a program it has not started.

Here is the claim I will defend. A vendor's published implementation timeline is an honest number about the part of the work that is the same in every organization, and your date is made of the rest. An estimate worth defending is coarse on purpose, carries its contingency in the open and re-derives it when the definition moves, and puts the first quarter-close date on the plan beside the go-live.

Two numbers, and the decision the date is for

Somebody is going to ask when it will be done, and they are entitled to an answer. On the day they ask there are exactly two numbers available to build one out of. The first is a timeline the vendor has published, in a table, with figures attached. The second is a guess. Everything that follows is about getting from those two to a date that could be read back at a quarterly review nine months later without anybody in the room needing to explain it away.

Before building it, one question deserves an answer, and Martin Fowler asks it better than anyone: "estimation is valuable when it helps you make a significant decision," so "whenever you're thinking of asking for an estimate, you should always clarify what decision that estimate is informing" — and if there is none, or it is not very significant, "that's a signal that an estimate is wasteful" [11]. I take that seriously, because it is right, and because on a master data program it changes what the date has to contain. The decisions riding on the first estimate are whether to fund a phase, how to staff it, and what to promise the teams downstream of the master record. The last of those is the one a bare go-live date gets wrong. A sponsor deciding what to promise finance needs to know when the first correction will arrive, not only when the build will end, and a date that answers only the second question informs the decision it was asked for about half as well as it appears to.

What the published table actually measures

The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on this category being bought at all. On this subject there is no reading against our interest: crediting the platform sells the platform, and a longer estimate sells implementation days. Weigh the criticisms below above the praise.

Start with something checkable. Profisee publishes its implementation timelines, in a table, with figures attached, which is more than most of this category does. There are three service paths: a pre-configured, fixed-scope, single-domain path at roughly four to six weeks; a full-featured single-domain build at roughly twelve weeks, extending to two domains; and a multi-domain deployment at roughly three to six months depending on complexity [1]. The pricing page adds two claims in its own words — that a customer can "add value in weeks, not months," and that SaaS installation is "Profisee-managed, available in minutes" [2].

Read that table as an implementer rather than as a buyer and it says something the marketing around it does not. What is fast is the part that is the same in every organization. Installation. Infrastructure. The standard path for getting records in and getting them mastered. That work has been automated and standardized down to close to nothing, and the credit belongs where it is due: this is real engineering, done well, and the numbers attached to it are honest numbers about it.

Now read the fixed-scope path against what the vendor itself says that path is: fixed scope, domain-specific templates, and customer involvement labeled "Light-touch" [1]. Light-touch is the tell, and it is a specification rather than a criticism. That path is fast because the customer is not required to decide very much. Every hour it saves is an hour in which nobody argued about which system owns a customer record, which of two addresses survives into the master, or whether a subsidiary counts as a separate entity when a credit limit is being set.

Those arguments are the implementation. The fixed-scope path has not removed them. It has moved them later, into a phase with no figure published against it.

That last claim — that compressing the standard part leaves the bespoke part exactly as large as it was, so the proportion moves and the total does not — is not in the vendor's documentation or in any source I cite. It is mine. On the implementations I have run, the first pass and the proof of concept came quickly, and the configuration and the testing did not.

Where the cost of being nearly right lands, and on whose calendar

Matching and survivorship are probabilistic. You configure the rules, you look at what they did, you tune them, and at some point somebody with the authority to say so decides the results are good enough to publish. There is no version of this work in which that decision does not get made, and there is no threshold a vendor can ship that makes it for you.

What "good enough" conceals is the direction of the error, and the two directions are not symmetrical.

A missed match leaves two records where one belongs. It is visible, it is irritating, and it is comparatively cheap: a steward merges them and the master record is right.

An overmatch fuses two genuinely different customers into one golden record, and by the time anybody notices, that record has been consumed. The warehouse has loaded it. The campaign list has used it. An allocation has been made on it. Unpicking a merge is not the inverse of making one. Restoring the master record can be quick; the warehouse, the reports and the decisions built on them have already acted on the merged record, and none of them has an undo.

The timing is what makes this a pattern rather than a grumble, and the timing is the part that never reaches a plan. On the implementations I have run, the bill does not arrive at go-live, when everyone is still watching. It arrives at the first quarterly reconciliation, when somebody in finance has to justify the overmatches and the over-allocations that followed them. The fixed-scope row of the vendor's table stops at week six; a full-featured build goes live around week twelve; the correction lands at quarter close. Only the first two of those dates are usually in the deck.

I draw one inference from that, and it is only an inference: put the quarter-close date on the plan, beside the go-live date. Not as a milestone with a deliverable underneath it — as a marker, with a name beside it, so that the person who is going to be asked to explain the numbers knows in advance that they are the one who will be asked.

Which reframes the question a plan is built to answer. Not when do we see value, but when does the first correction arrive, and whose calendar is it on. That is also the answer to Fowler's question: it is the decision the date is for.

Where AI lands on this timeline

One assumption underneath most current time-to-value claims is worth naming now rather than next year, because next year it will be the version of this argument that arrives pre-assembled.

AI assistance in this category is real and it is concentrated in authoring. Profisee's integration documentation describes the platform generating and mapping new master data attributes automatically, with the suggestions presented so that a user can "easily modify any suggested fields and re-run if needed" [3]. The human confirmation step is in the vendor's own description of the feature, which is the correct design and is worth crediting as such. The same layer is codeless, built on open standards including webhooks and REST application programming interfaces, ships pre-built connectors, and is complemented by native Azure Data Factory pipeline templates for moving data in and out [3].

The in-product assistant, in my experience, carries the limitation every AI tool carries: very good when what it produces fits out of the box, and usually in need of some massaging before it meets the exact business requirement.

Now place all of that on the timeline. Attribute creation, attribute mapping, connector scaffolding, integration plumbing: every one of them lives in the standard, every-customer segment. The already-fast part gets faster.

What none of it accelerates is adjudication, and adjudication is the slow part. Deciding whether two records are the same customer — when the tax identifiers differ, one of the two is a subsidiary, and the billing addresses agree — is not an authoring task. It is a business decision with a downstream owner and a consequence at quarter close, and a model's confidence score is an input to that decision rather than a substitute for it. The vendor's own golden-record page puts it in the same place: an "ML-powered matching engine" proposes the matches, they are displayed "side-by-side in a match group for data stewards to review," and it is the stewards who choose "winners" to "survive the merge and be stored in the golden record" [12].

The net effect is uncomfortable and looks unavoidable: AI widens the gap between how fast a demonstration runs and how long a production implementation takes. Which makes a time-to-value claim more misleading now than it was three years ago, not less.

One operating detail sharpens that, and it cuts the opposite way to how it first reads. Microsoft documents a Profisee connector for Copilot Studio, Logic Apps, Power Apps and Power Automate, published as a preview, exposing entity and attribute creation, record create, update and delete, metadata retrieval and data-quality issue retrieval, with a documented throttling limit of 100 API calls per connection per 60 seconds [4]. That is six thousand calls an hour, which is nowhere near a constraint on adjudication: no steward decides anything like six thousand merges in an hour, or in a week.

Which is the useful part of the number. If a documented rate limit is the first ceiling your architecture meets, something in that architecture is deciding at machine rate what I have just called a business decision with an owner. The throttle is a design parameter, not a complaint. It is a tripwire, and what it trips on is a design that took the human out.

So the estimating consequence stays narrow, deliberately. If a tool halves the authoring work in a plan, the plan gets shorter by half of the segment that was already the short one. Model that before promising it. And if somebody demonstrates a capability that adjudicates survivorship with no human in the loop — not suggests, not scores, decides — then I am wrong about this and the whole timeline argument moves. I have not found such a demonstration, and the vendor whose documentation I cite does not claim one [3].

Incremental, but not in the sense the word usually carries

The plainest objection to a twelve-week unit is that the field has already voted against it. A data-management consultancy states, flatly, that "90+% of successful data governance programs are implemented incrementally – and not with a 'big bang' approach" [7]. The figure is published with no sample and no method, so I do not treat it as measured, but it does not need to be dismissed on that ground, because on inspection it is not in disagreement. Six two-week sprints, each reviewed with the stewards who will operate the result, is incremental. What it is not is a sequence of production releases. An increment of build and an increment of release are different objects, and the word "incrementally" covers both, which is how a claim about the second gets read as a refutation of the first.

The empirical software literature makes a harder version of the objection. A piece in The Register that went looking for the evidence behind the industry's favorite cost curve found that the "IBM Systems Sciences Institute" figure traced to course notes from what Laurent Bossavit identified as "an internal training program for employees," with data "not more recent than 1981, and probably older"; it reports a 2016 study of 171 software projects in which "the times to resolve issues at different times were usually not significantly different"; and it quotes Hillel Wayne on what the literature does support: "shorter iteration cycles and feedback loops lead to higher quality software than long lead times" [6]. So the famous figure has no traceable source, and Wayne himself reads the wider research on late-stage bug costs as only tentatively pointing that way; what he says it does show, beyond the value of code review, argues against long units. That is a direct argument from evidence against a twelve-week unit, and pointing at master data's peculiarities does not answer it.

What answers it is that two loops share a name. Shorten the loop inside the build: iterate the match rules daily, review survivorship with stewards weekly, keep the feedback tight and constant. That is what the evidence in [6] supports, and I have no argument with it. Do not shorten the path out to live operational data, because that is the exact point at which an overmatch stops being a tuning problem and becomes a quarter-close problem, with the asymmetry described above. The two loops can be set independently, and the habit of moving them together is what makes the finding look like a contradiction.

Here is the observation that would move me, stated so that somebody can go and make it: a master data implementation running weekly production releases of survivorship decisions, with a correction rate tracked across three quarters showing that it held. That would change the shape, not dent it. The place to look is the independent operator record rather than anything a partner or a vendor publishes, and the cheapest instrument a buyer has is the public review corpus for this platform — 42 self-selected reviews, 4.3 out of 5, not a survey [8]. I read those reviews in August and again in September and found nothing of that kind in them; the nearest they come is a reviewer's remark on a time-intensive initial setup, which is not a correction rate. That is a weak negative and I report it as one: a self-selected review corpus is not the instrument that would reliably surface such a case, so the observation has not been made and the search for it was cheap.

What a flat fifth cannot know

The objection that moves my rule comes from estimation theory. Construx's published account of Steve McConnell's Cone of Uncertainty holds that "estimates created at Initial Concept time can be inaccurate by a factor of 4x on the high side or 4x on the low side"; that "the only way to reduce the variability in the estimate is to reduce the variability in the project itself"; and that "meaningful commitments are not possible in the early, wide part of the Cone," becoming "possible and appropriate" about thirty percent of the way in, where a project that mixes up-front definition with iterative delivery is down to about plus or minus twenty-five percent [9]. The page sells an estimation course, which I note by the same standard I apply to the vendor.

Held against a flat fifth written down in week one, that account does real damage. My contingency is a constant standing in for something the Cone says is a function of how much has been pinned down, and it is smaller than the range I am actually in on the day I write it. So I keep the part that survives: book the allowance up front, because a number has to go somewhere and the alternative is a plan that silently contains none, then re-derive it at the two points where the definition genuinely moves — when the domain's attributes and survivorship rules are settled, and when the source systems have been profiled rather than described. Carrying the flat figure through unchanged did not survive the source.

The rule still rules something out, and that is what keeps it from being a retreat: carrying the week-one figure into month four unchanged, as though the intervening work had produced no information about the estate. If the allowance at the second re-derivation is the same number as the allowance in week one, either the profiling was not done or its results were not read. Fowler, arguing from a different direction and with no stake in this, reaches the same place with a project manager's line about plans and estimates: "good for a couple of days, rather wilty after a week, and unrecognizable after a couple of months" [11].

The most radical objection refuses the exercise altogether. Ron Jeffries, stating the #NoEstimates position sympathetically and then naming its unresolved problems, writes that "Estimation is difficult, perhaps impossible, and we would be well off if we could avoid it"; describes Lean and Kanban approaches that "measure how long things take, in 'cycle time', and use that to make such predictions as are necessary"; and observes that "Estimates are often used as a bludgeon to try to get programmers to work faster" [10]. On that account the whole apparatus — the table, the units, the allowance — is an elaborate way of producing a number whose main function is leverage over the people who have to hit it.

It is right about software delivery more often than the industry admits, and it is unavailable here for a specific reason. The unit of work in this category is an adjudication whose owner sits outside the delivery team, and cycle time measures the delivery team. You cannot forecast from the throughput of a queue whose service time is set by how long two departments take to agree what a customer is, and no amount of measuring the team's own flow reaches that. What I take whole from the position is the misuse point [10]: a number given once as a range and then repeated as its midpoint has stopped being an estimate by about the fourth repetition, and no improvement in estimating can correct it, because the defect is in the repeating rather than in the number.

The argument from the sources ends here; what follows is my own operating experience, offered as pattern rather than law, and it carries a different kind of warrant.

The estimate I actually give

Asked for an honest date on a Profisee implementation, I answered with the frame I use rather than a number. Two abbreviations in it are estimating slang: a SWAG is a scientific wild-ass guess, and a ROM is a rough order of magnitude.

Honest date? I'll give it to them the day after that date arrives—and still be wrong. Everything is a guess and happy path numbers are just marketing figures. Great in the PowerPoint, terrible in the Accounting Department. As the industry has moved to an Agile cadence, I've taken to doing minimal two sprint estimates: one to implement, one to QA and deploy. A more practical timeline is a full PI: first two sprints are the build and test, next two are expand and integrate, final two are publish and train. Naturally, this expands and contracts on the volume of work, but for SWAGs and ROMs, it's a starting point.

Take the first sentence at its word: a date is a claim about work nobody has seen yet, and only its passing confirms it. The unit I reach for has a definition in the framework that renamed it. What practitioners still call a program increment — the name the framework's SAFe 5 pages use [13] — is a planning interval in the current framework: "A PI is an 8 to 12-week timebox consisting of four or five development iterations, followed by an Innovation and Planning (IP) iteration" [5]. Six two-week sprints fill that box only at its twelve-week top, and only if the sixth sprint is counted where the framework puts its innovation and planning iteration; my publish-and-train pair straddles that line. The fit is loose, and I would rather say so than borrow the framework's authority for a shape it does not quite describe.

Two things about the shape rather than the number. It is deliberately coarse, because a coarse estimate cannot pretend to a precision it does not have. And a SWAG or a ROM is a starting position, not a plan — treating one as a plan is how a directional figure becomes a commitment somebody is held to.

On top of the six sprints I book a fifth of the timeline as contingency, because something always comes up during an implementation that the plan did not contain. The vendor and my own practice both keep building tools meant to shorten these timelines, and the vendor's integration tool is a good one for basic extract-and-load work; none of them has yet removed the thing that comes up. Be clear about what that fifth is and is not. It is a planning rule applied before anything about your estate is known: it prices the unknown, it does not measure it. It is not a finding about how often implementations overrun, it is not derived from a sample, and if anyone offers you a contingency percentage with an evidentiary claim attached, ask to see the sample. I am not offering one.

Then hold my shape against the vendor's table honestly, because this is the easiest place in the piece to cheat. A planning interval is eight to twelve weeks [5]; the vendor's figure for a full-featured single-domain implementation is roughly twelve [1]. Those two agree at the top of the range and sit a month apart at the bottom, and they are not independent evidence of anything: one is a vendor's service package and the other is a practitioner's planning convention, and neither is a measured outcome. So it is not a convergence and I will not dress it as one. What the pair is worth is a planning rule: for a full-featured domain rather than a fixed-scope one, plan the twelve and not the eight, because both of the only two numbers available sit at the top of the range.

What the fast start does not buy

The fast start is real, and my answer on the vendor's time-to-value claims begins by granting it:

First pass is fast. Proof of concept is fast. Stand up from zero in a green field is fast. Sadly, none of those actually meet business needs. Profisee has done an excellent job of automating and standardizing processes for ingestion and mastering, but the devil is always in the details of the configuration and testing. They've Pareto-principled the install and the infrastructure, but that just leaves more time for the hard parts.

The clause people drop is the last one, and it is the one I would defend hardest. Compressing the standard part does not shrink the bespoke part; it hands you a calendar that is now mostly bespoke part. The proportion moved. The total did not. That is also the limit of the praise in the same answer: the install and the infrastructure really have been reduced to the easy part, and that is exactly why they no longer decide the date.

The same applies, with more force, to anything sold as a head start on the configuration itself. Asked about templates and accelerators, I said:

'Out-of-the-box' templates, consolidators or accelerators. Unless they were built specifically for companies that use SalesForce, SAP and Oracle Financials, in exactly the same way your company does, you're going to spend as much time refactoring as you would 'save' by using it. From a pure implementation perspective, plan on doing your own custom build-out because your company is functionally different from the 'standard' for which the accelerators were designed.

Which gives the test for any accelerator, template or assistant, including the AI-assisted ones above: does it remove work, or does it remove a decision? Only the second one moves a date, and almost nothing removes a decision. Notice also what my answer says about the saving: it may not be there at all, because refactoring a template built for somebody else's systems can cost what building it would have. Where the saving is real, my reading is that it belongs in the contingency or the buffer and not in the commitment, because the work it removed was never the work that was going to make you late.

Where does the remaining effort actually go? Into expressing a requirement the defaults were not built to express. In my experience configuration and setup get complicated, the way any software build tends to, once the requirements being matched sit at an angle to what the product does by default. That is not a criticism of the product and it is not a surprise; it is the segment no table can price, because the table would have to know your requirements to price it.

The residual, and who absorbs it

The residual is where fast time-to-value sends its bill, and my answer on what it costs later names who pays:

Intelligent error handling and depth of process. Like many things in the world, it's the details that matter and being 80% right out of the gate still means you're 20% wrong. Trying to force that remaining 20% into the 80% box causes late-night and weekend work for data stewards trying to unpick and un-match records that should never have been matched in the first place. All while marketing and production are operating on bad aggregates.

That bill arrives at the first quarterly reconciliation where someone needs to justify the overmatches and corresponding over allocations.

The tell is who absorbs the residual. The stewards absorb it, as evenings and weekends, and no plan carries a line for evenings and weekends. My inference, and it is an inference rather than a measurement: a cost with no line to land on is not thereby absent, it is only unbudgeted. And the second paragraph of that answer is the whole reason for the quarter-close marker. The reconciliation is where the overmatch becomes somebody's problem in public, and that somebody was not in the planning meeting.

The cost of undoing one I can state as a ladder, from a customer engagement:

Live example from a customer: * Minutes to refactor/restore the Mater Record * Hours to reload the downstream Data Warehouse * Additional Hours to regenerate the reports * Further Hours to revalidate decisions and presentations

That clock starts only when the problem has been noticed.

Mater [sic]. Read the last line first. The clock starts when the problem is noticed, not when the merge happened, and the noticing happens downstream — in a report somebody does not believe, or a reconciliation that does not balance. That lag is the whole reason the correction lands in a different quarter from the one that caused it. Notice, too, where the ladder is cheap: restoring the master record takes minutes. Every rung after it is downstream work that no plan had a line for. It is one case, abstracted, and it is not a measurement of what an un-merge costs in general.

I see the same shape in the cost model itself, twice over. The first is the emergency call nobody prices. A support contract covers business hours, and what business hours do not cover is the Sunday night that runs into Monday morning because a weekend bulk load failed, after an upstream system changed its data profile and announced it on no channel anybody was monitoring, and somebody has to come in and change code. The second is scope creep with requirement drift: as the business grows fluent in what the product can do, it asks sharper questions and wants more varied features, which changes the economics and produces change orders no total-cost calculation included. That is a timeline finding as much as a cost one. The plan lengthens because the project is working.

Compression that is really deferral

One way to shorten the date is to take the time out of testing. Asked about offering early value to keep a program funded, I put the risk this way:

Properly scoped, the attempt to provide 'early value' is a production deployment, but it's very risky to try to do that early in a project. Chopping off QA and UAT can get you out the door faster, but it just means you're doing testing in Production—great timeline compression on the Happy Path and when someone finds that path, that'll be the first time.

Note where the compression went. Cutting the test-and-release phase does not remove the testing; it relocates it into production, where the happy path holds right up until the first person leaves it. That is the same move as banking the fixed-scope path's saving one phase earlier, and it produces the same calendar with a worse audience.

My unit names its own thirds out loud — build and test; expand and integrate; publish and train — and the naming does work, on my reading of it: publish-and-train is the only third with no engineering artifact to point at. Nothing compiles, nothing deploys, and the deliverable is that people know how to operate the thing. A named third that disappears is something somebody has to approve out loud. An unnamed one simply does not happen, and the program finds out two quarters later that it built a platform nobody was taught to use.

There is a reason that third is the one at risk, and it is about where the value sits in the curve. In the same answer I went on:

MDM projects are the epitome of Pareto—huge initial value with a long tail, so it's tempting to try to sell it based upon initial perceived value. However, the longer the project, the larger the Enterprise or the more complicated the data, the longer the tail gets. Therefore justifying the effort toward the middle and end of the project gets progressively more difficult—which is why I like to make sure I can sprinkle candy throughout the entirety of the implementation.

Which is the sponsorship problem and the estimating problem in one paragraph. The value curve front-loads and the work does not, so the further in you are, the harder the remaining effort is to justify from the evidence of what has already been delivered. A plan that spent every visible win in the first six weeks has nothing left to spend in month five, and month five is where publish-and-train lives. On that reading the candy is not decoration: it works as contingency for sponsorship, and it has to be scheduled the way the fifth is.

One last thing moves the number more than anything in the vendor's table does, and it is the starting condition. The start I would choose is to review, classify and compartmentalize the customer-related information across the systems in scope before anything is built, laying the schema metadata side by side so the redundancies and the genuine single sources of truth are visible. The worst start is a single "unified" table fed by every source and handed over by a previous team with no documentation beyond the code — which is now an operational system to monitor, maintain and bug-fix alongside the new build, and where the first request will be a straight lift-and-shift that preserves logic nobody ever wrote down. No published timeline prices that difference, and no estimate written in week one can either, because in week one nobody has looked hard enough to know which of the two they have.

Week one to quarter close

Week one. The estimate is written. Six sprints, a fifth held back, before a source system has been profiled or a survivorship rule agreed.

Week two. The SaaS instance stands up. The vendor said minutes, and about minutes the vendor is right [2].

Weeks three to six. Records in, records mastered, along the path that has been engineered down to nearly nothing. This is the segment the published figures measure, and it behaves the way the table says it does [1].

Week seven. The first survivorship argument with no technical answer. Two addresses, a subsidiary, a credit limit, and two departments each holding a correct answer from where they sit. The service time of that queue is now set outside the delivery team, which is where forecasting from the team's own flow stops working.

Week nine. The rules are tuned, reviewed and good enough to publish. That decision cannot be shipped by a vendor, and it gets made by somebody who has the rest of their week to get on with.

Week twelve. Go-live, near enough to the figure that nobody re-reads the figure.

Quarter close. Finance reconciles. The overmatches surface as over-allocations, the un-merge clock starts, and the calendar it starts on belongs to a function that was not in the planning meeting — unless the plan put that date beside the go-live and a name beside the date.

Then the next estimate. Phase two, the next domain, the same document.

And this time the attributes are settled, the survivorship rules are written down, and the source systems have been profiled rather than described.

Which are the two points at which the allowance was supposed to be re-derived.

So the line gets written again.

The motion is the same. The number under it is not.

References

[1] Profisee, "Professional Services" — vendor documentation for the FastStart implementation service. Cited for the published three-path table: Express at approximately four to six weeks ("Fixed-scope, domain-specific templates", customer involvement "Light-touch", single-domain analytical solutions); Accelerate at approximately twelve weeks ("Customized for single domain, with full feature set", up to two domains); and TurnKey at approximately three to six months ("based on complexity", multi-domain). Page modified February 13, 2026; read August 21, 2026; re-verified September 26, 2026. https://profisee.com/solutions/professional-services/

[2] Profisee, "Pricing" — vendor documentation of the commercial and deployment model. Cited for two stated claims quoted in the text: that a customer can "add value in weeks, not months," and that SaaS installation is "Profisee-managed, available in minutes". Analyst placements and comparative value claims on the same page are not cited. Page modified June 25, 2025; read August 21, 2026; re-verified September 26, 2026. https://profisee.com/pricing/

[3] Profisee, "Integration | Profisee Platform" — vendor product documentation. Cited for what the integration layer is: a codeless approach built on open standards including webhooks and REST application programming interfaces, with pre-built connectors, and with native Azure Data Factory pipeline templates for moving data in and out of the platform; and for the AI-assisted attribute feature as the vendor describes it — automatic generation and mapping of new master data attributes, with the suggested fields presented so a user can "easily modify any suggested fields and re-run if needed" (the page capitalizes the first word). Read August 21, 2026; re-verified September 26, 2026. https://profisee.com/platform/integration/

[4] Microsoft, "Profisee (Preview)," Microsoft Learn connector reference, page dated March 1, 2024 — documentation for the Profisee Power Platform connector, published as a preview, available in Copilot Studio, Logic Apps, Power Apps and Power Automate. Cited for the documented operation set (create entity and attribute; create, update and delete records; get metadata; get data quality issues) and for the documented throttling limit of 100 API calls per connection per 60 seconds. Read August 21, 2026; re-verified September 26, 2026. https://learn.microsoft.com/en-us/connectors/profisee/

[5] Scaled Agile, Inc., "Planning Interval (PI)," SAFe framework reference — "A PI is an 8 to 12-week timebox consisting of four or five development iterations, followed by an Innovation and Planning (IP) iteration." Cited for the timebox definition and for the current name of the timebox, Planning Interval (the page does not itself mention the earlier name; see [13]). Page last updated February 25, 2025; read August 21, 2026; re-verified September 26, 2026. https://framework.scaledagile.com/planning-interval

[6] Tim Anderson, "Everyone cites that 'bugs are 100x more expensive to fix in production' research, but the study might not even exist," The Register, July 22, 2021 — reporting the work of two named investigators. Laurent Bossavit traced the "IBM Systems Sciences Institute" chart to course notes cited in Roger S. Pressman's Software Engineering: A Practitioner's Approach, found the Institute was "an internal training program for employees," and concluded that "the original project data, if any exist, are not more recent than 1981, and probably older" (the source continues that they could be as old as 1967). The piece also reports a 2016 study of 171 software projects finding that "the times to resolve issues at different times were usually not significantly different," and quotes Hillel Wayne that "shorter iteration cycles and feedback loops lead to higher quality software than long lead times." Cited for the finding adverse to this article's planning shape. Read August 21, 2026; re-verified September 26, 2026. https://www.theregister.com/2021/07/22/bugs_expense_bs/

[7] Anne Marie Smith, Ph.D., "Gaining Executive Support for Data Governance," EWSolutions, published October 21, 2021, last updated April 6, 2026 — cited for one claim only: "90+% of successful data governance programs are implemented incrementally – and not with a 'big bang' approach," which is published without a sample or method (the source sets "big bang" in double quotation marks). Read August 21, 2026; re-verified September 26, 2026. https://www.ewsolutions.com/gaining-executive-support-for-data-governance/

[8] G2, "Profisee Reviews" — the public corpus of verified-user reviews of the platform: 42 reviews, 4.3 out of 5 average. Self-selected reviews, not a survey; aggregate and review bodies read August 21, 2026 and re-read September 26, 2026, the nearest remark found being a reviewer on the time-intensive initial setup. https://www.g2.com/products/profisee/reviews

[9] Construx Software, "The Cone of Uncertainty" — the firm's published account of Steve McConnell's estimation model. Cited for: estimates at Initial Concept "can be inaccurate by a factor of 4x on the high side or 4x on the low side"; "the only way to reduce the variability in the estimate is to reduce the variability in the project itself"; "meaningful commitments are not possible in the early, wide part of the Cone," with commitments "possible and appropriate" about thirty percent of the way in; and variability of about ±25% for a project that combines up-front requirements work with iterative implementation. The page sells an estimation course. Published September 17, 2016, modified November 24, 2020; read August 23, 2026; re-verified September 26, 2026. https://www.construx.com/books/the-cone-of-uncertainty/

[10] Ron Jeffries, "The #NoEstimates Movement," ronjeffries.com (undated) — a sympathetic statement of the position that refuses the exercise this article performs, by an author who supports it and then names its open problems. Cited for: "Estimation is difficult, perhaps impossible, and we would be well off if we could avoid it"; Lean and Kanban approaches that "measure how long things take, in 'cycle time', and use that to make such predictions as are necessary"; and "Estimates are often used as a bludgeon to try to get programmers to work faster." Read August 23, 2026; re-verified September 26, 2026. https://ronjeffries.com/xprog/articles/the-noestimates-movement/

[11] Martin Fowler, "Purpose Of Estimation," martinfowler.com, February 27, 2013. Cited for "estimation is valuable when it helps you make a significant decision"; "whenever you're thinking of asking for an estimate, you should always clarify what decision that estimate is informing"; "that's a signal that an estimate is wasteful" (when no significant decision can be found); and a project manager's line, as Fowler recalls it, that plans and estimates are "good for a couple of days, rather wilty after a week, and unrecognizable after a couple of months." Read September 26, 2026. https://martinfowler.com/bliki/PurposeOfEstimation.html

[12] Profisee, "Golden Record Management" — vendor product documentation. Cited for "an ML-powered matching engine"; matches "displayed side-by-side in a match group for data stewards to review"; and stewards choosing "winners" to "survive the merge and be stored in the golden record." The page does not describe reversing a merge. Read September 26, 2026. https://profisee.com/platform/golden-record-management/

[13] Scaled Agile, Inc., "Program Increment," SAFe 5 framework archive (v5.scaledagileframework.com), last update September 6, 2022 — "A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems." Cited only for the earlier name of the timebox that the current framework page [5] calls a Planning Interval; read with [5], the pair shows the rename. Read September 26, 2026. https://v5.scaledagileframework.com/program-increment/