Supporting Documents

In enterprise IT projects, the journey from initiation to completion involves various documents, including supporting materials that aid in creating, refining, and validating project deliverables.

Supporting documents are informational materials and analysis tools produced throughout the project phases. They include messages, conversation records, feedback comments, Q&A logs, Risks, Actions, Issues, and Decisions (RAID) logs, meeting minutes, decision registers, and links to electronic files. These documents serve several functions:

• Facilitating communication to ensure alignment among team members, stakeholders, and external parties on specific topics.
• Providing evidence by documenting decision-making and development processes for future reference.
• Informing decision-making with essential data and analysis for presenting options and making informed choices.
• Ensuring project deliverables are based on informed decisions, thorough analysis, and structured planning.

While supporting documents are helpful for internal processes, they are not formal project deliverables that receive endorsement or approval from the relevant stakeholders. The effectiveness of these documents relies on the quality of the information they contain. The following case study illustrates the consequences of inadequate business analysis, highlighting the difference between supporting documents and formal deliverables.

Background

A leading bank is initiating the process of divesting its insurance division in a strategic move to focus on its core offerings. The project's success relies on clear, detailed requirements that govern the operational, financial, and legal frameworks essential for a seamless separation. However, the responsibility is assigned to a team that, while experienced in business analysis, lacks the depth necessary to navigate such complex requirements.

A business analyst, Bobby Pace adopts an efficient approach: copying information directly from emails, meeting notes, and verbal communications into the project's requirements document. This method, termed 'business analysis without analysis,' bypasses the critical processes needed to ensure the requirements are meaningful, actionable, and aligned with the project's objectives.

Outcome

• Ambiguity: The development team struggled to create precise system functionalities due to unclear definitions and expectations stemming from poorly defined requirements.
• Inconsistencies: Contradictions between different sources went unaddressed, leading to conflicting requirements that created confusion within the project team.
• Lack of validation: Requirements were not confirmed with stakeholders, resulting in a disconnect between what was delivered and the actual business needs. 
•  Inadequate specifications: Requirements were either too general or lacked necessary detail, leaving excessive room for interpretation during the development phase, ultimately jeopardising project success.

This direct copying of information and pasting into the requirements document resulted in significant issues:

Analysis

Bobby's method failed to recognise a fundamental principle: the information gathered is a starting point. The role of a business analyst involves transforming these initial findings into coherent and actionable requirements. Practical business analysis involves:

• Critical evaluation: Each piece of information must be assessed for its relevance and impact in addressing the business problem.
• Synthesis and enhancement: Analysts should integrate and enhance information from various sources, supplementing gaps through further research and stakeholder discussions.
• Standardisation: Information must be presented in a clear and actionable format for all project participants, avoiding ambiguity and misinterpretation.
• Validation: Requirements must be confirmed with relevant stakeholders to ensure accuracy and completeness, establishing a foundation for successful project outcomes.

Resolution

Upon recognising the deficiencies in their approach, the project team halted development work to reassess the requirements. With a renewed emphasis on thorough analysis, Bobby re-engaged with stakeholders, conducted elicitation sessions, and collaborated closely with the project team to clarify, refine, and validate the requirements. This process aligned the project with business needs and reinforced the importance of rigorous analysis in defining project deliverables.

Conclusion

This case study illustrates a fundamental principle of business analysis: it involves gathering, transforming, and refining information rather than merely copying and pasting it from one document to another. The distinction between supporting documents and project deliverables is crucial; practical business analysis ensures that deliverables are well-defined, actionable, and aligned with the project's objectives, ultimately contributing to the project's success. By understanding this distinction, organisations can improve their approach to project deliverables and enhance overall project outcomes.

Formal Deliverables

Formal deliverables are tangible products essential for development in enterprise IT projects. They serve three primary purposes:

• Communication: Well-documented deliverables ensure project stakeholders understand the project's scope and expectations.
• Accountability: Each deliverable is tied to specific roles and responsibilities, ensuring that individuals and teams are accountable for their contributions.
• Project success: Deliverables act as milestones for assessing progress.

Examples of formal deliverables are:

• Plans: Strategic roadmaps that outline how the project will meet its objectives, guiding activities, resource allocation, and time management. 
• Models: Visual or theoretical representations, such as architectural blueprints, process models, or data models, to articulate complex systems or processes within the project.
• Requirements: Specifications of the functional and non-functional needs, constrained by the project scope and aligned with business objectives.
• Specifications: Descriptions of systems, products, or services, outlining quality standards and technical details to ensure clarity during development.
• Flowcharts: Visual tools that map out processes or workflows, helping the team understand the sequential steps required to achieve desired outcomes.
• Work instructions: Step-by-step guides that standardise how tasks should be performed, ensuring consistency in execution.

These deliverables shape the development process and are key reference points throughout the project lifecycle, supporting ongoing operations and future project assessments.