How Do Deliverables Differ Between a Custom Management Cockpit and Packaged BI Software?

Summary: A packaged BI project typically delivers a software license, installation and configuration, data models, reports, training and support. A custom management cockpit may also require contracted requirements, prototypes, design, API mappings, code or builds, database assets, deployment, tests, permissions, logs and operations documents. Neither project should be accepted merely because “the page opens.”

The practical point: deliverables matter because the buyer can verify what was purchased, how it is deployed, how numbers are calculated, how permissions work, how failures are recovered and who can change it later—not because there are many files. Whether source code is handed over, IP is transferred or third-party components can be redistributed depends on the contract and licenses.

Where Packaged BI and a Custom Cockpit Differ

1. Requirements, Prototypes and Design Assets

A custom project should retain an approved requirements baseline covering at least user roles, pages, metrics, filters, interactions, data sources, permissions, target devices, deployment and acceptance. Prototypes and UI need versions, approval dates and adaptation scope; a few images without interaction states are not enough.

If the design uses fonts, icons, maps, images, models or commercial assets, record their source, license and transferability. State whether editable design source files are included in the contract.

2. Metrics, Data and API Documentation

Every core metric should trace to a business definition, formula, source, version, effective date, owner, lineage and point of use. API documentation should include URL, method, authentication, fields, enums, time format, pagination, error codes, frequency, timeout, retry and examples, plus differences between test and production.

Database scripts should cover not only table creation but indexes, views, initialization, migrations and rollback. For caches, offline synchronization or queues, document consistency, latency and compensation behavior.

3. Source Code, Builds and Third-Party Dependencies

“Custom development” does not automatically transfer all source code, reusable components and IP. The contract should specify:

• Which repositories, branches, tags, commits and builds are delivered.
• Which rights to use, modify, copy, redeploy or relicense the customer receives.
• Whether shared components, existing tools, open-source libraries and commercial SDKs are third-party or pre-existing supplier assets.
• Dependency names, versions, licenses, download sources, vulnerability handling and replacement options.
• Whether the build environment, commands, package sources, signing and release process can be reproduced in the agreed environment.

If the contract only requires a runnable build, provide enough configuration, deployment, monitoring, backup and troubleshooting information so releases do not depend on one developer’s computer.

4. Deployment, Configuration and Environment Inventory

Document OS, database, middleware, runtime, browser, reverse proxy, certificates, ports, domains, storage, network zone, time synchronization and resource requirements. Distinguish development, test, staging and production environments.

Do not place environment variables or secrets in public documents or code repositories. Transfer them through the agreed secure method, recording custodians, permissions, rotation and revocation steps.

5. Permission Matrix, Logs and Security Evidence

A permission list should go beyond “which menus can this role see” to pages, APIs, organizations, rows and columns, sensitive fields, export, sharing, administrative actions and fixed terminals. At acceptance, test both authorized use and denial for unauthorized accounts, cross-organization parameters, direct API calls, disabled accounts and old links.

Define which log events cover login, queries, exports, settings, permission changes, errors and administration; where logs are stored, for how long, who can inspect them and how sensitive information is redacted.

6. Tests, Acceptance and Open Issues

Test reports should map to requirements and versions and cover functionality, data results, APIs, permissions, compatibility, performance, errors, recovery and target devices. User acceptance should retain samples, expected and actual results, evidence locations, severity, owners and retest conclusions, not just a “passed” label.

List open, deferred and known limitations separately with interim handling, impact, plan and launch effect, so spoken commitments remain traceable after handover.

7. Operations, Backup, Recovery and Exit

Launch is not the end of delivery. Define monitored components, alert recipients, first response, escalation, backup scope, recovery steps, certificate renewal, account review, dependency updates and metric-definition changes. Verify at least one representative recovery or rollback, rather than merely checking that a backup job exists.

Agree on transfer of code or builds, data, configuration, accounts, documents, licenses, pending changes and service logs before exit. Revoke departing accounts, VPN access, secrets and temporary permissions against an inventory.

Accept by Milestone, Not Through a Final Document Dump

1. Requirements review: Confirm scope, roles, metrics, APIs, permissions, deployment and acceptance.
2. Design review: Confirm prototypes, UI, data flows, architecture, third-party dependencies and risks.
3. Integration review: Check APIs, metrics, permissions, errors, logs and performance results.
4. Launch review: Check deployment, settings, accounts, monitoring, backups, rollback and security.
5. Final acceptance and handover: Check contracted deliverables, remaining issues, training, maintenance and exit documents.

Each deliverable needs a name, version, owner, location, applicable environment, review state and corresponding acceptance clause. Use the Metric Definition and Data Lineage Acceptance Matrix, Source Code, Deployment and Account Handover Checklist to support these checks.