Category Archives: Delivery Methodology

Articles discussing how best to deliver BI projects

BI Project Responsibility Assignment Matrix (RACI)

A RACI is a matrix that summarises who is responsible for what on a project. It also defines who approves a deliverable, who is involved in the production and who is the target audience of the deliverable.

The matrix is constructed by placing the project roles in columns and the tasks and deliverables in rows and then in the intersect the letters R, A, C and I are used to indicate the involvement of the role on the deliverable.

An important consideration when producing project documentation is to know who the target audience is and therefore who should approve the document. For example, consider a report functional specification produced by a business analyst. The specification should be read, understood and approved by the Business Representative as they need to be sure that the report meets their requirements. In addition it should also be read, understood and approved by the report developer as they need to make sure that the functional specification doesn’t contain any features that cannot be implemented.

Continue reading

This article was published on August 21, 2013 by Al Gulland.

BI Project Roles and Responsibilities

Having worked on and delivered many BI projects I have realised that one of the factors of a successful project is to have clearly defined roles and responsibilities for the project team members. This ensures that everyone knows what they and everyone else is responsible for and are required to do – no more “that’s not my job”.

This article describes a set of key roles for a BI project that is building a data warehouse and providing a set of reports and analytical capabilities to an organisation.

IT Project Team

A typical BI project team, hard at work

Continue reading

This article was published on August 21, 2013 by Al Gulland.

BI Project Deliverables


This article lists some of the deliverables that are produced as part of a BI project. It is not a fully comprehensive list and the descriptions of the deliverables are brief but the aim is to give an overview the main deliverables so that you have a starting point for your BI project.

This article is a companion article to the BI Project Roles and Responsibilities article which defines the roles and responsibilities on a project.

Shelves in a library containing many books

A project can be required to produced a large amount of documentation

Continue reading

This article was published on August 21, 2013 by Al Gulland.

Automated Unit Testing in SAP Data Services. Part I


One of the key drivers of this article is that although there are many articles on unit testing in general on internet there are hardly any on unit testing with SAP DataServices. Unit testing has been accepted as a key part of the software development lifecycle for projects building applications in languages such as Java or C++ however I have rarely come across a SAP DataServices project where unit testing is treated as a fundamental part of the software development life cycle. As a result projects without rigorous unit testing spend longer than planned in system testing, identifying trivial defects, and as a result suffer from delays and cost overruns.

This article first explains what is unit testing and what benefits it brings to a project and then looks at how to implementing automated unit testing in a SAP DataServices project.

Continue reading

This article was published on August 31, 2012 by Al Gulland.

SAP Data Services: 10 Reasons for never using Global Variables (and one where you can)

In software programming it is widely held that using global variables or other constructs to maintain global state is a poor programming practice[1] and many of those reasons can also be applied to development of jobs in SAP Data Services.
The following is my list of 10 reasons for why you should never use global variables,

  1. Tight coupling between separate parts of a Data Services job
  2. Hidden dependencies between separate parts of a job
  3. Lack of isolation for unit testing components of a job
  4. No access control – everything in a job has full access to a global variable
  5. Global variable values can be set at runtime
  6. Lazy reuse of global variables
  7. Global variables depend on the context in which they are being used
  8. Local variables can have same name as global variables
  9. Global variables discourage code reuse
  10. Global variables restrict configuration management

These are further explained below and since I’m a never-say-never type I’ve also included one situation where you can use a global variable.

Continue reading

This article was published on May 25, 2011 by Al Gulland.