Business Intelligence Project  Implementation And Management   Do’s and Don’ts with Best Practices  





Author: Chaitanya Bhure  Service Offering(s): Consulting 

  Publish Date:  15 ‐ October ‐ 2010 

Chaitanya Bhure


Table of Contents
1.0  EXECUTIVE SUMMARY 5  7  7  10  10  11  12  15  16  17  18  19  21  21  23  25  27  27  28  28  29  30  30  31  31  31  31  32  32  33  33  33 2.0  REQUIREMENT GATHERING AND ANALYSIS 2.1  System Requirement Study / Business Requirement Study 3.0  DESIGN PHASE 3.1  Report Rationalization Document (RRD) 3.2  Report Definition Document (RDD) 3.3  Universe Definition Document (UDD) 3.4  Logical Data Model (LDM) 3.5  Mapping Design Document 3.6  Report Scheduling Specification 4.0  DEVELOPMENT PHASE 4.1  ETL Development 4.2  Universe and Report / Dashboard Development 4.2.1  Universe Development 4.2.2  Webi Report Development 4.2.3  Dashboards Development 4.3  Unit and System Integration Testing 4.3.1  ETL Testing 4.3.2  Report Testing 5.0  DEPLOY PHASE 5.1  Perform UAT on Development environment 5.2  User Training 5.3  Prepare the BODS XI 3.1 Production Environment 5.4  Prepare the BO XI 3.1 Production Environment 5.5  Migration of Development to Production 5.5.1  ETL Migration 5.5.2  Report Migration 5.6  Review and Validation 6.0  EVOLVE PHASE 6.1  Knowledge Sharing 6.2  Post Production Support 6.3  Exclusions

Chaitanya Bhure


7.0  PROJECT ORGANIZATION 7.1  Vendor’s Roles and Responsibilities 7.2  Customer’s Roles and Responsibilities 7.2.1  Customer Responsibility: 8.0  DELIVERABLES AND ACCEPTANCE CRITERIA 8.1  Deliverables 8.2  Acceptance Procedure and Criteria 8.3  Sign‐off the User Acceptance Test (UAT) 8.4  Requirement Changes 8.4.1  Change Control Process 8.4.2  Response to Request for Change 8.4.3  Customer Approval 8.4.4  Implementation 9.0  PROJECT COMMUNICATION & CONTROL MECHANISMS 9.1  How does one do Basic Level BI Project Management? 10.0  RISK MANAGEMENT

33  34  37  38  39  39  39  40  41  41  42  42  42  43  44  47 

Chaitanya Bhure


   Due to ever changing information needs of an organization ranging from reporting to business modeling.  It should also be noted that before you submit the proposal for such large BI implementation project.  design  keeps  on  changing.  In the design phase tools like ERWIN should be used instead of Excel for Entity‐Relationship Diagram (E‐ R) which also ensures reduction in manual work and delay. ETL.  proper  system  study  should  be  undertaken  so  as  to  properly  estimate  the  efforts  and  commercials.      While  implementing  the  above  BI  project.  manual  monitoring  was  done  instead  of  proper  project  management  tool  which  was  time  consuming  with  no  proper  analysis  of  tasks  and  milestones  achievement.   For  tracking  the  completion  of  various  tasks  and  reaching  a  milestones  on  said  deadline  requires  a  Project  Management  tool  like  MS  Office  Project  Professional  Edition  which  gives  various  analysis  like  which  task missed the deadline and why. the entire chain of BI may be impacted. OLAP modeling and metadata updation. data‐warehouse modeling.  If  we  need  to  have  the  information  management  related to a new set of data elements.  delivery and number of requirements.  and  the  data  modeling.  These  tools  will  also  ensure  proper  change  control  mechanism  if  client  suggests  some  changes  which  needs to be incorporated in the project plan and new delivery schedule is agreed upon with customer. Proper change control mechanism also could not be ensured because the process  was  all  manual  and  a  lot  of  time  was  wasted  in  estimation  of  efforts  and  convincing  client  about  the  change. This resulted into dispute and delay with both the vendor and client companies blaming  each other for delay.        Chaitanya Bhure 5 .0 EXECUTIVE SUMMARY  This  document  details  about  the  learning’s  of  one  of  the  major  fixed  bid  Business  Intelligence  Project  Implementation  for  one  of  the  major  FMCG  player  from  the  Indian  Market.  the  vendor  company  should  convince  customer  for  system  study  which  will  help  in  avoiding  future  issues  on  project  commercials.  If  customer  ask  to  give  them  the  proposal  within  short  span.  This  type  of  major  implementation  requires  careful  monitoring  process  and  clear  definition  of  milestones.  Reaching  a  milestone at the prescribed deadlines requires the milestones to be broken into various tasks and the  resources that are going to complete those tasks.  efforts.1. This will transcend across  source system mapping. This will avoid the project delay and dispute with customer.

 Formats & Data)  Delay due to User UAT  Delay due to Inputs from User required for output  No usage of Project Management Tool  Delay due to multiple training sessions on BI tool for business users  Lack of commitment from User community (Resistance to Change)  Frequent resource change deployed on project  Chaitanya Bhure 6 .  • • • • • • • • • • • • • • • • •                                     Efforts and Commercial Estimation without proper System Study  End requirement changes  Requirement Logic change  RDD without proper logic for some reports   Data Transformation Logic change  Historical Data Load  Quality & Consistency of Data  Source Connectivity Issues (SAP)  Shared Folders Permission Issues  Disk Space Issues related to Target Data Warehouse  Excel Source Issues (Path Permission.      There can be number of issues which can result into delay and affect project profitability. Some of the  major issues are listed below which are elaborated in multiple sections of this document.

   Customer shall provide necessary support and information required in order to complete  the tasks specified in the scope. and use those requirements to  guide the analysis of the reporting. data and user interface requirements.    What types of information must you gather in the preliminary survey? At a minimum.  • Analysis of Database Source Structure and source to table mappings. individually and groups  • Products manufactured or sold  Chaitanya Bhure 7 .  • Mission and functions of each user group  • Computer systems used by the group  • Key performance indicators  • Factors affecting success of the user group  • Who the customers are and how they are classified  • Types of data tracked for the customers.0 REQUIREMENT GATHERING AND ANALYSIS  Analyze the existing systems and the requirement of the Customer that will help in driving  the Business Intelligence Solution implementation in detail. infrastructure.  2.        2. Use these requirements to recommend the infrastructure architecture.     • Understand the existing Business and terminologies  • Understand  and  review  the  Reporting  requirements  by  studying  the  existing  reports  created by the Customer and understanding of related Dimensions and Measures.1 System Requirement Study / Business Requirement Study  Do’s  This document is prepared after understanding Business Requirements that are driving the  whole project. obtain  general information on the following from each group of users:    • Ask very specific questions rather than high level.   • Understand the existing data sources.  • Understand  the  various  crucial  parameters  defined  by  studying  the  existing  reports  generated which are already provided by the Customer.

  Cost  mentioned  here  is  the  project related cost which needs to be considered in this phase of project and proper cost  justification  needs  to  be  given  to  customer.Categorization of products and services  Locations where business is conducted  Levels at which profits are measured‐per customer. the implementing vendor will be able to proceed to the other phases.    At  the  conclusion  of  this  phase.  Take  all  the  points  into  consideration  while  arriving at project commercials.  the  complete  understanding  of  the  systems  and  mapping  from the source systems will be done. per district  Levels of cost details and revenue  Current queries and reports for strategic information    The  vendor’s  primary  goal  in  the  requirements  definition  phase  is  to  compile  information  packages  for  all  the  subjects  for  the  data  warehouse. information packages enable implementing vendor to:    • Find out the Data Sources for the Data Warehouse data.  Once  firmed  up  the  information  packages. per product.  • Define the common subject areas  • Design key business metrics  • Decide how data must be presented  • Determine how users will aggregate or roll up  • Decide the data quantity for the user analysis or query (Historical Data)  • Decide how data will be accessed  • Establish data granularity  • Estimate data warehouse size  • Determine the frequency for data refreshing  • Ascertain how information must be packaged  • Get a list of reports that is supposed to come out of the new data warehouse. The points are given below:  • • • • • • License Cost (Business Objects Cost if licenses are not purchased)  Hardware cost (Vendor is not having the requisite hardware for BI)  Project Management Cost  Scoping and analysis cost  Modeling cost  Design and Development cost  • • • • • Chaitanya Bhure 8 .  Essentially.    Cost‐Adherence:   There  are  various  elements  of  cost  linked  to  BI/DW  projects.

  Ascertain  the  data  quantity  in  this  stage  itself  and  inform  the  customer  that  if  historical data is for multiple years then it needs to be consistent and clean and the  vendor is not responsible for cleansing and consistent data as it is a separate activity  itself  which  needs  to  be  estimated  for  efforts  and  commercials  avoiding  future  dispute and delay. Once everything is  clear make sure to get a sign‐off from the client on the requirements to avoid dispute.     Don’ts  • Going  overbroad  in  capturing  the  requirements.  Non  ascertaining  data  quantity  for  the  user  analysis  (Historical  Data)  in  this  stage. Understanding of reporting requirements and feasibility of  delivering those reports to the end customer by doing proper source system study  helps in setting the expectations right and also helps in estimating the development  efforts and commercials of the project.   Documenting the requirements where you have doubts about data availability. tool  constraints etc.  • • Summary    Requirement analysis and gathering is a bit tough as client might not be clear with his/her  requirements.                        Chaitanya Bhure 9 . Avoid this since this document becomes the guiding principle for the  project development where customer sign‐off is required.• Testing and implementation cost  • Employees Charged time  • Others  The cost management is an important piece for BI project implementation with license and  tools cost being only a smaller piece.  Its  implementation  vendor  expertise  in  the  design  process  and  prior  experience which help to analyze the requirements and put it on paper.  This  should  be  avoided  since  you  are going to document it.

  Methodology  Chaitanya Bhure 10 . user interface. which outlines unit.0 DESIGN PHASE  The requirements identified in the previous phase are further analyzed to  produce detailed design specifications for the architecture. A detailed Test Plan is produced in conjunction with  the design specifications. as to  which reports or requirements are similar in nature and which are too huge  to be accommodated into one BI dashboard / report.  3.                3. data model.1 Report Rationalization Document (RRD)  There are requirements provided by the end users to the implementing  Vendor by the Customer during the business requirement meetings.  An exercise of rationalization will enable the implementing Vendor to  proceed with the design phase of the project and also help the end users  meet the informational requirements with minimum number of BI reports /  dashboards to be referred to. and user acceptance  test scenarios. Each of  these requirements have been documented and approved by the end users. system.  reports.  The purpose of a rationalization activity is to further get a detailed  understanding on the business logic of each of the requirements and  suggest to the end users based on past experience and expertise.

 user actions.  hierarchies. the team will arrive at a  conclusion whether certain reports are to be merged to provide more  information in a single document or needs to be split to be able to  make the requirement more readable and user friendly  • Once the activity is completed along with an explanation of the  reason for report splitting and merging.  Chaitanya Bhure 11 . graphs. drills.  Sample LDM is attached below  PA_Technical_RRD_B _V_1.doc 3. the implementing Vendor will then proceed ahead to  initiate the creation of the Report Definition Document which will  contain the necessary information about every rationalized  requirement in terms of type of tabular data. we need to  understand the business requirements clearly from the user in terms of how  exactly the business user community see their reports at the end of the day. design and the definition of the  requirements will be fixed and developed accordingly by the  implementing Vendor.2 Report Definition Document (RDD)  Do’s  Before starting the Implementation of Data Warehouse. the requirements.The Rationalization activity will be initiated by the implementing Vendor  and the following methodology will be followed throughout the process to  arrive at a conclusion on the number of reports and dashboards to be  developed for each department    • The implementing Vendor will create a matrix containing the data  elements required in each and every requirement given by the  respective departments  • Based on the data elements so captured. slice and dice and so on  • The implementing Vendor will also create patterns of reports and link  the Report Definition Documents to the respective patterns so that  the end users are able to visualize the type of report that will be  developed  • Lastly. the same information will be  shared with the business users for their approval  • Once approved.1.

  Taking the Sign‐off of RDD from the business user. This semantic  Chaitanya Bhure 12 . allowing addition in the number of  requirements (Reports and Dashboard).3 Universe Definition Document (UDD)  A universe is a semantic layer or in more familiar terms a data abstraction  layer which is built with the Business Objects Designer tool. This should not be allowed as  it will have commercial implication as it is going to extent the project  delivery.  Any changes coming while system development which is not captured  in signed‐off RDD will be a Change Request and should be dealt with  change control mechanism.  The  business  logic  should  be  properly  documented  for  each  and  every  requirement  (reports/dashboard)  and  sign‐off  should  be  taken.  The Report Definition Document will reflect the no of requirements  (Reports and Dashboard) for which the implementing vendor will  provide the development efforts and commercials.doc 3. Any additional requirement should be treated as change  request.   Don’ts  • After taking the sign‐off on RDD.   Once through with user requirements and business logic of those  requirements the next step is creating the Report Definition  Document (RDD) and thoroughly checking whether all the elements  are captured or not according to the discussion.• • • • • • • The  next  step  is  to  understand  the  Business  logic  with  the  functional  people.  If business user insists on change which is important to him and not  captured in requirement gathering should be taken as change request  and development and commercial efforts should be estimated with  proper escalation to project owner from customer side.   Once the change request is approved then it should be incorporated  in project plan and project delivery schedule should be updated with  new timelines and milestones.  Sample LDM is attached below  PA_Technical_RDD_B _V_1.0.

 start building the universe  using Universe designer. Business terms and their  meaning. any specific formula which will be used to derive the  measures. type of data stored in those  tables.    • Before you actually start building the Universe. relationship between tables. This means that even if the database structure changes that  instead of being required to change what could be hundreds or even  thousands of reports throughout an organization to accommodate the  change you instead make the changes in the universe and those changes are  automatically passed through to all the reports.    • Once you have completed first two stages. This would be a Universe blueprint which is  called Universe Definition Document and which will help while  actually designing the universe. Try to document  it well and in detail.  Identify measures. plan it well in  advance. The Universe  designer must understand the tables. dimensions and details objects. Understanding the data source on  top which universe to be developed is very important. The genius of this is that  this data abstraction layer sits between the database and your reports or  application. But this might end up in future  Universe Maintenance problems.layer is where you define your business objects which are essentially  encapsulated snippets of SQL that when properly built express a leggo‐like  bit of business logic that can be presented in the reporting tool or through  an application be used and reused to build reports. This has numerous benefits  one being that it allows a much more flexible environment for preparing for  and facilitating change in an organization. Identify number of universes required for reporting. Understand Reporting need and what all tables are  required to feed the data to reports. in most of the BI projects the developers make this mistake and  they jump directly on designer.        Prepare and Analyze Before you touch the Universe Designer  • Well.    Plan the Universe. The planning Universe Definition Document  created in planning stage will help you a lot while building the  Chaitanya Bhure 13 .  Implementation or Actual Design of Universe.

 Frequently use the universe integrity test tool to identify SQL  traps. While building the universe it’s always better to create a  Unit Testing document for universe and create unit tests for every  object you create in universe. If production Business Objects Server is  available you can directly export the universe to production servers  from development server. This will minimize the possible errors and  bugs. join path problems.  Deploy it.    Test once it’s built.    • This is one of the very important stage of Universe building process. for SQL traps by creating sample  reports.universe.  Have very detailed universe testing plan ready for this stage. test measures.    • Once all above stages are completed and well documented. Test each and every object in universe  as soon as you create it. You can deploy  universe using BIAR tool.  Chaitanya Bhure 14 . compare the data against manual SQL data. Test  universe against different scenarios. it’s time  to deploy it for actual use for creating reports. If  possible ask few business users to use the universe for creating some  sample ad hoc reports.

Maintenance.  Design the Entity‐Relationship Diagram (E‐R) by giving the  appropriate relations of the tables.    • Since nothing is prefect issues are supposed to come frequently after  deployment.  SNO 1 2 3 4 5 6 7 8 9 10 11 NATIVE TYPE CHAR NUMC DATS TIMS CUKY CURR QUAN UNIT DEC LANG CLNT SQL TYPE VARCHAR NUMERIC DATETIME VARCHAR NUMERIC NUMERIC VARCHAR NUMERIC VARCHAR VARCHAR COL PREFIX chv_ num_ dt_ cid_ amt_ qty_ uom_ int_ lid_ clt_   Chaitanya Bhure 15 .4 Logical Data Model (LDM)  • • Once RDD is finalized identify the Entities.  Based on this we will start to design the Dimension tables by  capturing all the elements by maintaining hierarchies which are used  for Reporting purpose useful for business users to analyze at the  lower level. Make sure you document every change you made in  universe against the change request. Attributes and the Grain  level.  Next step is to design the Fact tables by maintaining the key  relationship from Dimension tables. Change the Universe for possible resolution and re‐ deploy it.  • • • Do’s  • The data types which coming from the source tables have to have the  following nomenclature which we will be implementing for the target  database as shown below.    3.  For doing the above LDM we have developed an Excel sheet with  prescribed format. Also for every column in the target table  which we design have to follow the given below column prefix. For this we can use ERWIN Tool  but currently we have designed it in the Excel Sheet which is again  time consuming and requires regular updates manually.

  source tables. which server etc)  • Once the above process is completed by designing in the Excel sheet. target tables. it  should be given sign‐off by the respective users.  • Sample LDM is attached below  LDM_V1_0. The Excel sheet which is prepared is called the  Mapping Design Document which is also submitted to the technical  users for checking the business logic and once it is approved.e.xls 3. It should not be allowed.e. source database name.  it’s been given to the development team for the Data Warehouse  Implementation.  • Chaitanya Bhure 16 .   Once the Development is over.  1) Source Definition (Where it is exactly coming from i. target  database name.    If the users change the structure then it will have the impact on the  Universe and Reports which can result into project delay and project  commercials and should be taken as change request with the  requisite commercials. ETL Unit Testing has to be done.5 Mapping Design Document  • Creating the Mapping Design Document in excel sheet where the  given below details are elaborated. which server etc  2) Transformations (Which transformation has to be used to load the data into  target tables and what was the logic to implement the ETL flow)  3) Target Definition ( Where we have to load the transformed data i.  Don’ts  • Once the LDM is created the users (Business / Technical) are given  permission to change the structure of the target tables with the given  nomenclature mentioned above.

  Below  are the given scheduling steps needed to be followed.  monthly  etc  or  the  users  might  refresh  the  report  on  their  own.  Sample LDM is attached below  Source_Target_Map ping_V. User Name / Password.  weekly. Permissions) has to be given by the customer.6 Report Scheduling Specification  Scheduling Reports in Web Intelligence  As per the requirements from the business users the reports can schedule daily. Source  Database Name.  Transformation Logic needs to be finalized by the customer.     Chaitanya Bhure 17 . changing the business logic to existing  mappings. This should not be allowed since it will impact the project  delivery.  User Name / Password changes by the customer at the source level  should be immediately intimated to the implementing vendor. If user insists on change it should be taken as change  request and change control mechanism should be followed. so as  to modify the credentials at the ETL level by the developer.xls 3.1.Do’s  • • • Source related Inputs (Server Name.     Don’ts  • Once the ETL mapping is finished and approved by the customer  accepting changes from the customer end in terms of adding source  tables. adding columns.0.

 Click on servers. access the data.0 DEVELOPMENT PHASE  The specifications completed during the Design phase are used to install and  configure the architecture.  Click ok to enable the selected item. Expand the destination option  Uncheck “use the job server Default”   Give the destination location for the file.   Select the format as Adobe Acrobat.   Click on central management console. The Build phase is where the system is configured to  fulfill the requirements defined in the previous phases. develop the user interface and  create the reports. Open the report to be schedule.   4.• • • • • • •                                     Before scheduling the reports logon to central management console.  Chaitanya Bhure 18 .   Go back to central management console and re start the web  intelligence job server. Click on destination  tab. D:\\Scheduled. E. Click on  schedule option in the report.   Click on web intelligence job server to configure.   Check on unmanaged disk and click on enable button on the right. Click on  schedule button below right to run the job.g.

  • Loading Master Tables: Loading and grouping data into Master tables  • Creating Staging Area which will have Transformation. Aggregation and Loading as per  Business Requirement. Applying each type of revision to the data warehouse is  different. most  suitable for query processing.  Chaitanya Bhure 19 . Hierarchies within each dimension tables are used for  drilling down to lower levels of data. Formulate a strategy for building  aggregate tables. since the ETL function in a data warehouse are most important. data loading is challenging because of volume of data. the initial requirement gathering should be precise and  exhaustive.1 ETL Development  The Business Intelligence project where data warehouse development is  integral part. regular periodic incremental loads  and full refreshes from time to time.  • Large dimension tables such as customer or product need special considerations for  applying optimizing techniques. data transformation is difficult because of the wide range  of tasks.  • Creating Target Area which will have Transformation and Loading as a process   • The data loading function relates to the initial load. time‐consuming and labour‐intensive which determines the  project profitability. optimizes navigation. The given  below are the ETL steps:  • Based on LDM. creation of Physical Data Model takes place which means determine all  the target data needed in the data warehouse.   Do’s  • The components of the dimensional model are derived from the information packages  in the requirements definition (System Study)  • The entity – relationship modeling technique is not suitable for data warehouses.  • STAR schema advantage is: easy for users to understand.  • Slowly changing dimensions may be classified into three different types based on the  nature of the changes. Type 1 relates to corrections.4.  challenging. Type 2 to preservation of history  and Type 3 to soft revisions.  • Aggregate or summary tables improve performance.  • The fact tables contain the business metrics or measurements. Data extraction is complex because of the disparate  source systems. the dimensional tables  contain the business dimensions. the  dimensional modeling technique is appropriate  • The STAR schema used for data design is a relational model consisting of fact and  dimension tables. and enables specific performance schemes.

 it is generally not  recommended. Such instances should be recorded  and notify to the Project Owner (Customer) for possible commercial implications.    • If historical data is part of such project then it is duty of customer to provide clean and  consistent data and vendor would not be responsible for any data quality or  consistency issues. If user even  after repeated communication alters the format of standardized excel sheet which can  result into project delay due to error in ETL load. missing values. loading) is the most  complex work one needs to do in the Data‐Warehouse. and inconsistent values  and so on.  • Changing business logic during the ETL development for any business area which is  completed and the reporting developers have already developed universe and reports  / dashboards.  • If the source is excel then vendor shall standardized those excel sheets and submit it  to the user for data population in the prescribed format only. Data quality problems run the gamut of dummy values.    • If there is problem in data extraction from source system like extraction of data from  purchase registered tables of SAP then Z‐table can be provided by the customer which  the ETL team picks as source and push the data to target database.  • Miscellaneous flags and textual data are thrown together in one table called a junk  dimension table. contradicting values.    Don’ts  • “Snowflaking” or creating a snowflake schema is a method of normalizing the STAR  schema.     Chaitanya Bhure 20 . One should play more  realistic. Data quality is project in itself and proper customer expectation should be  done prior to bidding for such projects.• While development if development teams come across certain product limitation then it  should be immediately communicated with the technical user of the customer and  decision need to be taken with mutual consideration especially with the cluster tables in  SAP. business rule violations. Although some conditions justify the snowflake schema.  • Keep buffer for activities like ETL: ETL (extraction. If the users insists on changes in the business logic (ETL Flow) the  vendor should be considering it as a major change request and appropriate efforts and  commercials need to be estimated since this will delay the project and affect the  project profitability.   • Including data quality scope in such type of projects even critical from customer point  of view. It should be informed to customer prior to implementing the  project and proper expectations needs to set. transformation.  cryptic values. Users should be  intimated not to change the format while populating the excel sheet. The schedule to  update the Z‐table is entirely customer responsibility against which our ETL jobs are  schedule which should be notified to the customer in such situations. when estimating the time for ETL.

    Universe Development Guidelines and Best Practices  Gives the basic guidelines/practices that could be followed in any Universe  Design  Chaitanya Bhure 21 . RDD and UDD Documents.  • Relationship between facts and dimensional tables should be captured in a UDD which  the development team can use in the universe development and which was not  implemented in the current project.2 Universe and Report / Dashboard Development  4.  • For classes and objects the business names should be define in concurrence with the  business users  • Objects description need to be captured in the RDD  • Proper Universe versioning need to be maintained.  • While universe development understanding the tables and their names.2. • While developing the Universe login ID. Take the sign‐off so to take the concurrence on business  names and relationship between tables from the business users which was not practice  in the current project. their  relationship (Joins). Sample reports need to be provided to the user for  testing the universe which was not a practice in the current project to take the  concurrence on report results.4.   • Forgetting to provide the sample reports developed on the Universe which completed  from development perspective.  Universe Development  • Development of reports as per the business requirement. defining joins.1 Do’s  • Development of Semantic Layer (Universe(s)) as per the SRS. connection string to the database  and database name to be provided before development.  • Changing table structure developed in target database while doing data modeling  should be avoided as it will have a major impact on the Universe and reports already  developed resulting into project delay. context and resolving the loops are major activities. password.    Don’ts  • Forgetting to take the user sign‐off once the Universe development for a particular  department is completed.  • Universe back‐up (biar file) need to be taken every day as best practice in case of any  untoward incident like server problem/crash etc  • Proper network connection is the responsibility of the customer for smooth  development.

  Chaitanya Bhure 22 .  Avoid deep level of subclasses as it reduces the navigability and usability.  Connection    • • •   When using a repository.    Tables  • Alias Tables should be named with proper functional use. provide a significant name to List Name under object  properties.  Object to be used in Analysis HAS to be Dimension Objects. Use it only for required Objects.  AVOID Auto Class generation in the Designer. make sure associated Dimension Object has LOV.  Give description for the use of each Object.  Keep "Automatic Refresh before Use" option clicked for LOV Objects  If LOV is editable by the user. esp. always define a SECURED Connection to the Database.  Include an Eg.  Class    • • • •   Define Universe Classes / Subclasses as per the business logic & Naming Convention.  Do not set LOV Option for each Dimension.  Use the Universe Property panel to define the Universe Use and Version (last  update).  Define the Connection Name that helps for Easy Database Identification.  If condition is resulting in a prompt. in the description for Objects used in LOV.  Avoid having duplicate Object names (in different classes).    Predefined Conditions  • Give description for the use of each pre‐defined condition.  All the measure objects should use aggregate functions.  Give description for the use of each Class/Sub‐Class.  those to be used in Report Prompts.  Objects    • • • • • • • • •       Object to be used in calculation HAS to be Measure Objects.

  • The above standard template needs to be provided to the development team prior to  report/dashboard development.  Import/Export    Make sure of the path for Import.  Joins & Context    • • • •   AVOID keeping hanging (not joined) tables in the structure. so that you can have a secured environment.    Migration     •  Better take a backup of the repository and then proceed with the migration       • 4.  alignments etc which should be captured while documenting the RDD.  • Report development should be done in concurrence with RDD only.  • LOCK the universe if Administrator/Designer does not want any user to  Import/Export. format of the page i.  AVOID having N: N joins.  Chaitanya Bhure 23 .  • Good to have correct folder structure. filters.  Give proper functional naming to the context for easy identification.  • Report development depends on RDD and standard templates of report/dashboard  requirements. prompts. report title.2 Do’s  Webi Report Development  • Once the Universe development is frozen and sign‐off is taken then start the report  development.2. This helps other  Universe users in understanding.  • DO "Integrity Check" before Exporting the Universe.  • Standard template of reports need to be finalized in concurrence with the business user  which includes logo. refresh date. which usually is always in the Business Objects'  Universe folder. any deviation needs  to be raised and taken into change request.e.•   Arrange the tables in the Structure as per Business/Functional logic.  AVOID having joins that are not part of any context.

 This should be avoided and escalated  to the customer and proper efforts and commercial need to be communicated.  • Doing new report development while on support. sub‐total figures. total figures etc.  • Doing changes to existing report while on support.        Don’ts  • Taking changes while doing the UAT not mentioned or not captured in the RDD. headers of  the table.  • While doing the UAT if a report or tab not found to be in concurrence with the RDD by  the user then sufficient time to be taken to incorporate the same and again the report  should be released for UAT. It also helps in managing the original project scope. Once accepted the business users should adhere to  the UAT timings otherwise it will impact the project delivery. The quality check should  be done properly prior to releasing the reports for UAT. immediately the  training session needs to be conducted for the user from that department and sign‐off  needs to be taken on report sign‐off template.  • UAT schedule should be communicated to the customer / business user well in advance  and acceptance need to be taken.• Unit Testing needs to be done once the report development is complete which nothing  is but data validation and report format testing as per the RDD.  • Productionisation of UAT completed report and user sign‐off of productionised reports.   • Once the unit testing and quality checks are performed by the development team the  reports / dashboards are released for UAT.  • If some reports are taking longer time for the refresh then it should be properly  communicated to the customer and a decision needs to be taken about those reports  with mutual understanding.   • While development if development team comes across certain product limitation then it  should be immediately communicated with the technical user of the customer and  decision need to be taken with mutual consideration. If user does not respond within stipulated agreed time then  those reports would be considered as accepted and would be released for production. colors. This  should be avoided and should be taken as change request and proper communication  on email about the same should maintain.  • Quality need to be maintained as per standards like proper fonts size.  • Once the UAT is successfully completed for a particular department. This is not best practice  and support should be provided by the separate team and not by the existing  development team as it may have an impact on ongoing project development and can  result into project delay. This also need to be avoided and such  activities should be communicated and efforts to be estimated for commercial and time  duration thus avoiding the delay. proper alignment.   • Once reports are productionised on particular date the support starts on that date itself.  Chaitanya Bhure 24 .  • Providing support by the existing development team on project.  The support is given only for the existing reports.

  General  • • • • • • Give meaningful names for the report tabs   For complex reports. For a face to be affable‐‐and for a dashboard to be  friendly to your business‐‐there are a few requisites that need to be in place. keep overview report tabs explaining the report  Use the report properties to give more information about the report data providers  Each data provider should be given a name that reflects the usage of the data it’s  going to fetch.  Business intelligence dashboard is not all that different from the dashboard in your car.  Avoid bringing lot of data into the report which will unnecessarily slow down the  report performance.2.  4.  Select Objects in such a fashion that the resulting SQL gives a hierarchical order of  tables which helps to achieve SQL Optimization.3 Dashboards Development  Dashboards are the new face of BI. To be  useful. keep you comfortable and tell you when you're  running out of gas. The more surgically  you zero in on precise tactics. This  helps to identify Report Variables different from Universe Objects. it must make you drive better.  Do 1: Let the Dashboard Be Business‐driven and Focused   Ask Business Users: what competitive goals are you trying to achieve through this tool? What  specific processes are you trying to make more efficient? What critical information are you  trying to make more readily available and why? Be ruthlessly specific.  Chaitanya Bhure 25 .  Webi Report Development Guidelines and Best Practices  Given below are the basic guidelines/practices that could be followed in any  Report Design and Development. Let's look at the top‐five do's and don'ts of  dashboard implementation as given below. the better your chance to achieve your strategy of getting  proper information. but without distracting you.  Report Variables  • Follow the naming convention of "var_" as prefix to each report level variable.

  Example: so you want to have an optimal in‐stock level of your top 10 SKUs. and your users will spend time on it for bringing new thought process  which might be 360 degree change from what you have captured in the requirement  gathering which can result into delay and dispute. If users ask for change treat it as change  request and raise the red flag that efforts and commercials needs to be frozen before moving  to the development activities.  Do 3: Make Your Dashboard Actionable   It’s good to give “What If” in dashboard where it makes more user interaction and brings  satisfaction to business users for the tool implemented. which was herculean task.  Do4: Dashboard Estimation  While we were executing the Parle‐Agro project where there were 29 dashboards which we  have to deliver for the 10 departments.   Do 2: Let the KPI Be Your Friend   What's a KPI? It's a key performance indicator‐‐a handy little color‐coded dot or gauge that  "indicates" if your "key" items are "performing" well or if they're headed for the dogs. Deliver what has been captured in  requirement gathering and don’t deviate from it. What we have missed  Chaitanya Bhure 26 . When you're on the wrong  side of the threshold. minimum month‐to‐date sales) for the critical items.  Don't   But for the sake of making the dashboard interesting don’t put “what if” criteria until and  unless some business value is driven out of it. since they can derive information on  which they can act.  Don't   Don't make the dashboard into a less unprofessional version of solitaire. You set up a dashboard that shows this  information in intuitive eyeful‐‐in graphic form and of course in real time. Green: all is going well. Red: either too  much or too little inventory.Example: you want the inventory of the top‐10 SKUs to always remain optimal.  where you have to sort through more figures.g. the KPI shows you a green dot‐‐all A‐OK. “What If” are complex development and users  tend to ask for more “What If” even they don’t make any business value which can result into  time consuming activity and delay. Educate users the difference between Webi  reports and dashboards and their objectives so as to set the expectation right in the  beginning itself. Too much freedom  and too little focus. so that you're  not out of goods while never getting overstocked. Set a  threshold (e. Have 10 KPIs  that alert you without even having to read numbers.  Don't   Don't turn your dashboard into the single‐screen version of those multiple‐sheet Excel tables. the KPI turns red‐‐time to take action. when you're on the good  side of the threshold.

  Universe Development. the more it will be adopted. the more positively it will impact your business as a vendor.  • In spreadsheet. They should be treated separately which will avoid the  dispute while delivering the requirements.    Don’t  • Use of SUMIF.3 Unit and System Integration Testing  4. remember that the dashboard is just a tool.  In Summary   In the end.  • Modification of reports used in Dashboard through Live Office/QWAAS connection. and the more  directly it makes your customers' life easier.  • Use colors. Excel Sheet. COUNTIF. What If criteria and user thought process plays critical role. labels and borders to identify cells or ranges of cells in the spreadsheet.3.while doing the project requirement gathering is our own analysis which would have reduced  the no of deliverable dashboards by asking more specific questions about each dashboards  business value.1 • • • •   Chaitanya Bhure ETL Testing  Basic Validation with Source  Validating the count of records from source and target database (Unit Testing)     maintaining the DB_RECORD_STATUS table at the target database. The easier it is to use. And the more it is  adopted.   27 .  • Try to limit dashboard size to minimum to get good performance.     Do5: Technical  • Data sets should be at a highly aggregated level.   • Use of spreadsheets having links to other spreadsheets. HLOOKUP and VLOOKUP functions on larger data sets.     Don’t  Don’t ever count dashboard requirements into Webi requirement at least for efforts and  commercial estimation purpose.            4.   Working of appropriate business logic which designed in the ETL flow  Testing the jobs on the daily basis which are successful or not by maintaining the  DB_FETCH_BATCH_LOG table at the target database. since dashboard implementation is totally a  different ball game and complex where factors such as Live Office Connection. leave room below and to the right of your data so it can grow over time  without having to add/remove rows or columns.

0 DEPLOY PHASE  The  Deploy  phase  is  where  all  of  the  built  and  unit  tested  system  is  moved  to  the  production  environment and then fully tested to ensure all of the requirements specified in Previous phases  have been fulfilled.   Unit Testing and System Integration Testing (SIT) of the Reports and Universe as per Test  Plan.3. the system will be transitioned into  general use and turned over to the IT department for on‐going Production support    Chaitanya Bhure 28 .  5.2 • • •                                                     Report Testing  Validate the report format and structure with the RDD.  Validate the report data against the validated Data warehouse data. At the conclusion of the Deploy phase.4.

  Do’s  • • Report and Dashboard development should be done in accordance with RDD only. prompt  display.  Forgetting to notify the client that once the reports are developed and the business user  insists on changing the formatting of reports then it will impact the project delivery. fonts.1 Perform UAT on Development environment  The Data Warehouse / Mart. This should be considered as change request and should be  escalated for efforts estimation and commercials.   If historical data is considered while bidding the project then data quality and  consistency comes under client’s purview. reports.   Data is loaded in the target database according to the RDD and business logic defined  during requirement gathering phase.   Always inform well in advance the UAT schedule to client. The business users  need to give these excel data well in advance to implementing vendor so as to proceed  with UAT  • • • • Don’ts  • Taking changes like addition of new elements.   Entertaining  logic change brought by user in the UAT stage which is considered as a  major change since it can have phenomenal impact on Universe for one or may be  multiple departments and thus can have impact on reports from one or may be from  multiple departments. It should be notified to the client that they  have to provide the historical data prior to UAT and data testing is clients responsibility  since lot of time is wasted in the doing the said activity if it is not properly defined while  bidding the project. heading. tabs in development which is not  documented in RDD. Left and Right  margin) should be finalized before the report development work starts. It should be taken as change request and estimated accordingly. universe(s) and report(s) will be tested by the user for their  accuracy in terms of data and formats on the development environment.   Standardized Excel inputs for data warehouse should be given to business users for data  population which they are not authorized to change (excel format).   Forgetting to raise the delay because of user UAT   Chaitanya Bhure • • • 29 .   Standard template design for report development which includes logo. heading background colors and margins (Header. It  should be taken as change request and estimated accordingly.5. Footer.

  BI tool functionality should be shown in general (how to access the BI tool.3 Prepare the BODS XI 3. how to publish  the reports in various formats like pdf etc.1 on supported platform  • • • • Install and configure BODS XI 3.  • 5. If it is for multiple years/months then everything  needs to be truncated and loaded again with unchanged standard excel format with  proper data because of ETL fail / improper data in reports which is highlighted while  doing UAT.  User training should be conducted only on UAT accepted reports only.   Install the DI (Data Integrator) functions on SAP R3 on production server  SAP R3 authorizing the functions for DI to operate (To extract the tables from SAP R3)   Chaitanya Bhure 30 .   Forgetting to escalate the issues relating to delay in user training because of non‐ availability of business user on the schedule time.  • • Don’ts  • • Forgetting to inform business users well in advance of training schedule.  Forgetting to escalate the standard excel data input format change by user while ETL. different ways to analyze the data like filtering etc. cleansing and consistency  of data which needs to be loaded in target database prior to UAT is not vendor’s  responsibility.2 User Training  Do’s  • User training needs to be conducted immediately after UAT completion for a particular  department since big gap between UAT and user training will result into lack of  commitment from business users. how BI tool will help in eliminating the  manual efforts etc) and not at great depth which makes users think of complexity of  using the tool resulting in lack of interest.1 Production Environment  Installation and configuration of BODS XI 3.  This is again a major loss of time since the developer needs to find out the reason for  ETL fail while loading the excel input. refreshing  report/dashboard.1 server on supported platform.• Forgetting to notify the client about Historical Data validation. I such scenario training is conducted multiple times  which affects project delivery and profitability.1 server components on supported Windows platform.  Deploy necessary BODS XI 3.    5.

1 on supported platform  • • Install and configure BO XI 3.   • •   5.1 server components on supported Windows platform.  Method2: Log on to the data services designer in the development environment and  take a back up of the related project on a shared folder.4 Prepare the BO XI 3.1 server on supported platform. 5. • • 5.5 Migration of Development to Production  5.   Configure CMS and Audit database and creating Repository databases on supported  database server.2   Report Migration  Migration of the UAT Tested reports and universes to Production environment can be done in  two ways as described below.    Once the project is imported successfully on the production environment we have to  run some sample jobs for testing purpose.5.1 ETL Migration  Promote the Data Integrator work flows to the Production environment by two ways described  below. Tomcat server installation on the supported environment. user name/password of production environment. This  process of migration can avoid the issue described in Method 1 of migration process. If  this process is followed for migration then there might be some issues like network  issue. Log on to the data services  designer in the production environment and import that file from the shared folder.    Chaitanya Bhure 31 .5. power failure/fluctuations etc which can corrupt any environment.1 Production Environment  Installation and configuration of BOXI 3.•   Scheduling the Data Integrator jobs in Data Services Management Console on  production environment.  • Method 1: Log on to the data services designer in the development environment and  export the related project directly from the development to the production server with  the credentials like repository name.  Deploy necessary BO XI 3.

• • By using the import wizard  By saving the entire universe and reports in the biar file and migrating by using the  import wizard.0 EVOLVE PHASE  Chaitanya Bhure 32 . universe(s) and reports will be tested by the user for their accuracy  in terms of data and formats on the production environment after which the system goes live  for the users                           6.6 Review and Validation  All the developed workflows.  5.

 creation/modification of views.   • Providing support by the existing development team on project. 6. procedures.  Any data cleansing is out of scope. The support is given only for the existing reports and dashboards.  6.2 Post Production Support  Hand holding to the Business Users and IT Department for maximum of 10 man‐days or as per  the agreement with the customer.3 Exclusions  • • • Resolution of Product Defects. etc. the project is formally closed down. tables.  • Database level scripting.    6.In the Evolve phase.  This again should be avoided while on support and treated as new development.  Don’ts  • Doing changes to existing Data Model (DW).0 PROJECT ORGANIZATION  Chaitanya Bhure 33 .1 Knowledge Sharing  All the documents created during the project will be handed over to customer and the project  knowledge will be shared during a two days knowledge sharing sessions. A Project closure is conducted to  ensure that the lessons learned from the project are captured for future reference.  7.   Working on any Business Objects Enterprise related activities that are not in the scope of  the current deployment. Universes. This  also need to be avoided and such activities should be communicated and efforts to be  estimated for commercial and time duration thus avoiding the delay.  • Doing new development (Universe/Webi Reports/Dashboard) while on support. like. Webi Reports and Dashboards  while on support.   Do’s  • Once reports and dashboards are productionised on particular date the support starts  on that date itself. This should be avoided and escalated to the customer and proper  efforts and commercial need to be communicated. Business Objects will assume that all the data that is  provided would be clean and reliable. This is not best practice  and support should be provided by the separate team and not by the existing  development team as it may have an impact on ongoing project development and can  result into project delay. and to  identify the opportunities for generating further value from another iteration of development.

  Organize project walkthroughs and co‐ordinate with QA for project audits or audits for a  process to ensure that the quality objectives are being achieved.  Implementation of Quality System in the project(s). as required.  Ensure that all necessary documentation for the project(s) are prepared.  Proper  usage  of  project  management  tool  for  effective  project  delivery  on  time.  Working in co‐ordination with the Developers.    Producing periodical status reports to the reporting authority and to the Customer.  to  manage change control mechanism and to ensure the optimum resource utilization so as  to ensure project profitability.7.1 Vendor’s Roles and Responsibilities  Project Manager:  Delivering the project(s) within time and resource budgets.  Requisition of human.  Ensure  that  project  team  members  are  always  kept  informed  on  matters  of  interest  concerning the project/process and their welfare to maintain their morale at a high level.    BO Consultant:   Conducting smooth functioning of various integrations needed  by Business Objects from  SAP Systems.  Coordinating with SAP Consultants on Customer site where additional information needed  to understand the customization if any. if contractually required. maintained and  approved.  Delivering the project(s) in accordance with the agreed contract / work order.  Conducting periodical meetings with team members to ensure effective communication &  feedback (up and down).  Chaitanya Bhure 34 .  Ensure that the status report is regularly reviewed by the reporting authority and by the  Customer. computer and consumable resources and ensure optimum usage.

  Communicate the potential delays along with reasons. as required. if any.  Working in co‐ordination with the Developers.  Evaluating and sizing Change Requests.  Reviewing  design  specifications  to  ensure  correct  use  of  common  modules.  Escalating Customer complaints.  Maintain weekly status and obtain necessary feedbacks.  technical  queries. if any.  correct  interfacing between sub‐systems.  Monitoring and controlling the progress of the project(s).  Demonstrate and implement the Business Objects skills.  Sending Minutes of the Meetings to all the concerned authorities.  Ensure that all necessary documentation for the project(s) are prepared.  Maintain appropriate documentation and records. system integrity and operating efficiency. if any and contractual issues or problems to the reporting  authority and co‐operating with the reporting authority to monitor their status & assist in  their resolution.   Obtaining  Customer  acceptance  on  project  completion. Developer:  Delivering the project(s) in accordance with the agreed contract / work order.  technical  queries.  changes  and  concessions.    Sr. maintained and  approved. if any.    Developer:  To perform all the tasks assigned.Obtaining  Customer  acceptance  on  project  completion.  Collaborating with the Customer executive(s) to ensure that Customer commitments are  being carried out to clarify technical requirements and to resolve technical problems in a  project.  changes  and  concessions.    Chaitanya Bhure 35 .

Chaitanya Bhure 36 .

2 Customer’s Roles and Responsibilities  This  section  details  the  Roles  and  Responsibilities.       Chaitanya Bhure 37 .    Project Manager / Project coordinator  Customer shall designate a person. The specific roles and responsibilities of this person are:  Setting up and managing the project team members from Vendor  Update Customer management on the project status. Customer shall allocate/assign the  required resources with the necessary skills and authority to execute the responsibilities given  below. wherever so required.  which  has  a  potential  impact  on  Vendor  responsibilities.  Initiate  and  approve  Change  Requests  or  obtain  necessary  sign‐off  and  approval  for  the  Change Requests from Customer Management.  Ensure  the  availability  of  Customer  management  and  users  whom  Vendor  may  need  to  discuss with for the purpose of the project. For any  changes  there  is  a  standard  change  request  procedure  for  which  structured  processes  need to be followed. the cost implications of the same have to be considered.  will  be  performed  by  Customer  any  deviation.  Accept  the  deliverables  or  obtain  the  necessary  acceptance  sign‐off  from  Customer     management.  which  Vendor  has  assumed. called Project Manager / Project coordinator to whom all  Vendor  communications  may  be  addressed  and  who  will  have  the  authority  to  act  for  Customer in all aspects of the project.  For any change in scope.  Furnish all the necessary information required by Vendor in connection with the Project. will be subject to Change Control Process.  7.

  Chaitanya Bhure 38 .  To provide the required technical assistance on relevant end Customer applications that  will be used by Vendor on the project. reviews and testing at appropriate times as per the project plan / schedule.  test  data  and  other facilities will be delivered to Vendor in time.  To pursue the project and to co‐ordinate discussions/demos/reviews/ approvals.  tools.   To provide the development standards that needs to be followed.   To provide the acceptance criteria for the project.  To provide the required Software and Hardware for the project.  7.  To provide quick turnaround for reviews.2.  meetings. if desired by Customer  To  provide  the  necessary  documentation  support  (For  Example.  To  make  undisputed  payments  to  Vendor  in  accordance  with  the  payment  schedule  on  Vendor fulfilling its obligations.  To arrange for the required resources  as per contract  To  ensure  availability  of  required  persons  Customer  for  discussions.  To issue the project acceptance certificate upon successful completion of the project. clarifications and answers to queries at various  stages of the project. sign‐offs and acceptances.  Issue  List)  in  assisting  Vendor project personnel for execution of tasks.1 Customer Responsibility:  To provide the required information and documentation associated with the development  effort from end Customer.   To  conduct  acceptance  of  all  project  deliverables  within  the  time  frame  specified  in  the  Project schedule.  clarifications.   To provide quick turnaround for approvals.  To  ensure  that  the  deliverables  from  Customer  including  Software.

 Customer shall provide vendor with written acceptance of such deliverable. the vendor shall provide the UAT sheet which can  be  different  for  different  requirements  (Webi  Reports  or  Dashboard)  mentioning  the  various parameters like report elements.  Vendor shall promptly address any such deficiencies.  After addressing the deficiencies.0 DELIVERABLES AND ACCEPTANCE CRITERIA  8.  Chaitanya Bhure • • 39 .  8.2 Acceptance Procedure and Criteria   Do’s  • Upon completion of any deliverable. data refresh.1 Deliverables  As the Fixed Bid Engagement the following are Deliverables given below  SRS Documentation  Data Warehouse  Mapping Design document  Report Definition Document  Universe Definition Document  ETL Document  Aggregate schema and Universes to cater to the requirements of Reports & Dashboards  Webi Reports  Dashboards    8.  Customer  shall  have  five  business  days  after  the  submission  of  the  deliverable  (“acceptance  period’)  to  give  Vendor  written  notice  which  shall  specify  the  deficiencies  in  detail. report formats etc which should  conforms  to  the  description  specified  for  such  deliverable  captured  while  doing  Requirement  Gathering  and  Analysis  . Vendor shall resubmit the deliverable for Customer’s  review  and  testing  as  described  above.  Customer  will  be  responsible  for  any  additional  review  and  testing  of  such  deliverable  in  accordance  with  any  mutually  agreed  Test  Script & Result forms.  Upon  accepting  any  deliverable  submitted  by  Vendor.   If  the  deliverable  does  not  conform  to  the  description  for  such  deliverable.

  etc. All this should be taken as change request and proper developmental  and commercial efforts to be estimated and notified to the customer well in advance.  his  sign‐off  is  essential  on  the  given  template. change in  formats of reports agreed in requirement gathering. change of logic (ETL). vendor needs to raise the issue immediately  as it might delay the project delivery and affect the project profitability.  Filters.  Alerter  (Working  /  Non  Working). new report  development / new tab development to substitute the dropped reports due to data  unavailability etc.   Forgetting to inform the customer that once the Reports or Dashboards has been  productionised after UAT sign‐off it is deemed to be accepted and invoices can be raised  for particular milestone.  • •   Chaitanya Bhure 40 . such deliverable shall be deemed accepted at the end of the  acceptance period.  Data  Refresh.  All  these  parameters  should  be  mentioned  in  the  template  and  copies  should  be  made  with  report  name  and  code.• If  Customer  fails  to  provide  written  notice  of  any  deficiencies  within  the  acceptance  period. The template will have various parameters of user acceptance like for  Webi  Report  the  parameters  would  be  Report  Format. as provided above.  Don’ts  • The deficiencies confused with change request like addition of new elements.  Once  the  business  user  is  satisfied  with  the  UAT.  8.   Forgetting to raise the issue of user delay in giving sign‐off even after successful  completion of UAT within stipulated time. Once the sign‐off is received the reports/dashboard can be productionised for  day to day usage.  Don’ts  • • Forgetting to take the sign‐off immediately after the UAT completion.   Taking changes which are not mentioned in RDD or not captured during requirement  gathering.  Graphical  Representation.3 Sign‐off the User Acceptance Test (UAT)    Do’s  • Proper  UAT  document  templates  need  to  be  created  for  various  requirements  (Webi  and Dashboards). If such situation arises raise flag of change request to customer and take his  concurrence on proceeding further with proper development and commercial effort  estimation and customer acceptance.

 which typically involves. It will also decide which party is responsible for implementing the change.  The  Review  Committee  will  evaluate  the  RFC  for  technical  validity  and  its  impact  on  the  project.4.1 Change Control Process  A change is initiated by a Request for Change (RFC).   Customer  shall  approve  the  changes  in  plans  and  revised  estimates  in  time  for  implementation.  the  RFC  will  be  forwarded  to  the  party  responsible.  The  party  responsible  will also be known as owner for the  RFC.   Chaitanya Bhure 41 .   Activity  Request for change  Study the impact of the  change  Efforts estimate due to  impact  Schedule Change   Approval of Cost due to  effort revision  Sign off on efforts to impact  Incorporating the changes   Acceptance  Change Request Closure  Implementation Vendor  Change Request form  Impact Analysis form  Estimation Template  ‐  ‐  Impact Analysis form  Development Life Cycle  ‐  Change Request Form  Responsibility  Vendor / Customer           Vendor  Vendor   Vendor with Customer      consent  Customer      Customer      Vendor  Customer         Vendor    8. For urgent RFCs. If approved  by  the  Review  Committee.  Parties  in  writing  will  agree  the  membership  of  the  Review  Committee  on  commencement  of  the  project.4 Requirement Changes   In the event of changes to the initial user requirements requested by Customer the same shall  be  incorporated  into  the  project  plan  and  estimate  of  effort  and  delivery  schedule  will  be  revised based on the extent of changes requested for.  Vendor will re‐evaluate any substantive changes from the baseline requirements and technical  requirements and will follow the Change Control Process. RFC can be initiated by Customer or Vendor. This is done by filling out a copy of the  “change  request  form”  and  submitting  the  same  to  a  Review  Committee  comprising  of  Customer  Project  Manager  and  Vendor  Project  Manager  and/or  their  designates.  The  revised  schedule  and  cost  shall  be  incorporated  to  the  contract  as  amendments.8. a time period will  be  stipulated by which the party should respond.

                    Chaitanya Bhure 42 . Vendor will notify the Customer in writing of the estimated cost.   8.  8.  Vendor  will  implement  change  request  in  accordance  with  the  agreed changed requirements.  Once approved by the Customer.  Depending  on  extent  and  complexity  of  the  requested  change.  provide the Customer with written acknowledgment of the receipt and estimate of time and  effort required to analyze the RFC and prepare the Revised Proposal. In such instances.4.  it  needs  to  be  approved  by  the  Customer's  authorized  representative  in  writing.2 Response to Request for Change  Vendor  will. Affected portions will be changed and tested.  Customer approval is required at two stages:    When  a  change  request  with  effort  estimate.4 Implementation  After  Customer  approval.  Vendor  may  charge  for  the  effort required to analyze the RFC and prepare developmental efforts and commercial for the  same.4. The  Customer may recall the RFC after receiving Vendor’s acknowledgment and estimate.4.  within  stipulated  time  of  receiving  an  RFC  approved  by  the  Review  Committee.   8. the implementation work can be undertaken by the vendor.3 Customer Approval  Approval for Assessment of Change Impact and  Approval for Implementation of Change.  commercial  and  schedule  is  submitted  to  the  customer.

 any urgent issues will be immediately  escalated and brought to the notice of the concerned person and an action plan initiated to  resolve them.   Chaitanya Bhure 43 .0 PROJECT COMMUNICATION & CONTROL MECHANISMS  The status report will be sent to Customer and the same will be discussed during the weekly  reviews conducted through project meetings. telephone conference and video conferencing can also be used. However.  All  relevant  team  members  from  Customer  and  Vendor  team  will  participate  in  the  periodic  reviews and contribute to resolve issues of concern. Other modes of communication  like Instant Messaging (chat).  9. The forum will be used to surface issues  that have dependencies on various activities being carried out.  The modes of communication will primarily be through email.

 deliverables pertaining to the project. deliverables could  result in change request and thereby in the delivery schedule and would affect the cost of the  project. The default response time by Customer on queries by Vendor  is considered as one business day and feedback on deliverables as two business days.  these  approvals  should  be  given  within  the  time  limits stipulated with the query.    For  Approvals  and  Responses  on  queries.  9.1 How does one do Basic Level BI Project Management?  It is very essential to have a project management tool in place for managing. monitoring and  reporting  the  BI/DW  project  progress  as  written  in  executive  summary  of  this  document.  Chaitanya Bhure 44 . Any changes to the signed off documents.  Once Customer has signed off documents. Customer is  bound to accept the documents.

  Cost Assessment Reports: These are the expense sheets based on the vendor payments  and internal effort charge‐out. the capabilities and information is not used. A standard template  needs to be devised for the above activity. A standard process needs to be documented for each step of development  like design. cost and scope. Failures can take various forms in terms of   • • • • Functional – The project is not able to deliver the functionality and analysis capabilities.  • • • • Data  Warehouse  initiative  is  more  challenging  as  compared  to  a  transactional  system.  But  this  need  to  be  avoided  and  given  below  are  only  guidelines for manual monitoring.  Usage‐ Even if the project is well delivered.  Proper  change  control  mechanism  also  could  not  be  ensured  because  the  process  was all  manual  and  a  lot  of  time  is  wasted  in  estimation  of  efforts and  convincing client about the change. fortnightly.  Chaitanya Bhure 45 . Scope for a  BI project will not be a singular statement.  Technical – The technology platform and services don’t work.  A typical  project status report will touch upon timelines.  In  spite  of  their  proven  ROI’s  for  well  implemented  projects. ETL development. Firstly being able to deliver what was  scoped out before and secondly not to have a scope creep at the later stage. A standard template needs to be devised for the same. Report and Dashboard development.  Scope Adherence: Scope adherence is both ways. It should be notified to the client that once  scope is frozen any activity outside the scope will be change request and needs to  adhere to the change request control mechanism or process for which it will have  efforts and commercial implications.  Publishing‐ The availability of data is not as per expectations.  the  proportion  of  Data  Warehouse project failures is fairly high.  • Daily and Weekly Project status reports: These provide the details which can be  consolidated for your weekly.  Here  are  the  methods  by  which  you  can  do  the  manual  monitoring  in  case  you  don’t  have  proper  project  management  tool. monthly and milestone meetings.Manual  monitoring  instead  of  proper  project  management  tool  is  time  consuming  with  no  proper  analysis  of  tasks  and  milestones  achievement  which  needs  to  be  avoided.  You  better read it to understand what you are in for.  Process Adherence checklists: These are the checklists used to assess process‐ adherence.  Steering committee minutes: They provide a view on the management judgment on the  project management which includes project manager/team lead from vendor  organization and project owner/project manager from client organization.  Manual  monitoring  can  result  into  dispute  and  delay  with  both  the  vendor  and  client  companies  blaming  each  other  for  delay.

 While typical business  systems projects also may suffer from similar challenges.• Achievement of business goals – Even if the information is used. when Data Warehouse and Data Management initiatives and knowledge  base still to become a mass awareness and expertise). The diligence required is because Data  Warehouse projects are quite different from business systems projects. Here are Data Warehouse challenges. which are unique   Chaitanya Bhure 46 .  The driver behind these failures is that hype & glamour of Data Warehouse has overtaken the  diligence (especially . the intensity of them is much higher  in Data Warehouse projects. it is not able to drive  the expected business goals.

  Vendor  undertake  to  provide  a  management  approach that will ensure the best possible communication for the containment and effective  handling of the potential risks associated with the implementation.  Areas of Risk  Probability  Implications  Introduction of such  changes will impact  the project schedule. Assign Project  Manager at both ends. Availability of Customer     resources during the various  phases of the project. System  logic discussion. User  Training and UAT  Steering Committee  proposed to ensure  implementation of  effective project  control mechanisms  Replacement  consultants will be  provided by Vendor  with appropriate skills. If possible continue  Chaitanya Bhure Change in application specifics  / design & guidelines during  High  development  High  Delays  Timely escalation of issues of  concern and evolving  appropriate action plans  Low   Any issues of concern  that are raised at the  appropriate time  could be solved so  that there is no  cascading effect  Non availability of assigned  consultants due to  unavoidable circumstances   High  Delays  47 .  10.  Mitigation  Plan  Adhere to formal  Change Control  Procedures  Detailed planning and  commitment to  project.  Vendor will  communicate the  business users in  advance about  meetings requirement  for business logic  discussion.0 RISK MANAGEMENT  Vendor  will  work  with  Customer  to  identify  and  assess  all  potential  risks  including  cost  of  ownership  and  human  resource  constraints.

  Data Quality and Consistency  High  Incorrect Results and  delays      Chaitanya Bhure 48 .  Data Cleansing will be  done by Customer  Customer will provide  consistent data.  Historical Data Upload  in Data Warehouse  needs to be discussed  with customer prior to  going for  implementation. In such  scenarios normally the  customer blames  vendor for data  mismatch which  results into delay and  dispute. since  most of the time the  data is not clean and  consistent which when  loaded into the DW  gives wrong  information.Areas of Risk  Probability  Implications  Mitigation  Plan  with the same  resources till project  closure at least Team  Leader should be  available till project  closure.

  Chaitanya Bhure 49 .

Sign up to vote on this title
UsefulNot useful