Where the Calendar Goes

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

Asked where the calendar of an implementation actually goes against the plan, which sinks swallow the time and which one nobody planned for, I answered with one word and then two sentences:

Pareto. Standing up the environment and getting the PoC in place is usually simple and less than ten percent of the work. Fixing integration problems; making systems work together; and troubleshooting security, authentication and networking connectivity issues almost always eat up half of the remaining calendar.

That answer is the spine of this investigation, and the first thing to say about it is what it is not. It is a shape drawn from one practitioner's record, not a measurement. "Less than ten percent" and "half of the remaining calendar" are rough shares, and I will not make them any more exact here than I made them when I gave them. Nor is the word at the front a ratio. Joseph Juran, who put Pareto's name on the idea, later conceded that he had "mistakenly applied the wrong name to the principle", and the principle as he stated it carries no fixed split at all: "a relative few of the contributors account for the bulk of the effect" [1]. That is the sense I meant. A small, visible part of the work arrives first and fast. The bulk arrives later, in many pieces, none of them large enough on its own to put in a plan. Asked later where match and merge rules, survivorship and the setting up of stewardship fall, I put them in the balance, not in the stand-up, provided the delivery is properly agile: what the business needs goes into production first, by hand where it must, and is done properly afterwards. The first release is the minimum viable product, the scope that can go out of the door quickly in a form the business can use; enhancements, optimisation and automation follow as later releases. The shares are shares of the calendar, not a strict sequence: some of the balance runs alongside the integration half, as set out below.

What the answer does say is uncomfortable for anyone holding a project plan. The plan for a master data implementation is drawn almost entirely from the part of the work that takes the least time, because that is the part everybody can describe in advance: the vendor, the partner, the reference architecture and the demonstration. The rest of the calendar is spent on work that is mostly not in the product at all, and on facts about the client's own systems that nobody knew until a stricter system met them. This Deep Dive follows the calendar in that order, one stage per article, and this piece is what shows up when the four are read together.

Why the plan is drawn from the quick part

A disclosure first, because from here this piece assesses Profisee and the claims made for it. 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 master data management being bought at all. That interest runs toward praise of Profisee and of the category, so weigh anything I say in their favour below what I say against them. Profisee positions itself inside Microsoft's platform, so the same interest runs toward Microsoft; weigh my remarks about Microsoft's identity and cloud services with that in mind. One interest runs the other way. This piece argues that most of an implementation's calendar goes on work outside the product: integration, identity, networking, discovery. That is the work our deployment practice is paid to do, and Shabel Enterprises is building its own tooling for the integration side of it. We therefore have a reason to make that share sound larger than it is. Discount my account of it accordingly.

Start with what the vendor says, because on the first stage I agree with it. Profisee's own architecture page tells a buyer to "Get Profisee running in minutes whenever you're ready to start", and for its hosted offering it goes further: "Leave the networking, firewalls and storage to us so you can deploy in minutes" [2]. Its services page sets out packaged engagements by duration, from about four to six weeks up to three to six months for the tier with advanced integrations, with a single-domain tier "delivered in as little as 12 weeks", and attributes to Gartner the claim that Profisee has "more customers go live in under 90 days than any other vendor" [3]. Those figures do not contradict my shares, because a go-live date and a share of the work measure different things. In the terms of the minimum viable product above, a packaged go-live is a first release: the platform in production for a first domain, with most of the estate's integration still to come. The stand-up inside it is the quick part, and it is the stand-up, not the go-live, that my answer puts under ten percent of the work. The date ends the first release, not the job, and the later stages of this investigation run on past it. The same page is also candid about where its own scope ends: integration appears only in that top tier, as "advanced integrations", and the page says nothing either way about security or network work [3]. A vendor describes the part it can promise. The trouble starts when a plan is built from that description as though it were the whole job.

There are now three ways to get through the quick part. The on-premises installer runs on a Windows Server machine, virtual or physical. The container release is a standard Kubernetes installation; Profisee publishes the templates and scripts for it on Azure's, Amazon's and Google's managed Kubernetes services, in a public repository whose own description is "Everything you need to know about deploying Profisee Platform on AKS, EKS and GCP" [4]. And the hosted service runs in Azure, operated by Profisee [2]. The installer's requirement is from my own record rather than a public page, because the vendor's installation documentation sits behind a customer sign-in. The point of listing all three is that the choice between them changes who does the quick part. It does not change whose firewall the sources sit behind, whose directory the users sign in from, or whose review board has to approve the connection.

Why plans keep being drawn from the quick part is not a mystery, and it is not peculiar to master data. Daniel Kahneman and Amos Tversky named it in a 1977 report for the US defence research agency: "Scientists and writers, for example, are notoriously prone to underestimate the time required to complete a project", a tendency they called the "planning fallacy" [5]. Their diagnosis is the useful part. A forecaster has two kinds of information: singular information, "evidence about the particular case under consideration", and distributional information, "knowledge about the distribution of outcomes in similar situations" [5]. Forecasts go wrong when the first crowds out the second. An implementation plan is singular information from end to end. The demonstration, the quote, the reference architecture and the deployment template are all evidence about this case, and every one of them describes the quick part well.

The psychology behind it has been tested since. Roger Buehler, Dale Griffin and Michael Ross asked students to predict when they would finish a thesis; "fewer than one third of the respondents (29.7%) finished in the time they reported as their most accurate prediction", and on average they predicted 33.9 days and took 55.5 [6]. Two of their findings matter more for this investigation than the size of the miss. When people predicted, they "focused primarily on future scenarios", and they explained their past misses as caused by "relatively external, transient, and specific factors" [6]. Both describe how an organisation fails to learn from its last implementation. The plan is a future scenario. Last time's lost months are filed under that client's firewall, that security review and that one difficult source system: external, transient and specific, every one. Each is true, which is exactly why the lesson never transfers.

The project-overrun literature measures how far whole information technology programmes overrun [7][8], not where time goes inside a Profisee implementation, so it is no check on my shares. One illustration in the McKinsey study does bear on this investigation: a bank's data warehouse project in which the team "focused purely on developing the IT-architecture solution", which "added huge amounts of unnecessary complexity" [8]. A team that plans the platform and not the estate around it makes that mistake in its plan before it makes it in the build.

The most quoted figures in this literature are also the least reliable. The Standish Group's 1994 CHAOS report put average cost at "189% of the original cost estimate" and the average time overrun at "222% of the original time estimate", from 365 respondents [9]. Magne Jørgensen and Kjetil Moløkken found that comparable surveys "suggest average cost overrun in the range of about 30%", and noted that Standish had asked executives "to share failure stories" [10]. I lean on none of the dramatic numbers. The same CHAOS report deserves a fair hearing on one more point, because it cuts against me. Its list of factors behind challenged projects is headed by lack of user input and by incomplete and changing requirements; "Technology Incompetence" comes fifth of ten, at a little over half the weight of each of the top three, and "New Technology" comes last [9]. A reader could take that as evidence that integration and networking are not where projects go wrong. The two answer different questions. The report ranks the causes executives gave for a troubled outcome; my answer is about where the days went. My answer does not mention requirements. My reading, and it is a reading rather than something the answer says, is that the corner cases and gaps that close my answer are what a survey like this one would file as incomplete requirements, found late, rather than a separate stage.

The four articles, and where to start

The four core articles publish with this piece. Each answers one stage's question, they are written to be read in order, and a reader with a calendar already in trouble should start at the stage it is stuck in.

The Part That Goes Quickly is the foundations article, on the environment and the proof of concept. It sets out what standing up Profisee involves under each of the three deployment routes. It separates a proof of the product from a proof of the line from source to consumer, and a demonstration of capability from evidence of fit. It also explains why the speed of this stage is the reason plans are drawn from it. Start here if the plan in front of you was written from a demonstration.

Half of What Remains is the frameworks article, on integration, interoperability, security, authentication and networking. It offers ways to see that work before it arrives: a layered view of interoperability, the identity and network posture security teams now apply, and why integrations follow organisational boundaries. Start here if the platform is running and nothing can yet talk to it.

What the Review Missed is the application article, on the corner cases in the balance of the calendar. It covers relationships the old system enforced without saying so, rules that were documented and never enforced, and a one-to-many that turns out to be many-to-many. It explains why review cannot see them and what good execution looks like when they surface. Start here if the build is "done" and the loads keep failing.

The Gap Nobody Was Looking At is the implications article, on the sink nobody planned. That sink is functionality in the old estate that was deprioritised and worked around for years and is still listed as critical path for the new one. It asks how an organisation plans for what it cannot yet see, and it ends on questions. Start here before the next plan is written.

What the four show together

Most of the calendar is spent outside the product

The quick part is quick because the vendor controls it. The half that follows is slow because nobody on the project does. Fred Brooks drew this line in 1986, in the essay that told a generation of software engineers there was no silver bullet. He separated the "essence" of software from its "accidents", the difficulties "that today attend its production but that are not inherent", and he named one source of difficulty that no tool removes: conformity. "Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems" to which the software's interfaces must conform, and that complexity "cannot be simplified out by any redesign of the software alone" [11]. A platform can make its own installation fast, but it cannot make a client's identity directory, network or security process fast. Those are the institutions and systems it has to conform to, and the half of the calendar in my answer is the time it takes to conform to them. Across my career, integration and security have almost always been the longest pole in that half, because each depends on several teams coordinating; the rare implementation in which one team handles every part, so that nobody waits, is one I see less and less.

The seam is visible in the vendor's own documentation, which is to its credit. The Azure deployment template for Profisee's container release is plainly written, and its prerequisites are a list of things a master data project team does not usually own. The licence is "tied to the DNS URL that will be used by the environment". The identity that runs the deployment needs Contributor on the subscription; where the zone is hosted in Azure DNS, "DNS Zone Contributor role to the particular DNS zone where the entry will be created"; "Application Administrator role in Azure Active Directory, so the Application registration can be created"; and, if Key Vault is used, subscription-level rights to create identities and assign roles. It needs them only for the duration of the deployment [12]. Microsoft's own role reference describes Application Administrator as able to "create and manage all aspects of app registrations and enterprise apps" and marks it as a privileged role [13]. Held briefly or not, rights of that kind are not usually held by the team installing an application, and someone outside it has to grant them. They belong to whoever runs the directory, the DNS zone and the subscription, and each of those owners has its own queue and its own approvals. The template does not create that wait. It names the people the project will be waiting for. Read that way, on the container route the stage that takes under ten percent of the work ends on the line where the README's prerequisites begin. It is quick once those rights have been granted; the wait for them belongs to the half that follows. That is a convention, not a finding: the shares count the stand-up's own work, and in a locked-down estate the wait for access can make the stand-up look like the longest stage while it is happening.

The best counter-evidence I found cuts against a careless reading of my answer, and it deserves its full weight. In 2002 Len Seligman and colleagues at MITRE surveyed people with data integration experience, drawn mostly from MITRE's staff and database user groups and about a quarter from research mailing lists, on where their effort went, and reported that "the most time-consuming tasks were gathering knowledge of sources, data cleaning, and identifying semantic correspondences", while "the least time consuming tasks were creating logical mappings and creating and optimizing an executable connection" [14]. The authors warn that retrospective estimates like these "are clearly prone to error" [14], and theirs is one survey, taken in 2002. Even so, it rules out one reading of my answer: if "integration problems" meant building the connections, the survey says building them is the cheap part. My answer is not only about the wiring. It names making systems work together and troubleshooting security, authentication and network connectivity, which is the work of getting permission to connect and keeping the connection alive inside someone else's controls. Where the survey and my record overlap is the more useful finding: in both, knowing the systems at the other end is expensive, and that is where the rest of the calendar goes. What my record adds is why the half is slow, which is the coordination between teams rather than the wiring.

Running a connection is another matter from building one. On my record, running one against sources of millions or tens of millions of records is not cheap. The product's own integration tool, Connect, serves low-volume sources well, but on the implementations I have worked on it did no change detection of its own in the source system: each run loaded the source in full and compared it, which against millions of records takes significant time and resources. Profisee's own Snowflake page says runs can be launched "via CDC" [20]. It does not say what such a run then loads, and I can: a Connect run launched by CDC is filtered to only the data that triggered it. So the full load and compare is a statement about the runs I have seen, not about what the product can do.

One concession belongs here as well. A buyer of the hosted service hands the vendor "the networking, firewalls and storage" for the platform itself [2], and on that route the platform's own networking leaves the client's list. The half does not. My shares hold there too, as they do on every route, and if anything more so, because on that route integration, and the security set-up and approval that make it possible, is nearly all that is left to configure and get approved. The source systems still live in the client's estate, the users still sign in through the client's directory, and the security review still meets on the client's schedule. Nor does that work stop at go-live: a master data system keeps taking on new sources as the business adds data, and each new source goes through the same queues.

The last two stages are discoveries

The same answer went on to the rest of the calendar:

The remaining balance is eaten up with tweaks and bug fixes to correct corner cases that weren’t identified during the initial review—undocumented relationships that are now not being enforced, enforcing documented relationships that haven’t previously been gated, discovering one to many relationships that are actually many to many.

The balance in that answer is the corner-case fixes. It is not all the balance holds. The first release's deferred matching, survivorship and stewardship work sits there too. So does getting the business owners to agree definitions, match rules and survivorship, and cleansing the data, which can run alongside the integration and security steps, and almost always does. The rest of this section is about the corner cases and the gaps.

None of those corner cases is a configuration mistake, and that is the point of grouping them. Each is a fact about the old estate that was invisible as long as the old estate was the only thing reading the data, and becomes visible the day a stricter system reads it. An undocumented relationship was being kept by a habit, a screen or a downstream job that nobody wrote down. A documented rule that was never enforced has been collecting violations for years, and the first load that enforces it turns every one of them into an error. A cardinality that was modelled one way and lived another way breaks the model rather than the load. Brooks put the general case plainly: "the hard part of building software" is "the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation" [11]. The corner cases are the conceptual construct of the client's data, finally specified, and nobody could have specified them from the demonstration.

What makes them expensive is not finding them but when they are found. One way a missed relationship shows itself is a wrong merge. In one case on my record, undoing one ran as a chain: minutes to restore the master record, hours to reload the warehouse downstream of it, more hours to regenerate the reports, and further hours to revalidate the decisions and presentations built on them. That clock started only once someone had noticed. A corner case found in the first weeks costs a change to the model. The same corner case found after go-live costs that whole chain, once for every time it fires before anyone traces it. That is the strongest argument I know for moving discovery forward, and it is an argument about the calendar, not about quality.

And then to the sink nobody plans for at all:

A big one is identifying systemic gaps that hadn’t previously been noticed because no one was ever looking at the reports or using the systems. I can’t tell you how many systems I’ve worked on modernizing and standardizing that had functionality gaps that had never been completed because they were deprioritized and worked around for years while being marked as part of the critical path for the new implementation.

What separates this sink from the corner cases is its object. A corner case is a defect in how two things relate. A systemic gap is a missing function: something the old estate was always supposed to do, that it never did, that people worked around until the workaround became the process, and that is still listed as critical path because the list was copied from the last plan. No review of the data finds it, because the data is not wrong. What finds it is someone asking who uses this report, or this function, and getting no answer.

The gaps have a second cause that the new implementation can avoid repeating. They survive because what the old estate did, and failed to do, lived in people's heads and in the code rather than anywhere a newcomer could read it. I run an implementation I expect to hand over no differently from one I expect to stay with. Done properly, the policies, procedures and documents are produced as by-products of the work, so that the knowledge settles into the organisation instead of staying with the engineers, architects and stewards who happen to be there. That habit does nothing for the gaps already in the old estate. It does decide whether the next implementation, the one that replaces this one, finds a list of what this system does or starts the search again.

The corner cases and the gaps can only be found, not estimated. The estimating literature has a picture for this. The Cone of Uncertainty describes estimates at the start of a project that can be wrong by a factor of four in either direction, and its rule about how the range shrinks is the one to keep: "The Cone narrows only as you make decisions that eliminate variability" [15]. Elapsed time does not narrow it. Discovery does, and so the work that finds corner cases and gaps belongs at the front of the calendar, where finding them changes the plan. At the back of the calendar finding them only changes the date. Kahneman and Tversky's corrective points the same way: place the case in "a class to which the case at hand can be referred meaningfully" and ask how long such projects usually take [5]. Flyvbjerg built that into a method, reference class forecasting, which "achieves accuracy by basing forecasts on actual performance in a reference class of comparable projects" [18]. The difficulty for master data is that the reference class has to be the client's own history, because I found no public one. No published breakdown of where master data implementation calendars go turned up in my search. The nearest thing is the 2002 integration survey above.

Put the four stages side by side and the shape of this investigation is visible in one picture: a quick, well-described head; a half that is spent conforming to other people's systems; a balance spent on the deferred matching work and on discoveries; and a sink that was never in the plan. The plan's install, configure and test steps sit over the first stage; its go-live falls early in the second, once the first domain's sources are connected, as a first release, and nothing in the plan covers what follows.

The tail arrives when the argument for continuing is thinnest

The calendar's shape matters for one more reason, and it is the reason a sponsor should care about it. My own gloss on the word I later used for the calendar came earlier, in an answer about early value and sponsorship:

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.

The candy is low-hanging fruit: work that adds little to the timeline yet can earn support from business groups beyond the core ask, spread across the whole implementation rather than banked at the start. It is argued in the first Deep Dive, Approval Is Not the Decision, and I will not argue it again. What this investigation adds is why the tail is hardest to justify, not only that it is. The value is front-loaded because the quick part delivers something visible: a running platform, a first matched domain, a demonstration on real data. The cost is back-loaded because the corner cases and the gaps come later, are found one at a time, and each looks small. So a programme reaches its middle carrying the work that is hardest to describe and the least new to show for it. Asked when a funded programme's troubles tend to show, I put it this way:

Months four to six is where the project is either wrapping up, if it is shorter, or getting into the meat of it if it is multi-year. It is one of the key inflection points: the team is either firing on all cylinders or clearly misfiring, and it is around the time all the low-hanging fruit has been addressed and the only remaining issues are the thorny ones. That is why you often see a rocky shoal during the second and third PIs — the team has learned what it could and got past the growing pains inherent in starting. Per Agile doctrine the team is supposed to be performing, but it can revert to storming as new challenges arise that were not encountered earlier.

Two terms in that answer need a gloss, and both are borrowed. The PI is the Scaled Agile Framework's planning interval, "a cadence-based timebox", normally "an 8 to 12-week timebox" [16]. Storming is the second of the four stages, "forming", "storming", "norming" and "performing", that Bruce Tuckman drew in 1965 from a review of 50 articles on how groups develop [17]. What my answer adds to the borrowed terms is timing. Read beside the calendar above, the rocky shoal falls where the corner cases and gaps are being found, after the low-hanging fruit has gone, and it is the stretch in which a sponsor is deciding whether to keep paying. That is why a calendar planned from the quick part fails twice. It is late, and it is late at the moment the programme can least afford to look late. Who carries the programme through that stretch is argued in Nobody Wins a Sponsor in Flight, and how to show it is delivering while it does is argued in Proving the Platform Is Delivering.

Each stage has a different owner, and the plan has one

Read the four articles together and one more pattern shows, which none of them states on its own. Each stage of the calendar is owned by a different group. The vendor and the implementer own the quick part, with the client's platform team on the on-premises and container routes. The half belongs to the client's identity, network, security and architecture functions, none of which reports to the programme. The corner cases belong to the owners of the source systems, because only they can say what a relationship was supposed to be. The gaps belong to the business users and report consumers who stopped using a function, or never started, and whose answer to "who uses this?" is the only evidence that settles it. The plan has one owner, the programme, which mostly controls the first stage and only influences the other three.

That is also why my working rule for the boundary between master data and the systems around it is that the master data platform decides what, and the other systems decide how. A source system owns the logic that produces its values; the platform owns the logic that chooses among them for the master record. The rule keeps the platform out of other owners' logic, and it also marks where the calendar leaves the programme's control. Every "how" belongs to someone else, and changing one goes through their queue. The second risk follows from the first. When master data travels inside a larger modernisation or migration, which is sometimes the only way it gets funded, it shares that initiative's fate, and a delay in someone else's stage becomes its delay. A plan that names an owner and a queue for each stage at least shows where the waiting will be.

What I would do on the first day

From here the warrant is my own record rather than the literature: what I would do differently on the first day of an implementation, offered as a pattern I have watched hold, not as a law. I keep the clients out of it; I would rather be vague than disparage a project I worked on.

Plan by where the time goes, not by the vendor's steps. A plan built from the installation guide has the stages install, configure, test, go live, and on my record very little of the work falls in the first of them. The plan should carry lines for the work this investigation names: access and identity, network paths and certificates, integration with each source, discovery of relationships, and an honest reckoning with what the old estate never did. Each line needs an owner outside the project, because most of them have one.

Open the other teams' queues on the first day. On my record the gates that hold a programme up are run by groups that meet when they meet, such as architecture review, security approval and data classification, and whose members are lent from other work. A gate that meets monthly costs a month every time a request misses it. The README's prerequisites [12] are a list of those queues, and the time to join them is before the platform exists, not after it is waiting. The frameworks article, Half of What Remains, sets out how to sequence them.

Prove the whole line early. The proof of concept that matters is not the platform running. It is a record travelling from a real source, through the platform, to a real consumer, inside the client's own security controls. On my record that is the single move that finds the problems while there is still time to fix them, and the foundations article, The Part That Goes Quickly, makes the case in full. It is also the move a plan drawn from the quick part leaves out, because it drags the slow half forward into the first weeks.

Put discovery in the plan as work, not as contingency. Contingency is a reserve for the unexpected. Corner cases are not unexpected, only unidentified, and the way to identify them is to look. My own preferred start is to extract the schema metadata from every system being integrated and lay it side by side before modelling anything, so that the redundancies and the single sources of truth show up before the model commits to either. The application article, What the Review Missed, shows what that looks for. A second disclosure belongs here, because this is where the advice and our revenue meet: Shabel Enterprises sells a fixed-price assessment of exactly this kind, reading metadata across systems and inferring the relationships between them. Discount my enthusiasm for discovery by that much, and judge it by whether it finds things.

Ask who uses it before accepting that it is critical path. On my record, every migration off an old platform has stopped reports and loads, and each migration between reporting platforms has come with a review that retired dozens of reports, if not hundreds, along with the data models behind them. A report nobody reads is a function nobody is checking, and a function nobody is checking is where the systemic gaps live. The implications article, The Gap Nobody Was Looking At, takes that further.

Keep your own reference class. Kahneman and Tversky's corrective and Flyvbjerg's method both depend on a record of where comparable projects actually went [5][18], and for master data implementations no such record turned up in my search. An organisation can build its own cheaply: at the end of each implementation, write down where the calendar went by stage, in the terms this investigation uses, and give the next plan that page before it gives it the vendor's guide. That one page of distributional information is what the planning fallacy says is missing.

What to watch

The boundary between the quick part and the slow half is moving, and it is moving toward the vendor. The hosted service takes the platform's networking and firewalls on to the vendor's side [2], and Profisee now markets itself as "The Only Native MDM Workload in Microsoft Fabric" [19]. Weigh what follows against the interest disclosed above. Whether a workload that lives inside a platform the client already runs shortens the half spent on integration is an open question. The vendor's page does not settle it, and on my record the half has held on every route so far, so a reader evaluating that route should ask for the evidence in the client's own terms: which identity, network and security approvals the route removes, and which it leaves in place.

The deployment routes themselves are diverging, and a plan should say which route it assumes and which approvals that route still needs, because a route change mid-programme moves work between teams and their calendars.

The evidence base deserves watching too, mostly for what it lacks. The most dramatic overrun figures are the least reliable [9][10], the best survey of where integration effort goes is two decades old and self-reported [14], and nothing I found in public describes where master data implementation calendars go. Until something does, the reference class each organisation keeps for itself is the best evidence it will have, and it is worth more than any figure in this piece, mine included.

Where the calendar goes

The demonstration, the quote and the template are all good evidence about the quick part, and they are what plans are drawn from. On my record that part is under ten percent of the work. About half of the rest goes to conforming to systems and institutions the project does not control. Much of the balance goes to facts about the old estate that only a stricter system could reveal, and one sink was never in the plan at all. None of that makes the vendor's speed claims false. It does mean a plan drawn from them is planning the wrong part of the job. Plan the calendar by where it goes, open the slow queues first, find the discoveries early enough that they change the plan, and keep a record of where your own calendar went so the next plan starts from it.

The four articles that go with this one

• The Part That Goes Quickly
• Half of What Remains
• What the Review Missed
• The Gap Nobody Was Looking At

References

All sources were read on 12 or 13 October 2026; an entry says where the reading was partial or from a copy.

[1] Joseph M. Juran, "The Non-Pareto Principle; Mea Culpa" (1974), PDF published by the Juran Institute. Cited for his confession that he "mistakenly applied the wrong name to the principle" and for his statement of it, "a relative few of the contributors account for the bulk of the effect"; the essay's body gives no fixed ratio (an "80/20" appears only in the host page's editorial sidebar, not in Juran's text). https://www.juran.com/wp-content/uploads/2021/03/The-Non-Pareto-Principle-1974.pdf

[2] Profisee, "Cloud Master Data Management Architecture" (product page), read 12 October 2026. Cited for "Get Profisee running in minutes whenever you're ready to start", for the hosted offering's "Leave the networking, firewalls and storage to us so you can deploy in minutes", and for the hosted service being "Hosted in Azure by Profisee". These are the vendor's own claims about its own product. https://profisee.com/platform/modern-cloud-architecture/

[3] Profisee, "Implement Quickly & Successfully" (FastStart services page), read 12 October 2026. Cited for the packaged tiers' durations (Express "~4-6 weeks", Accelerate "~12 weeks", Turn-key "~3-6 months (based on complexity)"; no prices are given), the single-domain tier "delivered in as little as 12 weeks", the turn-key tier's "advanced integrations", the page's silence on security and network work, and its attribution to Gartner of "more customers go live in under 90 days than any other vendor"; the Gartner source itself was not read. https://profisee.com/services/

[4] Profisee, "Profisee/kubernetes" (public GitHub repository, README), read 12 October 2026. Cited for the repository's description, "Everything you need to know about deploying Profisee Platform on AKS, EKS and GCP", as evidence that the container release deploys as a Kubernetes installation on those services. https://github.com/Profisee/kubernetes

[5] Daniel Kahneman and Amos Tversky, Intuitive Prediction: Biases and Corrective Procedures, technical report, Decision Research (a branch of Perceptronics), June 1977, prepared under a Defense Advanced Research Projects Agency contract monitored by the Office of Naval Research. Read as the scanned copy on the Defense Technical Information Center site. Cited for the sentence introducing the "planning fallacy", the definitions of singular and distributional information, and the corrective step of selecting "a class to which the case at hand can be referred meaningfully". https://apps.dtic.mil/sti/pdfs/ADA047747.pdf

[6] Roger Buehler, Dale Griffin and Michael Ross, "Exploring the 'Planning Fallacy': Why People Underestimate Their Task Completion Times," Journal of Personality and Social Psychology 67, no. 3 (1994): 366–381. Read as a course-hosted copy. Cited for the thesis-completion result (29.7% finishing by their best prediction; 33.9 days predicted, 55.5 taken), the finding that predictors "focused primarily on future scenarios", and the attribution of past failures to "relatively external, transient, and specific factors". https://bear.warrington.ufl.edu/brenner/mar7588/Papers/buehler-et-al-1994.pdf

[7] Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project Might Be Riskier Than You Think," arXiv:1304.0265 (2013); a version appeared in Harvard Business Review in 2011. Read at the abstract only; the PDF could not be downloaded. Cited as one of the studies of how far whole information technology programmes overrun. https://arxiv.org/abs/1304.0265

[8] Michael Bloch, Sven Blumberg and Jürgen Laartz, "Delivering large-scale IT projects on time, on budget, and on value," McKinsey & Company, 1 October 2012 (research with the University of Oxford). Cited as one of the studies of how far whole information technology programmes overrun, and for the bank data-warehouse illustration. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

[9] The Standish Group, CHAOS (report, dated 1994 by its critics [10] and published under a 1995 copyright: the hosted copy carries "© The Standish Group 1995"), read as a copy hosted by the Technical University of Munich. Cited for average cost, "189% of the original cost estimate", and the average time overrun, "222% of the original time estimate" (the report states the two in those different terms), the sample of 365 respondents, and its ranked list of challenged-project factors (Technology Incompetence fifth of ten at 7.0%, behind 12.8%, 12.3%, 11.8% and 7.5%; New Technology tenth at 3.7%). https://wwwbroy.cs.tum.edu/lehre/vorlesungen/vse/WS2004/1995_Standish_Chaos.pdf

[10] Magne Jørgensen and Kjetil Moløkken(-Østvold), "How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report" (2006), DOI 10.1016/j.infsof.2005.07.002. Read as the authors' copy hosted by Simula Research Laboratory; the copy does not carry the journal's volume and pages, and they were not verified. Cited for the finding that comparable surveys "suggest average cost overrun in the range of about 30%" and for the CHAOS survey's request that executives "share failure stories". https://cms.simula.no/sites/default/files/publications/Jorgensen.2006.4.pdf

[11] Frederick P. Brooks, Jr., "No Silver Bullet: Essence and Accident in Software Engineering," Proceedings of the IFIP Tenth World Computing Conference (1986): 1069–1076; reprinted in The Mythical Man-Month, anniversary edition (1995). Read as a copy hosted on worrydream.com. Cited for the essence/accident distinction, the sentence on "the hard part of building software", and the passage on conformity to "the many human institutions and systems", which "cannot be simplified out by any redesign of the software alone". https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf

[12] Profisee, "Azure-ARM" README in the Profisee/kubernetes repository, read 12 October 2026. Cited for the licence "tied to the DNS URL that will be used by the environment" and for the deployment identity's role prerequisites with their conditions: Contributor on the subscription; DNS Zone Contributor where DNS is hosted in Azure; "Application Administrator role in Azure Active Directory, so the Application registration can be created"; Managed Identity Contributor and User Access Administrator at subscription level, not required if Key Vault is not used; all needed only while a deployment runs. https://github.com/Profisee/kubernetes/blob/master/Azure-ARM/README.md

[13] Microsoft, "Microsoft Entra built-in roles," Microsoft Learn, updated 10 September 2026. The Application Administrator entry was read in the first part of a very long page. Cited for the role's description, "Can create and manage all aspects of app registrations and enterprise apps", and its privileged marking. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference

[14] Len Seligman, Arnon Rosenthal, Paul Lehner and Angela Smith, "Data Integration: Where Does the Time Go?" IEEE Data Engineering Bulletin, September 2002 (The MITRE Corporation). Cited for the survey (95 responses, 93 analysed, retrospective estimates; respondents drawn from MITRE staff and referrals, Oracle and DB2 user groups and other practitioner lists, with 25 from the DBWORLD and DBRSRCH research lists) and its findings on the most and least time-consuming integration tasks, and for the authors' caution that such estimates "are clearly prone to error". https://www.mitre.org/sites/default/files/pdf/seligman_data_integration.pdf

[15] Construx Software, "The Cone of Uncertainty" (web page, published 2016, modified 2020; a book excerpt whose book the page does not name). Cited for the fourfold range at initial concept and for "The Cone narrows only as you make decisions that eliminate variability." https://www.construx.com/books/the-cone-of-uncertainty/

[16] Scaled Agile, Inc., "Planning Interval (PI)," SAFe framework site, last updated 25 February 2025. Cited for the definition, "a cadence-based timebox", and the "8 to 12-week" length. https://framework.scaledagile.com/planning-interval

[17] Bruce W. Tuckman, Citation Classic commentary on "Developmental sequence in small groups," Psychological Bulletin 63 (1965): 384–399, in Current Contents (1984). The commentary and the reprinted abstract were read, not the 1965 paper. Cited for the four stages and the review of 50 articles on which the model was based. https://garfield.library.upenn.edu/classics1984/A1984TD25600001.pdf

[18] Bent Flyvbjerg, "From Nobel Prize to Project Management: Getting Risks Right," arXiv:1302.3642 (2013); first published in Project Management Journal in 2006 (journal details not verified). Read at the abstract only. Cited for reference class forecasting, which "achieves accuracy by basing forecasts on actual performance in a reference class of comparable projects". https://arxiv.org/abs/1302.3642

[19] Profisee, "Microsoft Fabric" (solution page), read 12 October 2026. Cited for the headline "The Only Native MDM Workload in Microsoft Fabric", a vendor's description of its own product. https://profisee.com/solutions/microsoft-enterprise/microsoft-fabric/

[20] Profisee, "Profisee MDM for Snowflake" (solution page), read 13 October 2026. Cited only for step 4 of its Connect set-up, "Launch integration runs on demand, on a schedule or via CDC", a vendor's description of its own product; the page does not say what a run launched that way loads. The article's statement of what such a run loads is the author's own answer, not the page's. https://profisee.com/solutions/profisee-mdm-for-snowflake/