Enterprise IT projects produce a wide range of outputs from initiation through to implementation. These outputs are referred to as project deliverables. Project deliverables include anything created to support, inform, or validate project execution.

Project deliverables are categorised as either working documents or formal deliverables. Working documents are informal records and analytical tools that provide input, context, or traceability for formal outputs. Formal deliverables are planned outputs that contribute directly to the project’s execution, progress tracking, and final product.

Working Documents

Working documents are informal outputs that support analysis, planning, and communication throughout the project. They are not subject to formal review or approval but provide essential input, traceability, and context for formal deliverables.

Working documents serve several purposes:

• Communication: Ensures alignment among team members, stakeholders, and external contributors.
• Evidence: Documents decision-making and development processes.
• Decision support: Informs decisions through recorded data and analysis.
• Traceability: Supports the creation and refinement of formal deliverables with traceable source information. 

Examples of working documents include:

• Messages: Email or chat messages.
• Conversation records: Logs of communications or interactions.
• Feedback comments: Input received from stakeholders, team members, or contributors.
• Q&A logs: Documentation of questions and answers raised during the project.
• RAID logs: Records of risks, actions, issues, and decisions made throughout the project.
• Meeting minutes: Notes summarising discussions and decisions from meetings.
• References to external or shared files: Links to or records of external resources and documents. 

Although working documents are not approved deliverables, they play a critical role in the project’s internal operations and often form the basis for formal outputs.

Formal Deliverables

Formal deliverables are planned outputs scheduled within the project timeline. These tangible products are created to demonstrate the completion of specific activities or the achievement of milestones. Unlike working documents, they are subject to stakeholder review and approval.

Formal deliverables serve the following purposes:

• Communication: Ensures stakeholders understand project scope, direction, and outcomes.
• Accountability: Assigns clear responsibility for producing, reviewing, and approving deliverables.
• Progress tracking: Provides checkpoints to monitor project development and delivery.
• Service management: Provides reference points for service management when supporting operational continuity. 

Examples of formal deliverables include:

• Plans: Strategic roadmaps outlining how the project will meet its objectives, including activities, resourcing, and timelines.
• Models: Visual or conceptual representations of architecture, processes, or data structures.
• Requirements: Defined functional and non-functional needs within the project scope.
• Specifications: Descriptions of systems, products, or services that include technical and quality standards.
• Flowcharts: Visual process maps used to define and understand workflows.
• Work instructions: Documented task procedures for consistent execution. 

Each deliverable is assigned to a specific role, with responsibilities for its development, review, and approval defined in the project schedule.

The following case study illustrates the consequences of inadequate business analysis, highlighting the difference between supporting documents and formal deliverables.

Background

CoinVault Bank initiates a project to divest its insurance division and focus on core banking services. The project requires precise and complete requirements to support the transfer of customer and operational data to SureShield Insurance, maintain compliance with financial and data protection regulations, decommission redundant systems, and archive legacy data securely at CoinVault Bank.

The bank selects the Waterfall model to deliver this large and complex project. Its upfront requirements definition and phase-based scheduling support the timely delivery of critical data and compliance documentation to SureShield Insurance. This structure allows both organisations to meet strict regulatory deadlines while maintaining continuous insurance services.

CoinVault assigns a team of business analysts with general experience but limited expertise in complex separation projects to define the requirements.

Challenges

The lead business analyst, Bobby Pace, adopts a flawed approach by copying information directly from emails, meeting notes, and verbal communications into the requirements document. This improvised method, termed 'business analysis without analysis’, bypasses critical processes such as evaluation, synthesis, and validation. The practice of copying and pasting information creates several issues.

The lead business analyst, Bobby Pace, adopts a flawed approach by copying information from emails, meeting notes, and verbal discussions directly into the requirements document. This improvised method, referred to here as 'business analysis without analysis', omits essential steps such as evaluation, synthesis, and validation. The copy-and-paste approach introduces several problems:

• Ambiguity in requirements: The requirements lack precise definitions, making it difficult for delivery teams to execute data migration and decommissioning tasks accurately. For example, 60% of the initial requirements, including data mapping rules for customer records, are identified as unclear during the first project review. This delays data transfer activities by two weeks.
• Inconsistencies across sources: Conflicts between email threads, meeting records, and verbal inputs are left unresolved. This results in 15 recorded instances of contradictory data transfer and decommissioning specifications, such as incompatible data formats for policy records.
• Lack of stakeholder validation: The team does not confirm the requirements with stakeholders, creating a misalignment between delivered outputs and operational needs. SureShield Insurance reports that 40% of the data transfers and compliance documents do not meet regulatory or business expectations, including deficiencies in GDPR-compliant archiving protocols.
• Inadequate detail in specifications: The requirements are either overly general or missing essential detail. This leads to assumptions during delivery, especially for archiving and decommissioning activities. As a result, 25% of project tasks require rework to correct misinterpretations. 

Analysis

Bobby’s approach disregards a fundamental principle of business analysis: stakeholder inputs are only a starting point. These inputs require structured analysis to produce usable requirements. According to the International Institute of Business Analysis (IIBA) and the Project Management Institute (PMI), effective requirements development in IT projects includes the following practices:

• Critical evaluation: Analysts review each input for relevance, accuracy, and consistency with project objectives and business needs. Information that does not meet these standards is excluded from the requirements.
• Synthesis and enhancement: Analysts integrate inputs from multiple sources, resolve gaps through consultation or research, and remove ambiguity. For instance, the analyst may consolidate inputs into a standard data transfer and decommissioning specification.
• Standardisation: Requirements are expressed in a consistent format to avoid confusion during development, testing, and handover.
• Validation: The analyst confirms each requirement with relevant stakeholders to verify that it reflects actual business and regulatory needs. 

Corrective Actions

The project team pauses development and revises the requirements using formal analysis practices. The following actions are taken:

• Clarifying ambiguous requirements: Bobby facilitates workshops with stakeholders from CoinVault Bank and SureShield Insurance. These sessions reduce unclear requirements from 60% to under 10% within three weeks. The team documents detailed workflows for customer record transfers and system decommissioning procedures.
• Resolving inconsistencies: The team conducts a requirements traceability analysis. They resolve all 15 identified conflicts by comparing source documents and consulting stakeholders directly.
• Engaging stakeholders for validation: Bobby introduces a formal review cycle, including bi-weekly validation sessions. Stakeholders confirm revised requirements, such as GDPR and FCA compliance documentation, before release.
• Enhancing specification detail: The team adopts a structured template based on ISO/IEC/IEEE 29148 standards. This enables the definition of detailed requirements for data migration, decommissioning, and archiving, including secure data handling protocols. Rework rates fall from 25% to 5% as delivery teams follow clearer guidance. 

These actions restore alignment with accepted business analysis practices and improve the quality of the requirements deliverable.

Conclusion

This case study reinforces a core principle of business analysis: stakeholder inputs are not sufficient on their own. They must be transformed through structured evaluation, synthesis, standardisation, and validation. By correcting the issues introduced through unstructured input handling, the team re-establishes control of the project and supports both CoinVault Bank and SureShield Insurance in meeting their shared objectives.