Description
8 Ways that Business Intelligence Projects are Different
1 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
8 Ways that Business Intelligence Projects
are Different
And How to Manage BI Projects to Ensure Success
Business Intelligence and Data Warehousing projects have developed
a reputation as being dif?cult, risky and expensive. Although Data
Warehousing has been around for decades, there is still a high failure
rate for BI and DW projects – an oft-quoted ?gure is that at least 50% of
these types of project fail, and many more go over time, over budget, or
don’t deliver the expected bene?ts – or all three.
One cause of these problems is that BI and Data Warehouse projects are often approached like
a typical IT project, whereas in fact a very different approach is needed. This paper will discuss
8 important differences between BI initiatives and other kinds of IT projects. By understand-
ing these differences, it is possible to structure the environment and the project management
methodology so that these differences are taken into account, resulting in a much higher suc-
cess rate and greater business bene?t.
How are Business Intelligence Projects Different?
1. Business Intelligence projects are primarily business projects, not IT projects.
There is a common perception that BI projects are IT projects. While Information Technology
is an important component of BI projects, it is better to treat BI initiatives as business projects
which are enabled using technology.
This is because the business users will ultimately decide the success or failure of the project.
The business therefore needs to take the lead role both in de?ning their information require-
ments and in ensuring that the BI solution built by IT meets these requirements. This is in
contrast to the approach often taken, in which IT determines what it believes to be the user
requirements and delivers to this speci?cation, inviting the business on board in the latter
stages of the project.
To drive the project as a business-led initiative, the business must be engaged to de?ne what
information they need, the format that they need it in, where the most up-to-date and accurate
version of the data is stored, how the data is related (including how it should be summarized
and categorized), when and how often the data needs to be provided, how much history needs
to be catered for, and to whom the data should be made available.
By properly analyzing and documenting the complexity of the business’ information require-
ments, questions will inevitably arise during the design and development process. The IT
developers will need the business to explain the meaning of the data, clarify how they want
the data processed and displayed and de?ne how to handle exceptions. The business subject
matter experts therefore need to allocate a substantial amount of time to help the IT develop-
ers understand the data and help resolve the questions which arise.
continue »
ABOUT ANALYTICS8
Analytics8 is a business intelligence (BI)
and data warehousing enablement and
optimization consulting ?rm. Though
we are experts with many tools and
technologies, we never lose sight of
the business reasons for implementing
technology.
Let us show you how to make the most
of your data.
“...it is better to treat BI
initiatives as business proj-
ects which are enabled
using technology.“
2 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
A signi?cant level of input from the subject matter experts (SMEs) is also required during the
testing phase. This is because the testing needs to be carried out by people with business
experience who know the signi?cance of the data being examined, so that exceptions can be
?agged and ‘?xed’.
Often, the business users and SMEs ?nd that they need so much time for testing that they
need to join the project team full-time during the testing phase. This is a signi?cantly greater
resource commitment, compared to typical IT projects.
The project sponsors need to be aware of the time commitment that will be required of the
information SMEs to make the project a success, and ensure that there is a high level of busi-
ness commitment and ownership before starting the BI initiative.
From a project management perspective, the project plans need to re?ect the level of business
personnel involvement required. The project manager should con?rm that the organization is
willing to release these people to join the project team when their involvement is required, and
that these people have the necessary knowledge and skills to provide the appropriate level of
input to the business analysts and the development team.
2. Intensive IT business analyst support is required throughout the project.
While the business needs to be prepared for a substantial resource commitment, IT also
needs to be aware that a BI initiative will require more dedicated business analyst time, com-
pared to other projects.
This is due to the fact that the requirements will continue to be clari?ed and re?ned during the
development phase. The IT business analyst needs to stay deeply involved in the project to
document (and note the impact of) these re?nements, and help manage the level of change in
the development process.
Compared to other projects, BI projects also involve a signi?cantly greater contribution of
business analyst time during the development and testing phases. Many organizations make
the assumption that business analyst involvement is required mainly during the design phase.
This approach leads to serious under-estimation of the business analysts’ work allocation in the
project schedule for the remainder of the project.
Project managers therefore need to make sure that the business analyst is appropriately al-
located for the duration of the project. The project manager and business analyst will need to
work closely together to manage the scope of work, ensuring that scope creep is managed.
The business analyst will need to document re?nements and clari?cations of the requirements
throughout the project life cycle, together with the reasons and business rules behind these
choices.
3. Requirements for BI projects are impossible to de?ne completely in advance.
It is rare to ?nd a BI project where the users are able to de?ne exactly what information they
want from the solution, in advance. While they will have some initial requirements, the process
of de?ning and thinking about their information needs will prompt new ideas, as they start to
realize how the data warehouse can make new reporting capabilities available to them.
Often these new ideas arise well into the development and even testing phase of the project,
presenting a major challenge to the project manager to balance the evolving business require-
ments with the need to manage scope.
continue »
“...IT needs to be aware that
a BI initiative will require
more dedicated business
analyst time, compared to
other projects.”
3 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
In fact, these additional requirements represent one of the major bene?ts of developing a
data warehouse, as these new insights are often where the greatest potential value of the
project lies. Changes to business requirements should not be viewed negatively, as delivering
enhanced capabilities represents a key objective of the BI project.
Traditional development methodologies, however, tend to focus on controlling and limiting
changes to initial requirements speci?cations. This can be extremely counter-productive in BI
projects, as this approach will limit the usefulness of the BI solution produced.
One way of mitigating this problem is to devote more time than usual to the requirements
gathering and analysis phase, before development begins. This extended scope de?nition
phase will provide a better picture of the ?nal scope of the project, and will allow more time to
get business agreement on the boundaries of what will be included in the scope.
The IT developers also need to adopt a ?exible approach, so that the detailed business require-
ments can be re?ned or clari?ed during the development phase of the project. The project
manager needs to take care, however, that only minor changes are allowed to proceed. As
with other projects, major changes should only proceed after the impact of the change has
been assessed, quanti?ed and agreed with the business sponsor.
4. A different project management approach is necessary.
The above three features of BI projects suggest that traditional software development
methodologies (such as waterfall-based approaches) do not work well in the BI context.
In fact, BI development efforts tend to ?t better into an iterative methodology, where work is
done in cyclical stages. Our experience has shown that agile system development methods
and techniques are very effective in delivering results in BI projects.
An agile approach involves small teams of highly skilled individuals, who work very closely
together. The project includes the business users as integral members of the team, with all
members communicating closely and continuously with each other. In our experience, an
important technique to promote the free ?ow of information and ideas is the co-location of
business SMEs and IT developers.
The agile methodology also emphasises rapid release cycles of small components of the
overall solution. Agile methods therefore do not involve a great deal of requirements speci?ca-
tion up front, but rather a continuous re?nement of the requirements as the system is being
developed, based on feedback from the users of the BI solution.
Scope is managed by applying a ‘timebox’ to each cycle of the project. To do this, the develop-
ers and business SMEs agree on what is achievable in the given time for a particular cycle. All
requirements that can not be completed within this period are deferred until after the current
scope of work has been completed, but are not lost as they become part of a future develop-
ment cycle.
The methods described above are quite different to traditional project management methods.
Most organizations and project managers have only had experience with conventional models,
and most conventional methodologies don’t always align easily with agile methods.
continue »
”...BI development efforts
tend to ?t better into an
iterative methodology,
where work is done in
cyclical stages.“
4 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
Ultimately, agile techniques are not incompatible with more conventional project management
methodologies. The agile development philosophy and emphasis on producing value to the
business is a valuable addition to standard project management tools and techniques in BI
projects.
5. Building the BI solution is just the beginning – extensive testing is needed.
One of the major areas that is frequently under-estimated in data warehousing projects is the
amount of time required for testing and dealing with data ?xes. Most organizations assume that
a report or dashboard is ?nished once the development process is completed. However, once a
report is available for testing, the testing process will often identify errors not in the report itself
but with the underlying data sources.
The project team, including business SMEs, need to examine the contents of the report care-
fully, and be able to check “the numbers” against a known correct set of values. This checking
and verifying process is often more complex and takes more time than expected because BI
projects commonly ?nd errors in the data supplied. The data from older systems, in particular,
tends to have numerous data quality issues. These problems can be caused by a lack of data
validation in the software, changes in data de?nitions through the history of the system or data
elements being used for multiple purposes.
It is usually very dif?cult to ?nd all of these issues before commencing the project. A good BI
project plan will include data discovery as a task (by the developers) and will facilitate early ac-
cess to the data by the business, to help identify these issues as quickly as possible. An early
‘pilot’ load is invaluable in exposing these issues at the initial stages of the project.
These data issues often need to be addressed by data ?xes during the testing phase. These
?xes then need to be re-tested. This may in turn expose further data issues, which will then
need to be ?xed. The testing phase therefore tends to be an iterative process, with repeated
testing cycles.
All these factors conspire to make the testing process longer and more resource intensive than
testing efforts on other projects. It is important that the project caters to the additional time
required to perform adequate testing, data ?xing, and re-testing, as the business needs to be
able to trust the information produced.
A good BI project plan will therefore allocate more time for testing, compared to other projects.
The ratio of additional time required will depend on the data quality and age and complexity of
the source data systems, which needs to be assessed during the data discovery process.
6. Users are attached to the current toolset – change management is critical.
BI projects usually involve replacing an existing reporting method (typically Microsoft Excel and
Access) with a new BI reporting capability, consisting of a data warehouse and new reporting
tools.
In the early stages of the BI initiative, the data loaded into the new warehouse often does not
allow the users to produce the full range of their existing reports. The users will also need time
to familiarize themselves with the structure of the data available in the warehouse, and will
require training on the features of the BI tools provided.
By contrast, users are already familiar with the features and data available in the existing tools,
and as a result often feel that the current methods are easier to use. They are also accustomed
continue »
”...once a report is available
for testing, the testing
process will often identify
errors not in the report
itself but with the underly-
ing data sources.“
”...users will also need time
to familiarize themselves
with the structure of the
data available in the ware-
house, and will require
training on the features of
the BI tools provided.“
5 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
to the ?exibility of general purpose tools such as Excel, and may not be prepared to use the BI
tools provided as a substitute.
It is therefore critical to de?ne a change management strategy for the BI effort. This should
take into account user training needs as well as gaps in reporting capabilities, and should
address any concerns about ?exibility to manipulate data manually for ad hoc reporting or
analysis.
This change management strategy should recognize that the BI initiative will not (in most cas-
es) replace all of the current reports at once. In such cases, the project should aim to replace
the current reporting methods according to a schedule agreed with the business. The existing
system and tools should be retired gradually, and the BI project may need to provide a short
transition period during which users have access to the old tools, or alternatively, allow access
to the BI reports via a more familiar interface such as Excel.
For long-term planning, it is important to identify all of the current reporting requirements, as
well as the downstream users of the data. It is also important to ensure that the solution being
developed is not bound by the same limitations as the existing systems. Although it is tempt-
ing for users and developers to agree to reproduce an existing set of reports, this is not the
best approach as it does not take advantage of the additional capabilities provided by the new
data warehouse, and may also reproduce existing errors in the new system.
A far better approach is to work with the users and business analysts to de?ne the reporting
requirements based on discussions and workshops, rather than seeking to replicate existing
reports. Brainstorming is often a good way to get users to ‘think outside the box’. By allow-
ing the users to come up with a ‘wish list’ of information requirements, the project team can
sidestep the limitations of the current reporting system, leading to greatly enhanced reporting
capabilities for the end users.
7. Tight integration with existing systems and business processes.
A BI solution needs to ?t into an existing environment of operational systems and databases
(that generate and record the data), business processes (that use the data) and business and
IT support (that keeps it all running smoothly).
In particular, it is usually necessary to extract the required data from the operational (transac-
tion processing) systems without affecting the performance, stability and reliability of these
systems. This is extremely important as these are often business critical systems that can’t be
jeopardized by a demanding data extraction process.
Once the data has been extracted, it needs to be integrated and presented in a timely and
meaningful manner. There are a number of tools which can be used, each with its own
strengths and weaknesses. The choice of tools to be used, as well as the integration method,
needs to be de?ned in advance.
At the same time, the BI solution also has to ?t into existing business processes and be ac-
cepted by the business staff who will be using it on a day-to-day basis. It is important to under-
stand what data they need, where they currently get this data from, and how they produce the
reports that management require. Issues such as lack of user training and acceptance could
have a huge impact on the project’s success, limiting the value of the solution that is built.
Again, the business deployment and change management strategy needs to be de?ned before
the BI project is started.
continue »
”...it is necessary to
extract the required data
from the operational
systems without affect-
ing the performance,
stability and reliability of
these systems.“
6 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
These considerations highlight the importance of a BI Strategy, and detailed planning and
preparation before embarking on a BI initiative. This implementation strategy also needs to be
informed by a readiness assessment across the affected areas of the organization.
Some of the elements of the BI readiness assessment would include an evaluation of the
technical environment, as well as a data and information needs assessment and a review of
the business and analytics culture. The results of this BI readiness assessment should then be
used to help de?ne the BI technical implementation strategy, business deployment and change
management strategy, and the background supporting elements such as the information gover-
nance program and production support arrangements.
8. BI is a program, not a project.
In the past, BI efforts were often structured as a ‘project’, with a single de?ned budget and
schedule to integrate data from a number of systems into the data warehouse.
Experience has shown that a large number of changes and issues are often found during these
projects, causing the ?nal budget and schedule to vary dramatically from the initial estimates.
This has given BI projects a reputation for being dif?cult to manage.
As we have discussed, in our experience it is better to structure the BI effort as a series of
projects, each with its own limited budget and schedule. The data warehouse is thus built in
stages, where each project delivery consists of a component of the overall set of requirements
de?ned by the business.
When the BI effort is approached as a ‘program’, it becomes easier to prioritize the delivery of
major components, including changes, without rejecting evolving user requests outright. It also
becomes easier to separate the development efforts (which are structured into projects) from
the support activities which the BI system will require.
The supporting elements of the BI program will include the technical infrastructure and envi-
ronment, the overall information architecture, design standards and guidelines, an information
governance program, a change management program and an ongoing BI operations (produc-
tion) support program. All of these elements need to be set up to support the BI effort and will
be shared by all of the projects on an ongoing basis.
Conclusion
Creating a BI capability is a complex and resource intensive set of activities. For this reason, it
is better to structure your BI initiative as a program, which includes a series of BI projects and
the supporting activities required.
BI programs and projects have some unique characteristics, and therefore require a different
approach to other projects. Agile techniques, extensive business involvement, careful change
management and extended scope de?nition and testing phases have all been proven to be
essential in BI initiatives.
By incorporating these methods and practices into your BI program, you will increase your
chances of producing a more reliable, accurate and timely information source that will deliver
value for your business.
”...it is better to structure
the BI effort as a series
of projects, each with its
own limited budget and
schedule.“
doc_728383960.pdf
8 Ways that Business Intelligence Projects are Different
1 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
8 Ways that Business Intelligence Projects
are Different
And How to Manage BI Projects to Ensure Success
Business Intelligence and Data Warehousing projects have developed
a reputation as being dif?cult, risky and expensive. Although Data
Warehousing has been around for decades, there is still a high failure
rate for BI and DW projects – an oft-quoted ?gure is that at least 50% of
these types of project fail, and many more go over time, over budget, or
don’t deliver the expected bene?ts – or all three.
One cause of these problems is that BI and Data Warehouse projects are often approached like
a typical IT project, whereas in fact a very different approach is needed. This paper will discuss
8 important differences between BI initiatives and other kinds of IT projects. By understand-
ing these differences, it is possible to structure the environment and the project management
methodology so that these differences are taken into account, resulting in a much higher suc-
cess rate and greater business bene?t.
How are Business Intelligence Projects Different?
1. Business Intelligence projects are primarily business projects, not IT projects.
There is a common perception that BI projects are IT projects. While Information Technology
is an important component of BI projects, it is better to treat BI initiatives as business projects
which are enabled using technology.
This is because the business users will ultimately decide the success or failure of the project.
The business therefore needs to take the lead role both in de?ning their information require-
ments and in ensuring that the BI solution built by IT meets these requirements. This is in
contrast to the approach often taken, in which IT determines what it believes to be the user
requirements and delivers to this speci?cation, inviting the business on board in the latter
stages of the project.
To drive the project as a business-led initiative, the business must be engaged to de?ne what
information they need, the format that they need it in, where the most up-to-date and accurate
version of the data is stored, how the data is related (including how it should be summarized
and categorized), when and how often the data needs to be provided, how much history needs
to be catered for, and to whom the data should be made available.
By properly analyzing and documenting the complexity of the business’ information require-
ments, questions will inevitably arise during the design and development process. The IT
developers will need the business to explain the meaning of the data, clarify how they want
the data processed and displayed and de?ne how to handle exceptions. The business subject
matter experts therefore need to allocate a substantial amount of time to help the IT develop-
ers understand the data and help resolve the questions which arise.
continue »
ABOUT ANALYTICS8
Analytics8 is a business intelligence (BI)
and data warehousing enablement and
optimization consulting ?rm. Though
we are experts with many tools and
technologies, we never lose sight of
the business reasons for implementing
technology.
Let us show you how to make the most
of your data.
“...it is better to treat BI
initiatives as business proj-
ects which are enabled
using technology.“
2 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
A signi?cant level of input from the subject matter experts (SMEs) is also required during the
testing phase. This is because the testing needs to be carried out by people with business
experience who know the signi?cance of the data being examined, so that exceptions can be
?agged and ‘?xed’.
Often, the business users and SMEs ?nd that they need so much time for testing that they
need to join the project team full-time during the testing phase. This is a signi?cantly greater
resource commitment, compared to typical IT projects.
The project sponsors need to be aware of the time commitment that will be required of the
information SMEs to make the project a success, and ensure that there is a high level of busi-
ness commitment and ownership before starting the BI initiative.
From a project management perspective, the project plans need to re?ect the level of business
personnel involvement required. The project manager should con?rm that the organization is
willing to release these people to join the project team when their involvement is required, and
that these people have the necessary knowledge and skills to provide the appropriate level of
input to the business analysts and the development team.
2. Intensive IT business analyst support is required throughout the project.
While the business needs to be prepared for a substantial resource commitment, IT also
needs to be aware that a BI initiative will require more dedicated business analyst time, com-
pared to other projects.
This is due to the fact that the requirements will continue to be clari?ed and re?ned during the
development phase. The IT business analyst needs to stay deeply involved in the project to
document (and note the impact of) these re?nements, and help manage the level of change in
the development process.
Compared to other projects, BI projects also involve a signi?cantly greater contribution of
business analyst time during the development and testing phases. Many organizations make
the assumption that business analyst involvement is required mainly during the design phase.
This approach leads to serious under-estimation of the business analysts’ work allocation in the
project schedule for the remainder of the project.
Project managers therefore need to make sure that the business analyst is appropriately al-
located for the duration of the project. The project manager and business analyst will need to
work closely together to manage the scope of work, ensuring that scope creep is managed.
The business analyst will need to document re?nements and clari?cations of the requirements
throughout the project life cycle, together with the reasons and business rules behind these
choices.
3. Requirements for BI projects are impossible to de?ne completely in advance.
It is rare to ?nd a BI project where the users are able to de?ne exactly what information they
want from the solution, in advance. While they will have some initial requirements, the process
of de?ning and thinking about their information needs will prompt new ideas, as they start to
realize how the data warehouse can make new reporting capabilities available to them.
Often these new ideas arise well into the development and even testing phase of the project,
presenting a major challenge to the project manager to balance the evolving business require-
ments with the need to manage scope.
continue »
“...IT needs to be aware that
a BI initiative will require
more dedicated business
analyst time, compared to
other projects.”
3 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
In fact, these additional requirements represent one of the major bene?ts of developing a
data warehouse, as these new insights are often where the greatest potential value of the
project lies. Changes to business requirements should not be viewed negatively, as delivering
enhanced capabilities represents a key objective of the BI project.
Traditional development methodologies, however, tend to focus on controlling and limiting
changes to initial requirements speci?cations. This can be extremely counter-productive in BI
projects, as this approach will limit the usefulness of the BI solution produced.
One way of mitigating this problem is to devote more time than usual to the requirements
gathering and analysis phase, before development begins. This extended scope de?nition
phase will provide a better picture of the ?nal scope of the project, and will allow more time to
get business agreement on the boundaries of what will be included in the scope.
The IT developers also need to adopt a ?exible approach, so that the detailed business require-
ments can be re?ned or clari?ed during the development phase of the project. The project
manager needs to take care, however, that only minor changes are allowed to proceed. As
with other projects, major changes should only proceed after the impact of the change has
been assessed, quanti?ed and agreed with the business sponsor.
4. A different project management approach is necessary.
The above three features of BI projects suggest that traditional software development
methodologies (such as waterfall-based approaches) do not work well in the BI context.
In fact, BI development efforts tend to ?t better into an iterative methodology, where work is
done in cyclical stages. Our experience has shown that agile system development methods
and techniques are very effective in delivering results in BI projects.
An agile approach involves small teams of highly skilled individuals, who work very closely
together. The project includes the business users as integral members of the team, with all
members communicating closely and continuously with each other. In our experience, an
important technique to promote the free ?ow of information and ideas is the co-location of
business SMEs and IT developers.
The agile methodology also emphasises rapid release cycles of small components of the
overall solution. Agile methods therefore do not involve a great deal of requirements speci?ca-
tion up front, but rather a continuous re?nement of the requirements as the system is being
developed, based on feedback from the users of the BI solution.
Scope is managed by applying a ‘timebox’ to each cycle of the project. To do this, the develop-
ers and business SMEs agree on what is achievable in the given time for a particular cycle. All
requirements that can not be completed within this period are deferred until after the current
scope of work has been completed, but are not lost as they become part of a future develop-
ment cycle.
The methods described above are quite different to traditional project management methods.
Most organizations and project managers have only had experience with conventional models,
and most conventional methodologies don’t always align easily with agile methods.
continue »
”...BI development efforts
tend to ?t better into an
iterative methodology,
where work is done in
cyclical stages.“
4 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
Ultimately, agile techniques are not incompatible with more conventional project management
methodologies. The agile development philosophy and emphasis on producing value to the
business is a valuable addition to standard project management tools and techniques in BI
projects.
5. Building the BI solution is just the beginning – extensive testing is needed.
One of the major areas that is frequently under-estimated in data warehousing projects is the
amount of time required for testing and dealing with data ?xes. Most organizations assume that
a report or dashboard is ?nished once the development process is completed. However, once a
report is available for testing, the testing process will often identify errors not in the report itself
but with the underlying data sources.
The project team, including business SMEs, need to examine the contents of the report care-
fully, and be able to check “the numbers” against a known correct set of values. This checking
and verifying process is often more complex and takes more time than expected because BI
projects commonly ?nd errors in the data supplied. The data from older systems, in particular,
tends to have numerous data quality issues. These problems can be caused by a lack of data
validation in the software, changes in data de?nitions through the history of the system or data
elements being used for multiple purposes.
It is usually very dif?cult to ?nd all of these issues before commencing the project. A good BI
project plan will include data discovery as a task (by the developers) and will facilitate early ac-
cess to the data by the business, to help identify these issues as quickly as possible. An early
‘pilot’ load is invaluable in exposing these issues at the initial stages of the project.
These data issues often need to be addressed by data ?xes during the testing phase. These
?xes then need to be re-tested. This may in turn expose further data issues, which will then
need to be ?xed. The testing phase therefore tends to be an iterative process, with repeated
testing cycles.
All these factors conspire to make the testing process longer and more resource intensive than
testing efforts on other projects. It is important that the project caters to the additional time
required to perform adequate testing, data ?xing, and re-testing, as the business needs to be
able to trust the information produced.
A good BI project plan will therefore allocate more time for testing, compared to other projects.
The ratio of additional time required will depend on the data quality and age and complexity of
the source data systems, which needs to be assessed during the data discovery process.
6. Users are attached to the current toolset – change management is critical.
BI projects usually involve replacing an existing reporting method (typically Microsoft Excel and
Access) with a new BI reporting capability, consisting of a data warehouse and new reporting
tools.
In the early stages of the BI initiative, the data loaded into the new warehouse often does not
allow the users to produce the full range of their existing reports. The users will also need time
to familiarize themselves with the structure of the data available in the warehouse, and will
require training on the features of the BI tools provided.
By contrast, users are already familiar with the features and data available in the existing tools,
and as a result often feel that the current methods are easier to use. They are also accustomed
continue »
”...once a report is available
for testing, the testing
process will often identify
errors not in the report
itself but with the underly-
ing data sources.“
”...users will also need time
to familiarize themselves
with the structure of the
data available in the ware-
house, and will require
training on the features of
the BI tools provided.“
5 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
to the ?exibility of general purpose tools such as Excel, and may not be prepared to use the BI
tools provided as a substitute.
It is therefore critical to de?ne a change management strategy for the BI effort. This should
take into account user training needs as well as gaps in reporting capabilities, and should
address any concerns about ?exibility to manipulate data manually for ad hoc reporting or
analysis.
This change management strategy should recognize that the BI initiative will not (in most cas-
es) replace all of the current reports at once. In such cases, the project should aim to replace
the current reporting methods according to a schedule agreed with the business. The existing
system and tools should be retired gradually, and the BI project may need to provide a short
transition period during which users have access to the old tools, or alternatively, allow access
to the BI reports via a more familiar interface such as Excel.
For long-term planning, it is important to identify all of the current reporting requirements, as
well as the downstream users of the data. It is also important to ensure that the solution being
developed is not bound by the same limitations as the existing systems. Although it is tempt-
ing for users and developers to agree to reproduce an existing set of reports, this is not the
best approach as it does not take advantage of the additional capabilities provided by the new
data warehouse, and may also reproduce existing errors in the new system.
A far better approach is to work with the users and business analysts to de?ne the reporting
requirements based on discussions and workshops, rather than seeking to replicate existing
reports. Brainstorming is often a good way to get users to ‘think outside the box’. By allow-
ing the users to come up with a ‘wish list’ of information requirements, the project team can
sidestep the limitations of the current reporting system, leading to greatly enhanced reporting
capabilities for the end users.
7. Tight integration with existing systems and business processes.
A BI solution needs to ?t into an existing environment of operational systems and databases
(that generate and record the data), business processes (that use the data) and business and
IT support (that keeps it all running smoothly).
In particular, it is usually necessary to extract the required data from the operational (transac-
tion processing) systems without affecting the performance, stability and reliability of these
systems. This is extremely important as these are often business critical systems that can’t be
jeopardized by a demanding data extraction process.
Once the data has been extracted, it needs to be integrated and presented in a timely and
meaningful manner. There are a number of tools which can be used, each with its own
strengths and weaknesses. The choice of tools to be used, as well as the integration method,
needs to be de?ned in advance.
At the same time, the BI solution also has to ?t into existing business processes and be ac-
cepted by the business staff who will be using it on a day-to-day basis. It is important to under-
stand what data they need, where they currently get this data from, and how they produce the
reports that management require. Issues such as lack of user training and acceptance could
have a huge impact on the project’s success, limiting the value of the solution that is built.
Again, the business deployment and change management strategy needs to be de?ned before
the BI project is started.
continue »
”...it is necessary to
extract the required data
from the operational
systems without affect-
ing the performance,
stability and reliability of
these systems.“
6 Sydney
Melbourne
Chicago
Raleigh
Dallas
[email protected]
www.Analytics8.com
© 2010 Analytics8
These considerations highlight the importance of a BI Strategy, and detailed planning and
preparation before embarking on a BI initiative. This implementation strategy also needs to be
informed by a readiness assessment across the affected areas of the organization.
Some of the elements of the BI readiness assessment would include an evaluation of the
technical environment, as well as a data and information needs assessment and a review of
the business and analytics culture. The results of this BI readiness assessment should then be
used to help de?ne the BI technical implementation strategy, business deployment and change
management strategy, and the background supporting elements such as the information gover-
nance program and production support arrangements.
8. BI is a program, not a project.
In the past, BI efforts were often structured as a ‘project’, with a single de?ned budget and
schedule to integrate data from a number of systems into the data warehouse.
Experience has shown that a large number of changes and issues are often found during these
projects, causing the ?nal budget and schedule to vary dramatically from the initial estimates.
This has given BI projects a reputation for being dif?cult to manage.
As we have discussed, in our experience it is better to structure the BI effort as a series of
projects, each with its own limited budget and schedule. The data warehouse is thus built in
stages, where each project delivery consists of a component of the overall set of requirements
de?ned by the business.
When the BI effort is approached as a ‘program’, it becomes easier to prioritize the delivery of
major components, including changes, without rejecting evolving user requests outright. It also
becomes easier to separate the development efforts (which are structured into projects) from
the support activities which the BI system will require.
The supporting elements of the BI program will include the technical infrastructure and envi-
ronment, the overall information architecture, design standards and guidelines, an information
governance program, a change management program and an ongoing BI operations (produc-
tion) support program. All of these elements need to be set up to support the BI effort and will
be shared by all of the projects on an ongoing basis.
Conclusion
Creating a BI capability is a complex and resource intensive set of activities. For this reason, it
is better to structure your BI initiative as a program, which includes a series of BI projects and
the supporting activities required.
BI programs and projects have some unique characteristics, and therefore require a different
approach to other projects. Agile techniques, extensive business involvement, careful change
management and extended scope de?nition and testing phases have all been proven to be
essential in BI initiatives.
By incorporating these methods and practices into your BI program, you will increase your
chances of producing a more reliable, accurate and timely information source that will deliver
value for your business.
”...it is better to structure
the BI effort as a series
of projects, each with its
own limited budget and
schedule.“
doc_728383960.pdf