zData Quickstart Program

zData’s recommendations are based on the success of its key clients and are based on a 12-16 week project plan.  Below are the milestones and resources required for a standard project. The tasks below should be considered a guideline for the process to establish specific dates and times of deliverables. These timelines will be flexible based on resources, project complexity and availability.  Data Delivery projects generally work well under the rule of thirds, meaning 1/3 of the project is planning and design, 1/3 of the project is development and testing and 1/3 of the project is optimization and rollout.  If adequate time is not given to planning and design or optimizing and rollout (which is all too common) there will be critical steps missed that can have a drastic effect on the long-term success of the implementation. Requirements Gathering and Planning (1-2 Weeks) – This is where management defines the project, the team is created and the project plan and milestones are laid out.  Success requirements are being defined, and the 4 resources below are put in place to get the project started.

  • zData Engagement Manager
  • zData Database Engineer
  • zData Database Architect
  • ETL Scripter / Developer

Data Inventory & Greenplum Infrastructure (2-4 Weeks) – The team gets involved with the identification and understanding of all data sources involved, and the internal subject matter experts help define the data requirements.  The development hardware infrastructure is procured and the Greenplum database is installed.

  • zData Engagement Manager
  • zData Database Engineer
  • zData Database Architect

ELT of Source Data into Data Mart (4-6 Weeks, but depends on # of sources) – Business rules and data definitions are established as the ELT Scripter writes scripts to load the Physical Database.  Rules on how history is saved and purged are defined and sample data is loaded into the system so that report development can start.  Lightweight testing is put in place to confirm that data being loaded is, in fact, correctly being transformed.

  • zData Engagement Manager
  • zData Database Engineer
  • ETL Scripter / Developer

Performance Tuning and Optimization (1-2 Weeks) – The Architect and Engineer review the performance of the system and check it against project success goals.  This entails checking ELT load times into the data warehouse, query processing and report delivery for the front-end systems.  This is a very iterative process and if changes need to occur to meet agreed upon performance, this could become a lengthy process.  Scalability between Development, QA and Production must be reviewed, so accurate performance numbers can be taken

  • zData Engagement Manager
  • zData Database Engineer
  • zData Database Architect

Quality Assurance (QA) (3 Weeks) – The system is migrated to QA and testing begins.  For the next two weeks, the QA team is the “client” on the system and tests all aspects of functionality including performance, accuracy, security and delivery of the data.  Any changes must be communicated back to development for review and then put back through the QA process. This will establish baselines for loading, resource queues, and establish hardware consistency.

  • zData Engagement Manager
  • zData Database Engineer
  • zData Database Architect
  • ETL Scripter / Developer

Production Rollout (1 week) – The team anticipates the switch from the current system to the new system and management starts marketing the solution to the customer.  Appropriate documentation and communication must be distributed and a rollback plan should be tested.  When the time comes to “flip the switch” assure all relevant team members are on staff and available for help.  Watch the system very closely for the first week after rollout, and prepare for the first big hit of the system (i.e. Month-End Reports)

  • zData Engagement Manager
  • zData Database Engineer
  • zData Database Architect

Review, Maintenance & Incremental Enhancements (Ongoing after Production Rollout) – Reviewing comments from customers will tend to drive a lot of small enhancement requests.  Be careful not to try and make too many changes to the production system as customers are just getting used to the system and always think there is a better way of doing things.  Create a plan for how small changes are implemented and involve QA in the process so the system’s integrity is never compromised.