Business Intelligence Guidebook: From Data Integration to Analytics

1. 1Sequence training in three layers: vendor-agnostic foundational BI training first (concepts and shared vocabulary), then use-case-based training tied to actual business processes, then tool-specific training only when people are ready to build. The book's stance is explicit: 'After this book, you should be ready to learn specific tools' — foundation precedes vendor mechanics.
2. 2Segment your audience into business people and IT people, and design distinct tracks. The passages treat these as separate constituencies with different roles ('who does what, how they interact'); a data modeling track (conceptual/logical/physical models, ER, normalization) targets technical team members, while requirements-gathering and interviewing skills matter more for people-facing roles.
3. 3Ground foundational training in the distinction between raw data and actionable information. Use Chapter 1's framing so trainees understand why BI exists and why 'there really is no good substitute for true BI' before they touch any tool.
4. 4Build use-case-based modules from real BI styles the organization uses: reporting, dashboards or scorecards, OLAP/pivot, ad-hoc query, statistical analysis, alerting, data discovery, data visualization, and spreadsheets. Match each person's training to the styles their role actually consumes or builds.
5. 5Pair training investment with the change-management case. Because business people will pick 'good enough' alternatives that 'do not require retraining and change,' explicitly budget for retraining and address it in the technical case so adoption does not collapse post-deployment.
6. 6Route training toward reducing data shadow systems: train business groups on the sanctioned BI path so they stop creating spreadsheet silos when 'they do not want to work with IT or cannot wait for them.'
7. 7Reinforce a people-centric mindset in every module — the book deliberately avoids the word 'user' because 'we are building BI solutions for people.' Frame training around roles and workflows, not features.
8. 8Anchor training material to the companion resources (www.BIguidebook.com templates, examples, vendor links, updated research) so the vendor-agnostic and tool-specific layers stay current as vendors merge or are acquired.

The book itself is the worked model of foundational, vendor-agnostic training. Rick writes it to 'fill in the gap between books that focus on the concepts of business intelligence and the nitty gritty of vendor tool training' — deliberately not naming products or vendors because 'these can change frequently as companies merge and are acquired.' It teaches you not just a foundation but 'how to apply that foundation in order to actually get your work done,' so that afterward 'you should be ready to learn specific tools.' Chapters 8-10 are explicitly aimed at technical members who build data models — the IT track — covering conceptual/logical/physical levels, ER modeling, and normalization, while chapters on requirements and justification serve business and mixed audiences. A professor can request a syllabus (BIguidebook@athena-solutions.com), showing the material is structured for staged, use-case teaching. This is the intended progression: concepts and shared vocabulary, then applied use cases, then vendor tool mechanics.

• If a person cannot yet articulate the difference between raw data and actionable information, then delay tool-specific training and start with foundational BI concepts.
• If the trainee is a technical team member who will build data models, then route them through conceptual/logical/physical modeling, ER, and normalization; if they are business-facing, then prioritize requirements interviewing and BI-style consumption.
• If business people are gravitating to a 'good enough' alternative because it avoids retraining, then invest in change-focused training and couple it with the technical case rather than assuming the tool sells itself.
• If data shadow systems are proliferating, then treat training the affected business groups on the sanctioned path as part of remediation, not a separate afterthought.
• If vendor tool selection is still unsettled, then keep training vendor-agnostic and lean on the companion site for current vendor links rather than baking product names into curriculum.

• Jumping straight to vendor tool training. The tell: people can click through the tool but cannot connect the mechanics to concepts or get real work done — the 'gap' the book was written to fill.
• Training only IT and leaving business people out. The tell: the technologists and power users are 'so enamored with the new tool that they have no idea that the business community would consider inferior alternatives,' and adoption stalls after launch.
• Ignoring the retraining cost in the business case. The tell: business selects doing nothing or expanding operational reporting because the BI path 'does not require retraining and change.'
• Treating training as a technology problem. The tell: teams say 'technology is easy; it is people that are hard' after the fact — roles, interaction, and politics were never trained.
• Baking product/vendor names into permanent curriculum. The tell: material goes stale as 'companies merge and are acquired,' and trainees learn a tool that no longer exists in its taught form.

• ▸Audience segment: business person or IT/technical team member
• ▸Current foundation level: can they distinguish raw data from actionable information? (yes/no)
• ▸Foundational (vendor-agnostic) module: concepts and shared vocabulary this person needs
• ▸Use-case module: which BI styles (reporting, dashboards, OLAP, ad-hoc, stats, alerting, discovery, visualization, spreadsheets) map to their role
• ▸Tool-specific module: named tool and readiness gate (only after foundation + use case)
• ▸Change/retraining component: what resistance or 'good enough' alternative this training must counter
• ▸Data shadow remediation link: which shadow system this training helps replace or fold in
• ▸Companion resource reference: BIguidebook.com templates/examples/vendor links used
• ▸Success measure: what the trainee can do afterward that they could not before

1. 1Review the organization's strategic business initiatives, business drivers, and hindered processes first — anchor governance and sponsorship to business needs, not to IT questions like tool selection.
2. 2Identify and enlist a business sponsor from your list of business needs: someone with budgetary authority OR an influential leader who can get funding approved. Do not default to the CIO as sole sponsor.
3. 3Get the sponsor to commit beyond the budget: securing business resources for the full project, engaging in politics to protect money and resources for the long haul, and providing support when hiccups occur.
4. 4Screen the sponsor for three traits — politically astute, enthusiastic, and realistic — and set realistic expectations explicitly so neither sponsor nor team overpromises.
5. 5Establish an enterprise-wide BI program (not a one-off project) so priorities can be matched to business demand; prioritize the overwhelming demand list down to what one justification can deliver now, while planning for future initiatives.
6. 6Stand up data governance as a people-centric program that manages the business/IT relationship, roles, and responsibilities to transform data into actionable information.
7. 7Install a steering committee for oversight and build Centers of Excellence — a BI COE to coordinate BI resources and expertise across silos, and a DI COE to own data integration scope, architecture, and vision.
8. 8Assign project management discipline: use an assessment, build a work breakdown structure, choose a methodology, and drive the project through defined phases and schedule.

The book warns against the classic 'if we build it they will come' failure, where BI groups assumed a data warehouse was obviously needed. These projects grew too big and long, sold the business an 'information nirvana,' missed expectations, and spawned data shadow systems — the one-off spreadsheets business groups build in frustration when the DW project takes too long. The governance corrective is to answer four business-case questions up front (what problems/opportunities, who will use it, anticipated benefits, and why prior initiatives failed), then secure real sponsorship rather than just an approved budget. A sponsor who only writes the check but does not commit business resources or fight the political battles leaves the project exposed. The passages note that studies show most BI projects fail from an expectations shortfall, not technology — which is why realistic sponsorship and steering-committee oversight matter more than tooling. Structuring the demand into a prioritized long-term program, rather than delivering everything at once, keeps the effort grounded.

• If the only sponsor is the CIO, treat it as a red flag — the project will be perceived as technology-driven and lack business commitment; recruit a benefiting business group as sponsor.
• If a sponsor lacks budgetary authority, then require they be an influential leader who can get funding approved — otherwise do not proceed.
• If the sponsor is enthusiastic but not realistic, temper expectations before starting; overzealous sponsorship is a mixed blessing that breaks when scope changes.
• If the prioritized demand list exceeds delivery capacity, then fold the surplus into a long-term BI program with priorities matched to demand rather than attempting it all at once.
• If the enterprise suffers from disconnected application and data silos, stand up a COE (BI COE and/or DI COE) to coordinate resources, expertise, and integration vision.

• Assuming budget approval is the sponsor's only deliverable — the tell: no business resources are committed and no one defends the project politically when problems hit.
• Making the CIO the sole sponsor — the tell: the project is framed as an IT initiative and business groups stay uninvolved.
• 'If we build it they will come' overreach — the tell: the project is too big, too fast, promises 'one version of the truth,' and spawns data shadow systems as frustrated users route around it.
• Lack of steering-committee oversight and no data governance — the tell: data quality is not addressed and information stays inconsistent and unusable.
• Stating intangible or too-high-level benefits ('faster time to market,' 'better decision making') — the tell: no documented, measurable business benefits tied to specific processes.

• ▸Business initiative addressed: name the strategic driver or hindered process this BI effort supports.
• ▸Business problem/opportunity: state what is being solved and who will use it.
• ▸Prior initiative review: list any failed BI efforts and why they failed.
• ▸Named business sponsor: identify the person and confirm budgetary authority or funding influence.
• ▸Sponsor commitments: list resources, political support, and issue-handling the sponsor will provide beyond budget.
• ▸Sponsor trait check: rate politically astute / enthusiastic / realistic and note expectation-setting done.
• ▸Steering committee / oversight: name members and cadence for reviewing priorities and progress.
• ▸Governance scope: define data governance owner and the roles/responsibilities across business and IT.
• ▸COE plan: specify whether a BI COE and/or DI COE is needed and its initial scope.

1. 1Sequence the Five Cs against the data flow: run clean first (data profiling and cleansing on source), then consistent, conformed, current, comprehensive — because dirty transactional data poisons everything downstream.
2. 2Profile every source before ingestion to expose missing items, invalid entries, and other defects; treat customer and prospect data as presumed dirty since it is notorious for it. Make profiling and cleansing explicit, non-optional steps in the data warehousing workflow.
3. 3Resolve consistency at the definition level, not the data level: establish one agreed version of each metric, hierarchy, and calculation so management meetings argue about improving sales, not about whose number is right.
4. 4Build conformed, shareable dimensions so business people across the enterprise analyze against common dimensions and decide from the same information.
5. 5Set currency per decision type: define the required freshness for each application (up-to-the-minute for credit card fraud detection, less for others) rather than defaulting all data to one refresh cadence.
6. 6Guarantee comprehensiveness by mapping what each persona needs — all data regardless of source or level of granularity — and confirm the target model can deliver that granularity before development.
7. 7Validate each C against a signed-off requirement from Chapter 3 (Business, Data, and Quality), since these requirements are the foundation the team uses to design, develop, and deploy.

A CFO must sign off on financial reports and press releases based on real-time disclosure. Before that is safe, the enterprise data must clear all Five Cs. Clean: profiling exposes missing and invalid entries that would otherwise wreck automated integration, so cleansing runs first. Consistent: finance agrees on one revenue calculation so no meeting devolves into whose number is correct. Conformed: revenue is analyzed across shared dimensions so regional and corporate views reconcile. Current: the disclosure data is refreshed to the freshness the filing demands. Comprehensive: every source feeding the statement is included at the needed granularity. With all five satisfied, the CFO signs off at low risk instead of finding — or worse, having a customer find — errors after publication.

• If source data has missing items or invalid entries, then profile and cleanse before any integration — dirty data wrecks automated data integration and analysis.
• If two groups report different numbers for the same metric, then fix definitions (hierarchies and calculations), not the transactional data — clean data alone will not stop the argument.
• If the decision is fraud detection or similar, then require up-to-the-minute currency; if not, set currency to whatever the decision type actually needs and no more.
• If a persona cannot get all the data they need at the required granularity, then the data is not comprehensive yet — do not ship the application.
• If a customer could plausibly find an error before you do, then treat that C as unmet — mistakes are expensive and embarrassing.

• Skipping data profiling and assuming source data is clean; the tell is automated integration jobs failing on invalid entries and analysis returning nonsense.
• Cleaning transactional data but leaving metric definitions inconsistent; the tell is management meetings breaking down into arguments over whose number is correct.
• Using non-shared dimensions per department; the tell is that enterprise-wide views cannot reconcile and each group defends its own numbers.
• Applying one refresh cadence to all data; the tell is either stale data on time-sensitive decisions or wasted effort refreshing data that never needed to be current.
• Delivering partial data because some sources or granularities were hard to source; the tell is business people rebuilding data shadow systems to fill the gaps.

• ▸Data domain / application: name the subject area and the BI application it feeds.
• ▸Clean status: profiling findings — missing items, invalid entries, cleansing steps done.
• ▸Consistent status: the single agreed definition, hierarchy, and calculation for each metric.
• ▸Conformed status: list the common shareable dimensions used across the enterprise.
• ▸Current requirement: the freshness this decision type demands (e.g., up-to-the-minute).
• ▸Comprehensive check: all required sources and granularities, per persona, confirmed present.
• ▸Business owner / BI owner: who signs off that each C is met.
• ▸Risk if unmet: consequence of shipping with this C unresolved (e.g., CFO sign-off exposure).

1. 1Run a data shadow system census: survey the enterprise for spreadmarts, Access databases, and departmental reporting tools that pull, transform, and re-report data outside the DW, then triage each by risk, scope, and data currency.
2. 2For each silo, trace the transformation path from source to analysis using metadata; where transforms are manual code or spreadsheet macros known only to the owner, flag it as a black hole and document what happens to the data.
3. 3Apply the 'do once, use many' test: identify every place the same measure or dimension (e.g., customer list, product list) is being recreated, and consolidate the transformation upstream into shared, reusable, documented data stores.
4. 4Shift data transformation as far upstream as it makes sense — from BI to data franchising to data preparation — so reuse, consistency, and resource efficiency all improve.
5. 5Decide the reporting architecture per application: shift users to the application-specific reporting silo (supplemented from other apps), shift all reporting to the DW-based BI environment, or blend the two — based on whether the vendor is a mega-application vendor, a cross-function vendor, or neither.
6. 6Use conformance and consistency data quality services to reconcile the silos: build conformed dimensions for shared entities and standard measures on fact tables, using data profiling to quantify the extent of nonconformance and nonstandardization.
7. 7Stand up a Center of Excellence (BI COE for coordination, DI COE for scope/architecture/vision) so the consolidation is governed and does not regress into new silos.
8. 8Pair the technical consolidation with data governance — a people-centric program — so ownership, definitions, and business rules are signed off by responsible business people rather than left implicit in shadow tools.

An enterprise runs a mega-application vendor's suite alongside several cloud and on-premise specialty applications, each with its own operational reporting environment. Business people need both operational and management reporting, so reporting silos proliferate, each producing overlapping and inconsistent numbers when compared against the DW-based BI environment — the 5 C's of data are broken. IT evaluates the three alternatives: because the mega-vendor's application spans many business processes and ships its own DW and BI tool, shifting all reporting to that application-specific environment gets serious consideration, while the specialty apps argue for blending. IT profiles the customer and product data across silos, finds multiple nonconformed lists, and builds conformed dimensions plus standardized fact measures. Transformations that had lived in analyst spreadsheets are moved upstream into documented DI jobs with audit and error-handling metadata. The result is one transformation performed once and reused, closing the black holes and reconciling the silo numbers to the DW.

• If a transform is done via manual coding or spreadsheet macros and is invisible/undocumented outside its owner, then treat it as a black hole and prioritize renovating it before it is trusted.
• If the same dimension or measure is being recreated in multiple silos, then build a conformed dimension / standard measure and transform once upstream rather than per silo.
• If the application vendor is a mega-vendor with its own DW and acquired BI tool, then shifting all reporting into the application-specific environment is a legitimate option; if it is a specialty vendor, then blend with the DW BI environment instead.
• If a shadow system delivers real benefit but carries risk, then renovate it rather than attempt a blunt replacement — misguided replacement attempts are a documented failure path.
• If a business rule or measure definition lacks sign-off from a responsible business person, then do not operationalize the consolidation until governance provides it.

• Trying to kill shadow systems outright with a mandated replacement — the passages explicitly warn of 'misguided attempts to replace data shadow systems.' Tell: users quietly keep the old spreadsheet running in parallel.
• Falling into the technology trap — buying a BI/DI tool and assuming silos are solved, ignoring the business-IT relationship and governance. Tell: new silos appear right after the tool rollout.
• Leaving transformation logic in BI-layer manual code so it is not reusable, visible, or documented. Tell: no metadata tracing data from source to analysis; only the developer knows what happened.
• Consolidating structure without reconciling semantics — no conformed dimensions or standard measures. Tell: overlapping, inconsistent numbers persist across the DW and the app reports.
• Skipping data profiling before conformance/consistency work. Tell: the team underestimates the extent of nonconformance and the reconciliation stalls mid-project.

• ▸Silo name & type: spreadmart, Access DB, or application reporting environment.
• ▸Data sources & currency: where it pulls from and update frequency (note the data currency gap).
• ▸Overlap/inconsistency: which DW entities/measures it duplicates or contradicts.
• ▸Transformation visibility: is logic documented, shared, reusable, or a black hole?
• ▸Business owner sign-off: named responsible person for its rules/definitions.
• ▸Risk & benefit: triage rating balancing damage caused vs. benefit delivered.
• ▸Target architecture: app-specific silo, all-to-DW, or blended.
• ▸Upstream move: transformation shifted to franchising/preparation? (yes/where).
• ▸Governance/COE owner: BI COE or DI COE accountable for the fix.

1. 1Detect the trust deficit first: watch meetings for the tell that business people spend time debating whose numbers are correct or reconciling data instead of acting on it. That symptom, not tool selection, tells you foundational work is required.
2. 2Get serious about data governance on two fronts: agree on data definitions and agree on business metrics. Establish these before investing in slick visualizations, because inconsistent data makes any visualization worthless (the old GIGO rule — garbage in, garbage out).
3. 3Attack the data integration backlog directly. Gather, cleanse, standardize, conform, and transform data from multiple business processes rather than believing vendor claims that the latest analytic tool lets you 'point and click' to answers without integration.
4. 4Bring the data into the Five Cs state — clean, consistent, conformed, current, and comprehensive — so every consuming application draws from the same trusted foundation.
5. 5Govern spreadsheets: allow them only when they analyze the same consistent, comprehensive, clean, and current data as the dashboards, data discovery, and visualization tools. Forbid their use as an ungoverned data integration and transformation layer.
6. 6Enlist the business power user who built or maintains the shadow system to reverse engineer the old business rules and data. When that power user blesses the new solution, they become the business's 'trusted advisor' and adoption is almost guaranteed.
7. 7Stand up a cross-functional BI COE of business and IT people to coordinate metrics, definitions, and analytics so different groups stop producing conflicting numbers and share one trusted set.

A power user maintains a data shadow system built on old business rules the business person requesting new requirements has forgotten or assumes IT already knows. Rather than build the new BI solution on incomplete requirements and watch it get derailed the moment people start using it and disputing the output, you enlist that power user to reverse engineer the embedded business rules and data. The work is not exciting for IT, but the bulk of it falls to the power user who already understands the shadow system. Enlisting them pulls that person into the BI virtual team and turns them into an advocate — the business's trusted advisor for this analysis. When the power user blesses the new solution, business adoption is almost guaranteed because the people who would otherwise debate the numbers now vouch for them. The gaps reverse engineering fills are exactly the ones that would later surface as 'these numbers are wrong' arguments.

• If business people spend meetings debating or reconciling numbers, then stop adding visualizations and do the unglamorous governance and integration work first.
• If a spreadsheet analyzes the same clean, consistent, comprehensive, and current data as the governed applications, then it is a viable tool; if it is used as an ungoverned integration/transformation layer, then it is a trust problem.
• If a shadow system exists, then reverse engineer its business rules with the power user before building, rather than assuming IT already knows them.
• If the power user blesses the new solution, then expect near-automatic business adoption; if they do not, treat it as unresolved and do not deploy.
• If a vendor claims the latest tool removes the need to integrate data, then distrust it — 'it is not that easy.'

• Buying slick visualization and data discovery tools before fixing data consistency. Tell: dashboards look impressive but people still argue over which number is right.
• Believing the point-and-click vendor pitch and skipping integration. Tell: a growing data integration backlog that everyone keeps deferring while chasing new tools.
• Letting spreadsheets become the ungoverned integration and transformation layer. Tell: multiple people produce different totals from 'the same' report with no shared architecture behind them.
• Building the new BI solution on requirements alone while ignoring the shadow system's embedded rules. Tell: the solution gets derailed the moment business users start using it and find missing rules or data.
• Treating trust as purely a technology problem. Tell: heavy tool spend with no governance of definitions or agreed-on metrics, so debates continue.

• ▸Disputed metric — name the number people currently argue about
• ▸Trust symptom — where you observe debating/reconciling (which meeting or report)
• ▸Data definition owner — who agrees the definition of this data
• ▸Metric owner — who agrees the business calculation of this metric
• ▸Five Cs gap — which of clean/consistent/conformed/current/comprehensive is failing
• ▸Integration status — is this data properly integrated or point-and-click assumed
• ▸Spreadsheet check — does the spreadsheet use the same governed data (Y/N)
• ▸Shadow system + power user — which shadow system feeds this and who maintains it
• ▸Blessing status — has the power user validated the new source (Y/N)

1. 1Identify the business power user who built or maintains each data shadow system in scope; enlist that person into the BI virtual team rather than routing around them.
2. 2Reverse engineer the data shadow system to extract the business rules and data the requirements-giver forgot or assumed the BI team already knew — assign the bulk of this to the power user who owns the shadow system, not IT.
3. 3Collect the full requirement set — business, data, functional, regulatory, technical, and existing reporting — from every business group in scope, recognizing that diversity of needs grows as scope grows.
4. 4Consolidate the varied requirements into one cohesive document, then cross-reference (tag) each along business value, business processes, business group, data sources, and analytical functionality to expose overlaps, redundancies, conflicts, and dependency gaps.
5. 5Design an information and data architecture before evaluating products, so BI applications support diverse business processes without collapsing into silos — resist the pull to make product selection the focus.
6. 6Where application-based operational reporting is already embedded in business processes and working, leave it in place ('if it ain't broke, don't fix it') and blend it with DW BI rather than duplicating it.
7. 7Build a blended data and technical architecture spanning enterprise applications, DWs, data marts, cubes, and even spreadsheets, so business people see consistent information and never have to guess which silo to query.
8. 8Have the power user validate the delivered solution; secure their blessing before broad rollout, since that endorsement is what converts the business from shadow systems to the BI application.

A business power user built a data shadow system that quietly embedded business rules the new requirements-giver either forgot or assumed the BI team knew. Instead of building the new BI solution from the incomplete written requirements, you assign that power user to reverse engineer their own shadow system, filling the inevitable gaps that would otherwise derail the solution once business users touch it. Doing so pulls the power user onto the BI virtual team and reframes them as the business's 'trusted advisor' for this analysis. When the finished solution is presented, the power user blesses it — and because the business already trusts that person, adoption becomes almost guaranteed. Contrast this with the 'Twilight Zone' trap: an enterprise skips information architecture, picks 'best' products, ships late and over budget, fails to reach active adoption, blames the product, buys a new one, and loops forever. The difference is that architecture-plus-power-user route ends in usage; the product-chasing route ends in abandonment back to spreadsheets.

• If a business power user created or maintains the data shadow system, then assign them the reverse-engineering work and bring them onto the virtual team — their blessing nearly guarantees adoption.
• If application-based operational reporting is already embedded and relied on in business processes, then do not rebuild it in the DW; blend the two environments instead of duplicating vendor-maintained reporting.
• If there is no overarching information architecture, then a project-by-project BI approach will produce silos that thwart analytics — build the architecture first, before product selection.
• If the solution falls short, is late, or over budget, then diagnose the missing information architecture before blaming the products, or you enter the never-ending 'Twilight Zone' loop.
• If you leave application and DW BI as separate silos, then business people will see inconsistent information and must know which to use when — blend them to protect both IT and business productivity.

• Skipping reverse engineering because IT finds it tedious — the tell is business users hitting missing business rules and data the moment they start using the solution, then reverting to their shadow system.
• Letting product evaluation and selection dominate initial planning while information architecture gets shortchanged — the tell is repeated product-blaming and re-selection with no improvement in adoption.
• Delegating BI tool selection and application development to departmental groups even after achieving the 5C's — the tell is multiple BI silos with redundant, inconsistent reporting.
• Duplicating working, embedded application reporting inside the DW — the tell is an expensive replacement project that drains resources IT could have spent expanding overall BI capability, plus an ongoing drain to keep matching what the vendor already maintains.
• Leaving application-specific and DW BI environments in separate silos — the tell is business consumers getting different, inconsistent numbers and not knowing which environment to trust.

• ▸Data shadow system in scope: name the spreadsheet/shadow system being replaced.
• ▸Power user owner: who created or maintains it and will do the reverse engineering.
• ▸Hidden business rules & data recovered: list rules/data the requirements-giver forgot or assumed.
• ▸Requirement categories captured: check business, data, functional, regulatory, technical, existing reporting.
• ▸Cross-reference tags: business value / business process / business group / data source / analytical functionality.
• ▸Overlaps, conflicts, gaps found in consolidation: list what the consolidation exposed.
• ▸Existing app reporting to keep (not rebuild): identify embedded, working reports to leave in place.
• ▸Blended architecture sources: list applications, DWs, data marts, cubes, spreadsheets to include.
• ▸Power-user sign-off status: recorded blessing that confirms adoption readiness.

1. 1Replace prose requirements documents with visual artifacts: build storyboards, BI mock-ups, and prototype BI objects, then walk the business through them to gather, validate, and document functional requirements. Visual techniques communicate and establish joint expectations far better than dozens of pages of text.
2. 2During data requirements gathering, run data profiling and show output from BI, ETL, and data modeling tools directly with BI developers so business people see the actual state of their data, not an abstraction.
3. 3Set up every deliverable list (BI content specifications, BI applications list) on a shared collaboration tool so team members can solicit feedback, track revisions, and co-edit — use file sharing with revisions turned on at minimum, a project-oriented collaboration tool at best.
4. 4Schedule deliverable reviews as recurring joint events: technical reviews inside the BI team on data models and applications, and stakeholder reviews on requirements, testing, user feedback, and project status. Where co-location is impossible, use collaboration tools with remote application access, desktop display, and audio/video conferencing — there is no excuse for excluding the right stakeholders.
5. 5Close the requirements phase with the business sponsor(s) and key stakeholders signing off on the requirements documentation, which sets expectations and establishes a baseline to manage the project against.
6. 6Assign roles by strength: give BI and analytics to the analytical elites (analysts with business knowledge and analytical expertise) and have IT concentrate on data integration and delivery of cleansed, consistent, self-service data.
7. 7Choose a data integration tool that supports a program rather than tactical projects, because reuse of data definitions/transformations and developer collaboration is what lets you add people to projects and keeps knowledge out of a single programmer's proprietary custom code.
8. 8Anchor collaboration in data governance: obtain business ownership of data definitions and transformations, and pick a data integration tool that implements those definitions so governance does not become a paper exercise ignored by the actual processes.

A BI team faces analytical elites who built their own data shadow systems because IT either could not deliver the data they needed or could not deliver it fast enough. Rather than trying to shut the shadow systems down, the team splits accountability: IT's charter becomes providing cleansed, consistent, self-service data to feed the analysts, while the analysts keep ownership of the modeling and BI work. When a data scientist protests that they need raw, dirty, inconsistent data to build a model, IT does not force it through the standard cleansing pipeline — it trusts that the data scientist's techniques account for the data's shortcomings and often pull from many sources for accuracy. The two ingredients for success are named explicitly: an analyst with business knowledge and analytical expertise, and IT that can enable the self-service data. This partnership stops the shadow-system arms race and turns a turf conflict into a division of labor with shared outcomes.

• If you are about to write dozens of pages of requirements prose, then stop and build storyboards, mock-ups, or a prototype instead — they establish joint expectations more effectively.
• If a phase involving requirements is ending, then require business sponsor and key stakeholder sign-off before proceeding to data modeling, data integration, or BI development.
• If a stakeholder cannot be in the room, then use collaboration tools for remote access and conferencing rather than proceeding without them.
• If a data scientist asks for raw data that is dirty or incomplete, then provide it and trust their modeling handles the shortcomings — do not force it through the standard cleansing meant for typical BI.
• If you are picking a data integration tool, then favor one supporting a multi-project program so reuse and collaboration improve data consistency and reduce data silos.

• Falling into the technology trap — treating BI as a tooling problem while ignoring the business-IT relationship, roles, and politics; the tell is a fully specified architecture with no named business owners for data definitions.
• Trying to replace data shadow systems by decree instead of dividing work between analytical elites and IT; the tell is the elites quietly rebuilding shadow BI and data integration because IT was too slow.
• Communicating requirements through long prose documents; the tell is stakeholders signing off without truly understanding what they approved, then rejecting the delivered BI.
• Building deliverable lists in a private spreadsheet with no sharing or revision tracking; the tell is conflicting versions and stakeholders unaware of scope changes.
• Choosing a data integration tool for a single tactical project so knowledge stays locked in one programmer's proprietary custom code; the tell is being unable to add people to a project or reuse transformations across projects.
• Letting governance become a paper exercise — documenting data definitions and transformations that the integration processes never actually implement; the tell is business-owned definitions that don't match what the ETL produces.

• ▸Business process / analytic in scope: name the process and the analysis it supports
• ▸Visual artifact used: storyboard / mock-up / prototype — attach reference
• ▸Data profiling findings shared with developers: summarize state of source data
• ▸Roles split: name the analytical owner (business) and the data delivery owner (IT)
• ▸Collaboration tool and access: where the artifact and lists live, who can edit/review
• ▸Governance owner of definitions: business person accountable for data definitions/transformations
• ▸Open issues / dirty-data exceptions: list raw-data needs for data scientists
• ▸Business sponsor sign-off: name, date, and baselined deliverables list

1. 1Start justification before scope: build both the business case and the technical case, because approval depends on tying BI spend to tangible benefits (revenue optimization, cost reduction, risk reduction, improved decision-making) rather than to technology features.
2. 2Assess readiness and translate each business goal into a specific actionable-information deliverable — the report, dashboard, or predictive model a business person consumes to make a decision — so the value is a decision changed, not a database granted.
3. 3Scope narrowly and deliver incrementally: reject the enterprise-wide 'big bang' approach. Limit initial scope to a business group's highest-value question so you finish and show return before requirements go stale.
4. 4Cost the whole path from data integration through analytics. Since the bulk of BI work lies in data integration (locating, cleaning, conforming data into the information backbone), price that effort into ROI — value does not appear until data is clean, consistent, current, and comprehensive.
5. 5Evaluate build-vs-buy on total cost of ownership: an integrated BI suite can lower TCO versus a 'roll your own' stack where you pick each component separately; weigh this against risk of imperfect vendor-suite integration.
6. 6Attach analytical governance so BI deliverables produce consistent information; inconsistent numbers across reports, dashboards, and self-service outputs destroy the credibility that value depends on.
7. 7Measure the delivered outcome against the justified benefit after go-live — did the decision improve, did the cost drop, did the risk fall — and feed misses back into scope, because BI failures come from missed expectations, not technology.

A credit-lending group wants to reduce loss from bad loans (risk reduction). Rather than a multi-year enterprise CDW, you scope a single data mart for the lending group and stand up a predictive-analytics model that determines credit scores from customer credit history and other data. The bulk of the effort is data integration: extracting, transforming, and loading history the transactional systems did not retain, then conforming it into a clean, consistent information backbone. The business case ties the spend to fewer defaults and better underwriting decisions; the technical case shows the ETL and OLAP capacity needed. Because scope is limited to one group, you finish and demonstrate return instead of fizzling out like the 1990s big-bang CDW projects. The tradeoff you accept and manage is a potential data silo — you apply analytical governance so the credit scores are consistent with enterprise definitions.

• If the business case cannot name a tangible benefit (revenue, cost, risk, decision quality), then do not fund the project — technology features alone are the technology trap.
• If scope is enterprise-wide and requirements will take months to gather, then narrow it to one business group so the project finishes before the business changes and invalidates the requirements.
• If data is not yet clean, consistent, conformed, current, and comprehensive, then no BI access delivers value — invest in data integration first.
• If evaluating products, then compare TCO of an integrated suite against a component-by-component build, and pick based on your actual requirements (data, analysis type, consumer skill diversity, BI styles needed), not vendor hype.
• If a deliverable lacks analytical governance, then treat its reported value as unreliable until governance makes the numbers consistent.

• Confusing data capture with value: the tell is a big data-collection effort with no one able to analyze it or act on current information — data has no value until you understand, analyze, and act.
• Big-bang scope: the tell is months/years to deliver, budget overruns, and requirements going stale mid-project before anything ships.
• Falling into the technology trap — buying tools to fix a business/organizational problem; the tell is inflated expectations followed by project failure blamed on technology when the real cause is missed expectations.
• Under-budgeting data integration: the tell is a slick front-end demo sitting on unconformed, inconsistent data, producing conflicting numbers that erode trust.
• Skipping analytical governance while enabling self-service and data shadow systems: the tell is multiple versions of the same metric across reports, dashboards, and spreadsheets, so decisions rest on numbers no one trusts.

• ▸Business goal: the decision or outcome BI must improve, in one sentence
• ▸Benefit type: revenue optimization / cost reduction / risk reduction / improved decision-making
• ▸Actionable-information deliverable: the report, dashboard, or model a business person will consume
• ▸Scope boundary: single business group and the one highest-value question addressed first
• ▸Data integration effort: sources, cleansing/conforming work, and historical load needed
• ▸Cost & TCO basis: integrated-suite vs component build, with the chosen option and why
• ▸Governance plan: how consistency of the delivered numbers is enforced (analytical governance)
• ▸Success metric: the measurable post-go-live change proving the benefit was realized

1. 1Start by justifying the project before building: determine the business and technical need, identify benefits, and set explicit expectations—these expectations become the yardstick for success, not just on-time/on-budget delivery.
2. 2Identify risks and assess organizational readiness during justification, because unrealistic expectations set here are what later get scored as 'failure' regardless of technical quality.
3. 3Scope the project incrementally rather than as a 'big bang'—the CDW history shows enterprise-wide scope guarantees late delivery, budget overrun, and requirements that go stale before completion.
4. 4Document requirements (business, data, quality) as the foundation the development team designs, develops, and deploys against; treat requirements gathering as a people-oriented process built on interviews, not a form-filling exercise.
5. 5Involve both business and IT throughout the entire lifecycle—reject the simplistic 'business are customers, IT delivers' model, since success depends on business people participating in every phase.
6. 6Build data integration holistically, incrementally, and iteratively (the bulk of BI work lives in DI), and use prototyping and testing to validate before full load.
7. 7Establish report/analytical governance so BI deliverables produce consistent information the business can actually make decisions on—inconsistency undermines perceived success even with working systems.
8. 8Manage expectations continuously against the changing business; re-check requirements as conditions shift so you don't deliver against a target that no longer exists.

The classic failure is the early Corporate Data Warehouse (CDW). Teams attempted to gather all requirements and implement an entire enterprise-wide warehouse in one 'big bang' project. With enterprise-wide scope, the project consumed many resources, ran late, and exceeded budget. Worse, while the lengthy project was under way, the business changed after requirements were documented—invalidating many of those requirements. Even the CDW projects that were completed tended to under-deliver on expectations, and many simply fizzled out. The lesson: success is not defined by finishing; it is defined by delivering on time, within budget, with quality, and meeting expectations—which the big-bang scope structurally prevented. The fix is incremental, iterative delivery with expectations set and re-checked as the business evolves.

• If the project scope is enterprise-wide and 'all at once,' then break it into incremental, iterative deliveries—big-bang scope is destined to be late and over budget.
• If expectations were never explicitly set during justification, then stop and set them, because success is measured against stakeholder expectations more than any other criterion.
• If requirements were documented long ago and the business has since changed, then revalidate them before building—stale requirements produce technically correct but useless deliverables.
• If someone is treating BI as purely a technology problem, then re-engage the business, because BI projects are about people as much as technology.
• If a vendor or stakeholder promises a 'silver bullet' shortcut, then treat it as a warning sign and check it against the disciplined path before it trips up the project.

• Defining success only as on-time/on-budget while ignoring expectations—the tell: stakeholders are dissatisfied even though the system technically works.
• Big-bang enterprise scope—the tell: the timeline stretches into months or years, resources balloon, and requirements go stale before delivery.
• Treating business people as passive customers rather than participants—the tell: IT 'delivers' something the business never truly owned or uses.
• Skipping the justification/expectation-setting phase and diving into build—the tell: no agreed definition of benefits, ROI, or success criteria exists.
• Skimping on data integration and governance—the tell: inconsistent, incomplete, error-riddled information reaches decision-makers, eroding trust in the whole BI environment.

• ▸Business need: state the specific problem and why BI (not an operational workaround) is required.
• ▸Benefits & ROI: quantify the expected outcomes used to justify the project.
• ▸Stakeholder expectations: list explicit, agreed criteria beyond time/budget that define success.
• ▸Scope & increment plan: define the incremental deliverables that avoid a big-bang approach.
• ▸Risks & readiness: rate organizational readiness and top risks that could shift expectations.
• ▸Business/IT roles: name who from both sides participates in each phase.
• ▸Requirements validation date: schedule when documented requirements will be re-checked against business change.
• ▸Quality & governance standard: define the report/analytical governance ensuring consistent information.

1. 1Quantify the current split of business people's time between data gathering/reconciliation and actual analysis; establish this baseline in the business benefits matrix (Figure 2.1) so productivity shifts become measurable.
2. 2Map IT's current time allocation between maintaining existing BI/data shadow systems and expanding BI value; treat the maintenance burden as the cost you are trying to reduce.
3. 3Build the technical case as a comparison of alternatives, not a feature comparison: pit the BI solution against what business people are inclined to use anyway (expanded operational reporting, spreadsheets, more data shadow systems) across functional, productivity, and long-term cost dimensions.
4. 4Run product evaluations that include the actual daily users, not only power users and architects, because their faster learning masks the adoption friction that stalls productivity gains.
5. 5Sell technologists on 'what's in it for me' — frame new tools as making them more marketable and more valuable, and provide training on BI concepts/processes/architectures, not just product training, so they stop building solutions 'the old way.'
6. 6Secure a powerful sponsor who frees people's time from other tasks so both business and IT can actually commit to the shift rather than defaulting to old habits.
7. 7Assess readiness across data, expertise/experience, analytical commitment, organizational/cultural change, and financial commitment; identify the gap between current state and what success requires, and plan how to bridge it.

The classic anti-pattern the passages describe is the 1990s CDW: IT tried to gather all requirements and build the entire enterprise data warehouse in one 'big bang' waterfall project. Everything was manually coded, the projects ran months to years, went late and over budget, and while they dragged on the business changed and invalidated the documented requirements. Meanwhile business people kept doing reporting in spreadsheets and building data shadow systems because those were cheaper and faster in the short term. The data mart backlash sped delivery by limiting scope to a single business group, but sacrificed consistent data definitions and guaranteed data silos. The productivity lesson: when IT stays trapped in maintenance and 'big bang' delivery, and business stays trapped in shadow systems, neither party moves toward analysis or expanded value. Escaping requires tightly coupling the business case (tangible benefits from freed analysis time) with the technical case (why BI beats the 'good enough' spreadsheet/shadow alternatives over the medium and long term).

• If the business can meet a goal with expanded operational reporting or spreadsheets more cheaply and quickly, then your technical case must prove the BI solution wins on medium- and long-term cost and agility — not on features.
• If only power users and architects test a candidate tool, then discount their positive verdict, because ordinary users' inability to adapt to the interface is a common reason BI projects flounder.
• If technologists have product training but no training on BI concepts, processes, and architectures, then expect them to rebuild solutions the old way and stall the maintenance-to-value shift.
• If you cannot secure a sponsor who frees people's time, then assume commitment will collapse back to old habits and do not proceed on flawed expectations.
• If your readiness assessment shows a gap in analytical commitment or cultural change, then your justification and project plan must explicitly fund bridging that gap before promising productivity outcomes.

• Treating the technical case as a tool feature bake-off instead of a comparison against the 'inferior' alternatives business people will actually use — the tell: no line item for spreadsheets or data shadow systems in your comparison.
• Letting only power users and architects evaluate tools; the tell is glowing evaluation scores followed by low adoption because everyday business users can't get used to the interface.
• Ignoring the technologists' 'what's in it for me' — the tell is developers quietly saying they 'could do things faster the old way' and reverting to manual coding.
• Selling productivity gains while leaving IT buried in maintenance and shadow-system support — the tell is medium-term IT support costs rising even as the BI solution goes live.
• 'Big bang' scope where you try to gather all requirements at once — the tell is a multi-month/year timeline during which business needs change and invalidate the requirements you documented.

• ▸Current business time split — estimate % spent gathering/reconciling data vs. analyzing it.
• ▸Current IT time split — estimate % spent maintaining BI/shadow systems vs. expanding BI value.
• ▸Target shift — the % of time you intend to move on each side and by when.
• ▸Alternative-of-choice — name the 'good enough' option (operational reporting, spreadsheets, shadow systems) the business would otherwise use.
• ▸Comparison across horizons — for each alternative, note short/medium/long-term cost, agility, and support burden vs. the BI solution.
• ▸Real-user tester list — name the everyday business analysts and developers (not just power users) included in the proof of concept.
• ▸Technologist incentive — state what each key technologist gains (marketable skills, expert status) from adopting the new tools.
• ▸Readiness gaps — score data, expertise, analytical commitment, cultural change, and financial commitment; note the gap and bridge action.
• ▸Sponsor commitment — name the sponsor and the specific tasks they will free up so people can commit time.

1. 1Sequence the work correctly: justify the program, define business/data/quality requirements, then build the architectural framework — before selecting any product or vendor. Do not let a product decision drive the architecture.
2. 2Design all four layers of the framework explicitly: information architecture (how data integrates and flows, DIF, operational vs analytical BI, MDM), data architecture (data modeling and integration choices, EDW, ODS), technology architecture, and product architecture. Document each as a deliverable, not an afterthought.
3. 3In the information architecture layer, define the Data Integration Framework and decide where master data management applies (customers, products, suppliers, employees, accounts and their hierarchies) so you get a consistent master list before silos form.
4. 4In the data architecture layer, choose your integration pattern deliberately — favor hub-and-spoke with a physical DW (data hub) feeding data marts over a virtual/conformed-only bus, because the virtual hub is simple to draw but hard to achieve in real-world timing and data-quality conditions.
5. 5Defer product and vendor names to the end: run product and technology evaluations only after the technology architecture is set, following an 'evolution not revolution' approach that reuses existing components where sensible.
6. 6Enforce the Five Cs (clean, consistent, conformed, current, comprehensive) as architectural requirements — build profiling, cleansing, and conformed shareable dimensions into the design rather than bolting them on later.
7. 7Time-box the architecture effort: 'do not obsess over the architecture.' Produce enough blueprint to avoid accidents, then move into design and build; treat the framework as a living plan governed through project management and centers of excellence.
8. 8Make migration of legacy reporting and data shadow systems an explicit deliverable of BI projects so accidental architecture is retired instead of accumulating alongside the planned one.

Consider the Kimball-vs-Inmon (CIF) decision point the book describes. Two competing architectural approaches emerged as an answer to the data mart problem: a data bus with conformed data marts (no DW required, an intellectually appealing 'single version of the truth') versus a hub-and-spoke with a physical DW feeding data marts. Disciplined teams recognized the stumbling blocks with the pure conformed-bus approach: only a small percentage of companies had the discipline to build the required real-time data integration, ETL tools couldn't handle the needed complexity, and transactional data was often out of sync with its reference data, breaking on-the-fly validation. Architecturally disciplined enterprises chose hub-and-spoke, building a physical data hub while borrowing the conformed-dimension modeling and integration techniques from the bus approach. The tell of missing discipline is right there in the passage: even after adopting hub-and-spoke, companies had already built countless ODS systems, DWs, marts, OLAP cubes and shadow systems, and 'the data silo genie was already out of the bottle' — they lacked time or resources to bring them into the hub. Architectural discipline is choosing the physical hub early and consolidating, not drawing the virtual hub and letting silos multiply.

• If a product or vendor is being selected before the four-layer framework exists, then stop — architecture drives product choice, not the reverse.
• If your integration pattern relies on a virtual hub with on-the-fly conformance, then verify your team has the discipline and that reference/transactional timing aligns; if not, build a physical hub-and-spoke DW instead.
• If data fails any of the Five Cs, then treat profiling/cleansing/conformance as blocking architectural requirements before delivering information to business users.
• If the architecture effort is expanding indefinitely, then invoke 'do not obsess' — ship a sufficient blueprint and move to design, since people/process/governance are the hard part, not the technology.
• If shadow systems or legacy reports exist, then include their triage and migration in the BI project deliverables rather than letting them persist as accidental architecture.

• Accidental architecture: products are bought piecemeal and stitched together, producing silos that 'end up producing more harm than good when examined from an enterprise perspective.' Tell: no documented information/data/technology/product layers exist.
• Choosing the intellectually appealing virtual/conformed-bus hub without the discipline to implement it. Tell: real-time DI that overwhelms ETL tools and reference data out of sync with transactions.
• Silo proliferation ignored: adopting a unifying pattern late while never consolidating existing ODS, marts, cubes, and shadow systems. Tell: 'the data silo genie was already out of the bottle.'
• Treating technology as the hard part. Tell: heavy focus on tools while people, process, and governance are neglected — the book warns these are where programs actually fail (the Technology Trap).
• Over-engineering the framework. Tell: the architecture phase never ends and no data design or delivery begins, violating 'do not obsess over the architecture.'

• ▸Information architecture: describe the Data Integration Framework and operational-vs-analytical BI scope for this program.
• ▸MDM scope: list which master entities and hierarchies (customers, products, suppliers, employees, accounts) will be mastered.
• ▸Data architecture: state chosen pattern (hub-and-spoke physical DW / conformed bus / ODS) and justification.
• ▸Data integration workflow: outline extract-transform-load flow from sources to hub to marts.
• ▸Five Cs assessment: rate current data on clean, consistent, conformed, current, comprehensive and note remediation.
• ▸Technology architecture: list required capabilities (not products) per layer.
• ▸Product/vendor evaluation: confirm this is completed AFTER the layers above; record 'evolution not revolution' reuse decisions.
• ▸Silo/shadow-system inventory: list existing DWs, marts, cubes, ODS, shadow systems and migration disposition.
• ▸Scope guardrail: note the 'good enough' cutoff so the architecture phase does not over-extend.

1. 1Treat data integration as the largest share of BI work and engineer it holistically: define data integration architecture, requirements, design, and standards before writing transforms (Chapter 11 sequence).
2. 2Choose tool-based integration over manual coding as the default; reserve hand-coded transforms only where the tool cannot express the logic, because manual coding is not reusable, not visible, and often undocumented.
3. 3Shift every transformation as far upstream as it makes sense — from BI to data franchising to data preparation — so the same transform is done once and used many times, increasing reusability, consistency, and efficiency.
4. 4Capture metadata for every transformation so you can trace data flow from source to analysis; make transforms shared, reusable, and documented rather than living inside a single developer's code or a spreadsheet macro.
5. 5Stand up process management services as the command-and-control center: job control to manage workflow, dependencies, and interactions; audit to record processing metadata; error handling to process errors by predefined rules.
6. 6Configure audit services to track data integration jobs, table and row updates, and data quality metrics across all tables and columns in the BI data architecture.
7. 7Implement the three data quality services — conformance (build conformed dimensions like a single customer or product list), consistency (standardize measures across variant fact-table measures), and cleansing — and profile data first to size the nonconformance before designing each service.
8. 8Get a responsible business person to sign off on business rules and data definitions as part of business and data requirements, and manage the effort with iterative phases and a change-control process to contain scope creep.

A conformed customer dimension shows the discipline. You have multiple source systems each holding their own customer record. Rather than hand-coding a one-off extract per report, you first run data profiling to determine the extent of nonconformance against the agreed business rules, then define the conformance rules with business people during design. You build a single conforming job that produces one customer list, do that transformation once upstream, and let every downstream BI application reuse it. The job runs under job control with its dependencies managed, the audit subservice records the row updates and data quality metrics, and the error handling subservice processes any records that fail the business-rule checks. Because the transform carries metadata, an analyst can trace any customer figure from the source of record back through the conforming job — no black hole.

• If a transform will be needed by more than one report or process, then build it once upstream as a shared reusable component instead of coding it per consumer.
• If you are tempted to hand-code a transform, then first confirm the tool cannot do it; manual coding forfeits reusability, visibility, and documentation.
• If multiple sources feed one dimension, then build a conformed dimension; if multiple variations of a measure exist, then enforce data consistency with standard measures — profile first in both cases.
• If a data quality check involves business rules, then require sign-off from a responsible business person before it is implemented.
• If off-the-shelf cleansing tools (parsing, matching, enrichment, survivorship, householding) are being considered, then justify the expense against the use case — typically only the largest firms warrant them.

• Relying on extensive manual coding for transforms — the tell: only the developer knows what happens to the data, there is no metadata trail, and costs of development rise (the black hole).
• Transforming data late, inside the BI layer, instead of upstream — the tell: the same logic is re-implemented in multiple applications and figures don't reconcile.
• Data shadow systems where transformation lives in spreadsheet macros no one else understands — the tell: almost no documentation exists and only the owner knows the logic.
• Skipping data profiling before designing conformance/consistency services — the tell: you discover the true extent of nonconformance during load, not design, and rework the rules.
• Assuming expensive tools are always required for command-and-control — the tell: you overspend when some economical tools already have robust job-control, audit, and error-handling capabilities.

• ▸Transform name/ID: label the reusable component, not the consuming report.
• ▸Upstream placement: state where it runs (data preparation / franchising / BI) and why it can't move further up.
• ▸Reuse map: list every downstream consumer of this transform.
• ▸Tool vs. manual: mark tool-based; if manual, record justification and reviewer.
• ▸Metadata/lineage: confirm source-to-analysis trace is captured.
• ▸Data quality service: tag as conformance, consistency, or cleansing, with profiling result attached.
• ▸Business sign-off: name the responsible business person who approved the rule/definition.
• ▸Process management: note job control dependencies, audit records, and error-handling rule.
• ▸Change log: record any change, its plan impact, and the adjusted baseline.

1. 1Build models across three levels before physical design: conceptual (business entities and relationships), logical (attributes, keys, cardinality), and physical (the implemented dimensional schema). Do not skip to physical.
2. 2Choose the schema per subject area: use a star schema (facts surrounded by denormalized dimensions) for user access and reporting; snowflake only where a dimension must be normalized; and the hybrid dimensional-normalized model where you need both an integrated normalized backbone and dimensional access layers.
3. 3Model fact tables around business events: identify the grain first, then the measures (facts), then the foreign keys to dimensions. Distinguish event fact tables from consolidated fact tables and keep degenerate dimensions (like transaction numbers) in the fact row rather than spinning up a dimension.
4. 4Design each dimension with its attributes and hierarchies (for drill paths), assigning surrogate keys rather than reusing source system natural keys so you control identity across systems and over time.
5. 5Apply slowly changing dimension handling deliberately per attribute: decide which attributes overwrite (Type 1) and which preserve history (Type 2) so analytics reflect the correct point-in-time attribute values; treat SCD processing as a data ingestion service in the DI tool alongside change data capture and reference look-ups.
6. 6Achieve consistency through conformed dimensions: define shared dimensions (customer, product, date) once and reuse them across fact tables and subject areas so cross-process analysis aligns.
7. 7Handle the advanced cases explicitly — role-playing dimensions (one date dimension used as order date, ship date), junk dimensions for low-cardinality flags, multivalued dimensions, causal dimensions, outrigger tables, value-band reporting, heterogeneous products, and hot-swappable/alternate dimensions — rather than forcing every attribute into a flat table.
8. 8Validate the design against requirements and normalization principles from the ER side, then test the loaded model with prototyping before it feeds BI applications.

Consider a sales BI subject area described by the source material's structure. You start conceptual: business people measure sales events by product, customer, and date. At the logical level you define a sales fact table at the grain of one row per order line, with measures (quantity, amount) and foreign keys to Product, Customer, and Date dimensions; the order number stays in the fact row as a degenerate dimension. Date is modeled once and role-plays as both order date and ship date. Because customer address changes over time, you apply Type 2 slowly changing dimension handling on the Customer dimension using surrogate keys so historical orders keep the address that was valid when the order occurred, processed via the DI tool's SCD ingestion service. Product and Date are built as conformed dimensions so they can be reused by an inventory fact table later, enabling consistent cross-process reporting. Low-cardinality order flags are collapsed into a junk dimension rather than bloating the fact table with separate keys.

• If the data is intended for user access, analysis, and reporting, then use dimensional modeling (star-oriented), because it is better suited to BI than ER/normalized design.
• If you need both an integrated, validated normalized store and dimensional access for analytics, then adopt the hybrid dimensional-normalized model rather than choosing one exclusively.
• If an attribute's history matters for analysis, then use Type 2 slowly changing dimension handling with surrogate keys; if only the current value matters, then overwrite (Type 1).
• If a dimension will be shared across multiple fact tables or subject areas, then define it once as a conformed dimension instead of rebuilding it per fact.
• If you find several low-cardinality flags or indicators, then combine them into a junk dimension rather than creating one dimension per flag or leaving them in the fact table.

• Reusing source system natural keys instead of surrogate keys — the tell is that SCD history breaks or keys collide when source systems change or merge.
• Skipping conformed dimensions so each fact table has its own customer or product table — the tell is inconsistent data and cross-report numbers that do not reconcile across the enterprise.
• Modeling everything ER-normalized for a reporting layer — the tell is complex multi-join queries and business users who cannot navigate or analyze the data.
• Ignoring grain when building fact tables — the tell is double-counted measures and facts that mix event and consolidated levels in one table.
• Not deciding SCD strategy per attribute — the tell is that historical analysis silently uses current attribute values, producing wrong point-in-time results.

• ▸Subject area / business event: name the process being modeled
• ▸Fact grain: one sentence defining what one fact row represents
• ▸Measures (facts): list each numeric measure and its type (event vs consolidated)
• ▸Dimensions & keys: list each dimension, its surrogate key, and natural key source
• ▸Conformed dimensions: mark which dimensions are shared across subject areas
• ▸SCD strategy per attribute: label each changing attribute Type 1 (overwrite) or Type 2 (history)
• ▸Hierarchies & role-playing: note drill paths and any dimension reused in multiple roles
• ▸Advanced structures: flag junk, multivalued, causal, outrigger, or alternate dimensions used
• ▸Schema choice: star, snowflake, or hybrid dimensional-normalized, with reason

1. 1Decide tool-based versus manual coding for data integration before you build: the source states DI is where the bulk of the work in a BI project lies, so default to a DI tool rather than hand-coding to gain productivity, governance, and reuse.
2. 2Select the best-fit DI tool against three explicit criteria named in the source: your needs, your team's skills, and your budget — not vendor hype about the 'best' product.
3. 3Map required tool services to your project. From the passage, verify the tool covers: access and delivery, data profiling, data transformation, data quality, process management, operations management, and data transport, plus data ingestion services (change data capture, slowly changing dimensions, reference look-ups).
4. 4Establish an information and data architecture BEFORE product evaluation, so tool selection serves the architecture instead of substituting for it — this is what breaks the 'Twilight Zone' loop.
5. 5Set and apply DI standards, since the source names standards as essential to successful DI; document the process model and design specifications for each stage.
6. 6Prototype and test the tool-based DI against real requirements, including a plan for loading historical data (called out as a specific watch-out).
7. 7Keep tool selection governed at the enterprise level; the passage warns that delegating BI application development and tool selection to departmental groups reproduces silos even after a hub-and-spoke is built.

The passages describe the hub-and-spoke evolution as a concrete case of tool-and-architecture fit. Early ETL tools could not handle real-time DI, and the timing of transactional data and its associated reference data were often out of sync, which prevented on-the-fly validation and integration across multiple source systems and data marts. Rather than chasing a virtual hub that was 'simple to draw but difficult to achieve,' companies moved to hub-and-spoke, building a physical data warehouse (data hub) and borrowing the conformed dimension modeling and integration techniques. This tool-and-architecture combination enables the 5C's of information: consistent, clean, comprehensive, conformed, and current. The lesson is that the win came from fitting integration technique to a real architecture, not from re-picking a 'best' tool. Where enterprises instead delegated tool selection to departmental groups, silos returned. That is tool adoption governed by architecture versus tool adoption left to ad hoc departmental choice.

• If DI logic would otherwise be hand-coded, then default to a DI tool — the source explicitly recommends tool-based DI over hand-coding for the bulk of project work.
• If a candidate tool lacks any of the named services (profiling, transformation, quality, process/operations management, transport, CDC, SCD, reference look-ups), then it is not best-fit for a full DI workload.
• If product evaluation is starting before an information architecture exists, then stop — you are entering the never-ending 'Twilight Zone' trap.
• If a departmental group wants to pick its own BI/DI tools, then route selection through enterprise governance, because delegated selection recreates silos.
• If real-time integration is required and reference data updates lag transactions, then favor a physical hub (hub-and-spoke) over a virtual hub.

• Treating tool selection as the whole solution — the tell is blaming products when a project is late or fails adoption, then repeating step 2 (implement without architecture) with a new 'best' product.
• Skipping information architecture because power users only see the BI tools, not the underlying architecture — the tell is that architectural design gets shortchanged during initial planning.
• Delegating BI/DI tool choice to departments — the tell is proliferating ODS systems, DWs, data marts, OLAP cubes, and data shadow systems that never join the hub.
• Choosing a tool without standards or stage-level design specs — the tell is inconsistent DI processes that fail prototyping and testing.
• Ignoring historical data load requirements during tool evaluation — the tell is the DI process breaking when historical data must be loaded later.

• ▸Need being served: state the DI requirement this tool must satisfy
• ▸Skills match: rate whether current team can operate the tool
• ▸Budget fit: record cost against allocated BI budget
• ▸Service coverage: check profiling, transformation, quality, process mgmt, operations mgmt, transport
• ▸Ingestion coverage: check change data capture, slowly changing dimensions, reference look-ups
• ▸Real-time capability: note whether it supports required timing/latency
• ▸Architecture alignment: confirm an information/data architecture exists that this tool serves
• ▸Governance owner: name the enterprise (not departmental) owner of this selection
• ▸Historical load & test plan: note how historical data loads and prototyping/testing will be validated

1. 1Build both the business case and the technical case before writing any requirements — the business case identifies the need and benefits with sponsors and stakeholders; the technical case establishes feasibility. Do not skip this even when an enthusiastic CIO or executive offers to approve the project without formal justification.
2. 2Assess organizational readiness and identify risks explicitly, because readiness and risk are what determine how realistic your expectations are. Document each risk against the scope it threatens.
3. 3Estimate scope, costs, schedule, and ROI as a package, then create a high-level BI road map that shows incremental delivery rather than a single big-bang outcome. Use the road map as the communication vehicle for staging expectations.
4. 4Document the justification formally and treat it not just as a selling device but as the reference you use to manage scope and change control — every scope change gets measured against what was justified.
5. 5Run requirements definition as a people-oriented process: define roles, follow a defined workflow, and conduct structured interviews with business people as the basis for documented business, data, and quality requirements.
6. 6Document what you are planning to build so the development team can use those requirements to design, develop, and deploy — the written requirements are the foundation, not the conversation.
7. 7Confirm requirements trace back to the business case's stated benefits and to information that is actually available (clean, consistent, conformed, comprehensive), so expectations are anchored to deliverable data, not aspirations.
8. 8Obtain both program and project approval on the documented package so the agreed scope and expectations are on record before development begins.

According to the studies Sherman cites, the majority of BI projects fail — not because of technology shortcomings but from an expectations shortfall, and they tend to run late and over budget when business needs are not clearly established. Picture a team whose sponsor believes the payoff is obvious and pushes to skip justification. The team instead builds a business case with the sponsor and stakeholders, builds the technical case, assesses readiness, and finds several data-quality risks. They stage those findings into a high-level road map with a preliminary plan, budget, and ROI, then document it and obtain approval. When a stakeholder later requests an out-of-scope dashboard, the documented justification lets the team manage the change against the agreed scope rather than absorbing it silently. The result: expectations were set against realistic readiness, and the project is judged against what was actually committed.

• If an executive or CIO offers to approve BI without formal justification, then still build and document the case — approval is not the only reason, since documentation prevents the project from later being labeled a failure.
• If readiness assessment surfaces risks, then reflect them directly in scope, schedule, and expectations rather than promising the ideal outcome.
• If a stakeholder requests a change, then measure it against the documented justification and manage scope/change control from that baseline.
• If requirements cannot be traced to available clean, consistent, conformed data, then flag the expectation as unrealistic before committing to it.
• If benefits presented are only high-level or intangible, then push back and build a concrete business case before proceeding.

• Skipping justification because the payoff seems a 'no-brainer' — the tell is a project approved on high-level, intangible benefits with no written business case.
• Establishing scope on flawed expectations — the tell is a project running late and over budget with disputes about what was supposed to be built.
• Treating justification only as a selling device — the tell is the document is filed after approval and never referenced during change control.
• Underweighting readiness and risk — the tell is expectations that assume ideal conditions the organization cannot actually support.
• Under-investing in the requirements interviews and documentation — the tell is developers designing from memory of conversations rather than documented business, data, and quality requirements, since this is one of the most people-oriented and trickiest processes in a project.

• ▸Business Need & Benefits: state the need and identified benefits agreed with sponsor/stakeholders
• ▸Technical Case: summarize feasibility and technical justification
• ▸Readiness Assessment: rate organizational readiness and note gaps
• ▸Risk Register: list risks and the scope each threatens
• ▸Scope / Plan / Budget: define scope with preliminary plan and budget
• ▸ROI Estimate: cost, schedule, and expected return
• ▸BI Road Map: incremental delivery stages tied to expectations
• ▸Documented Expectations: written statement of what will and will not be built
• ▸Approval Record: program and project sign-off names and date