Data warehouse risk management – risk identification

Data warehouse projects are highly complex, and as such, are inherently risky. It is the responsibility of the project manager to lead the data warehouse team in identifying all risks associated with a particular data warehouse implementation. The goal of this process is to document all essential information relating to project risk.

For additional information relating to risk, refer to the Project Diva article on project risk identification and management.


Risk ID








Impact Description


Possible mitigation






Loss of project sponsor


Impending reorganization


Scope, budget, staffing, schedule issues


Identify secondary sponsor. Review project requirements with






General lack of experience with toolsets, methods and best


Potential for huge margins of error in budgeting and scheduling;
project delays; deliverables not fit for use


Strong resource management plan; clearly defined project
responsibilities; recruiting staff with DW experience; off-site training;
professional consulting






Wide range of users driving system requirements


Conflicting user requirements


Scope creep; application not meet user requirements; marginalized


Ensure high level of user involvement; requirement






Changing system requirements


Impending reorganization; new product development; staff


Schedule delays; system not meet business


Change management process; project sponsor






Inadequate Budget


Project delay; scope scaled back; not meet business


Research; professional cost estimation; contingency budgeting; sponsor






Unrealistic schedule due to initial estimates / poorly understood


Large initial delays; evidence of tasks excluded from


Project delay; quality issues due to rushed delivery or exclusion of


Research; sponsor support; professional






Disconnect between business objectives and project


Changing business objectives; change in management; market


Product not fit for use; no ROI


Proactive alignment of project with business objectives; active
stakeholder management; prototyping






Scalability issues due to huge amounts of data, changing


Poor system performance


Data access issues


Estimating toolsets; technical design completed by experienced






Support issues; heterogeneous environment; new


Staff turnover; staff currently not trained on


System unavailable


Administrator training; staff training budget; DR






Poor data quality


Useless datasets; not meet business requirements; system not


Data quality review sub project; data cleansing; implement known clean
data first; metadata quality tags (e.g. “questionable,” “not yet






End user technical skills too low


Implement canned reports and templates; user involvement in front end






Vendor issues


Budget; project delays


Verify vendor financial viability; vendor






User rejection


System not used; users express dissatisfaction during training,


High level of user involvement; prototyping; user feedback incorporated
into project; user training


Data Warehouse Risk Identification (.doc format)

Call Center Setup Project Planning

Call Center Setup

Call center models range from the simple internal IT help desk, to a fully staffed customer care department, to the more complex multi-channel systems with IVR (Intelligent Voice Recognition) and ACD (Automatic Call distribution) call handling.

All call centers will require software to track and manage customer issues, a voice and data network to support the software, and adequate staff to handle call volume.

The following project documents cover varying aspects of call center setup and provide a project management framework for successful deployment of a call center.

Project Documents

Call Center Software Setup Example WBS

Call Center Software Requirements Definition

Call Center Setup Project Risk Matrix

IT Disaster Recovery Project Objectives

  • Document all existing IT practices, procedures, standards and guidelines by June 2016.

  • Inventory and document all IT systems, software and supporting network infrastructure by July 2016.

  • Identify and document all 3rd party IT service and support partners; provide contact information and copies of associated contracts by July 2016

  • Establish an IT Disaster Recovery Committee to review accepted practices, procedures, standards and guidelines defined as a result of this project and prioritize importance of IT systems by August 2016.

  • Establish a formal and documented Disaster Recovery Program by September 2016.

  • Establish a redundant data center, and deploy those services identified as high priority by the Disaster Recovery Committee by October 2016.

  • Deploy those services identified as medium priority to the redundant data center by December 2016.

  • Implement Maintenance and Operations plans that ensure on-going, annual review of the IT Disaster Recovery Programs established by this project by December of 2016.

  • Develop and distribute IT Disaster Recovery Plan documentation to management and staff members identified by the Disaster Recovery Committee by December of 2016.

Website Development Contract Considerations

Aside from the standard clauses (liability, force majeure, cancellation, etc.), a website development contract should specifically address the following:


Many website development contracts will be signed before the project scope has been fully defined. In cases such as this, the contract should require the development firm to fully document project deliverables, budget and schedule before formally beginning work on web site. Contractually, this could be considered the first project milestone. If this milestone is not reached (and the contract would need to specify criteria for acceptance of this and all project milestones), then the contract would be void.

If a scope of work has been developed, then, as part of the project plan, the project deliverables need to be included in the website development contract. The scope of work includes all work to be done as part of the project. Items not specifically included in the scope of work are considered out of scope and would be addressed as part of a change management process. A website development project scope of work might include:

  • Design – site graphics, layout, color schemes, logos, images, illustrations, maps, etc. If these are to be developed by an external design studio, then issues of copyright and use will specifically need to be addressed as part of a development contract. If the art works are to be provided by the customer, then the contract should specifically state this. The contract should specify the designs to be provided in as much detail as is possible. For example, “the development house will design 3 proof logos based on existing marketing materials and corporate color schemes for review by the client.”

  • Content – content includes all text, media, downloads. Content development is perhaps the most time consuming task in developing a web site. Content is extremely important! Sites that plan on deriving revenue from traffic will need content to attract and retain site visitors.

  • Supporting applications – most websites will utilize applications to support content delivery and information collection. These may include bulletin board systems, forms, database systems, shopping carts, product catalog management systems, etc. Many of these applications are available as open source. The website contract should specify the source of the applications, whether open source or custom development and document any license restrictions or rights associated with these applications. In instances of custom development, license and right to use should be specified in the contract.

Change Management

Change management procedures outline how changes from the initial scope are handled by both the service provider and the customer. Most change management policies call for documenting the nature of the change and allowing time for proper evaluation of the costs of change and subsequent impacts on schedule, quality and risk. In the case of a website development contract, particular attention should be paid to managing design changes, as these can be both time consuming and expensive.

Project Responsibilities

A responsibilities clause provides clarity to the various roles and responsibilities of team members and management involved in the website development project. If the client is responsible for generating content, for example, then this should be documented under the responsibilities clause. The contract should cover at the very minimum: design, media and content sources, search engine optimization, testing, maintenance, hosting.

Payment Terms

Most contracts that cover a technology deliverable will use milestones for determining the payment schedule. It is essential that these milestones be clearly defined, with documented milestone acceptance criteria. An example milestone for a website development contract might be delivery of design proofs, completion of content, or successful testing of a data management application.

User Acceptance Testing

Testing is essential, as a company’s website is often the first interaction that a potential customer, partner or employee has with the organization. Like all company documents, sales and marketing materials, the website must be free from error. Completion of testing should signify a project milestone.


A warranty period will ensure that underlying web applications, components, scripts and other site developments are free from error for a period following project sign off by the client. The contract should detail the specifics of the warranty (e.g. length of warranty, what elements are covered by the warranty, time frame for remedy and what costs, if any, will be incurred by the client in the event that warranty repairs are required).

Ongoing Responsibilities

If the development house is responsible for site maintenance, then a regular maintenance schedule should be included in the contract, as well as a listing of the items which are covered by the maintenance agreement (e.g. data archiving, product catalog updates, content updates, design refreshes).


In addition to underlying web applications, scripts and source code, the contract will need to cover copyright of site design, logos, graphics, illustrations, images or other media produced for the website.

Project Timelines

The development contract should specify in as much detail as possible the proposed delivery schedule. If a formal scope of work has not yet been established, then defining a project timeline will not be possible. Rather, the development contract should be used to specify expectations and state that as part of the formal project scope, a project schedule will be created for the client to review.

The most important part of the website development contract and procurement process is having a legal expert who is familiar you’re your business and the project review the contract!

Project Risk Register

The Project Risk Register is a summary risk document. The risk register should contain a listing of all sources of risk, risk impact, risk probability, contingency plans, risk owner and the status of the risk. The risk identification, impact assessment and risk ranking, contingency planning and project execution tasks are all inputs to this document.

The risk register should be actively maintained throughout the project. The below example project risk register is based on a generic website development project.

Risk ID




Risk Impact


Impact Description


Risk Probability


Risk Severity


Risk Contingency


Risk Owner






Content will not be available when required 



Missed deadline will result in funding cut. 





Hire additional copy editors 


Currently recruiting for additional staff 



Project resources may be reallocated for other (higher) priority



Resources are currently 100% committed to this project. Losing a
resource would severely delay project. 





Work with Portfolio Manager to ensure resource availability 


Portfolio Manager will not reallocate staff. 



End users may be resistant to new site workflow 



Customer feedback was instrumental in site design, but not all
customers will like the site changes. May result in bad publicity or
customer satisfaction issues. 





Implement online help facility. Provide additional customer support
staff for transition. 

Support Manager 

Additional staff will be brought online 1 month prior to release.
Online help facility added as change request. 



Data loss 



Data migration may result in loss of customer data. Customer data is
key for day to day business operations. 





Revisit backup procedures. Execute manual backup prior to



Call Center Software Project Requirements Definition

1. General Call Center Software Project Requirements

1.1. Scalable to support multiple call center locations
1.2. Track both inbound and outbound customer communications

1.2.1. Provide performance metrics and reporting on call queue
1.2.2. Provide performance metrics on staff call handling
1.2.3. Associate all communications with appropriate customer account(s) Maintain log and provide management and center staff access to historic call data

1.3. Call Center software must integrate with CRM (Customer Relationship Management) application

1.3.1. Support screen pop based on dialing number for existing customers

1.4. Call Center software must integrate with Billing System
1.5. Call Center software must integrate with Help Desk application to

1.5.1. Track and manage open issues
1.5.2. Escalate and/or dispatch issues to appropriate department (e.g. level II support, engineering, management)
1.5.3. Support the work order management process
1.5.4. Provide incident statistics and management reporting

1.6. Call Center software must provide Knowledge Database

1.6.1. Automatically update knowledge database with issue and resolution information
1.6.2. Provide administrator facilities for managing knowledge database
1.6.3. Knowledge database should be searchable and available to customers via the WWW

1.7. Call Center software Quality management

1.7.1. Support the ability monitor calls for call quality
1.7.2. Support the ability to record calls

1.8. Comply with e-911 standards and provide support for lawful intercept

2. Call Center Software Email Routing Requirements

2.1. Support intelligent routing based on customizable rules definition
2.2. Ability to associate email with customer account

3. Call Center Software Voice Routing Requirements

3.1. Use ACD (Automated Call Distribution) and IVR (Intelligent Voice Routing) to direct calls
3.2. Use Auto Attendant features to greet customer based on time of call

3.2.1. During business hours
3.2.2. After business hours
3.2.3. Holiday
3.2.4. Outage notification
3.2.5. Special announcements

3.3. Routing, Auto Attendant, new extension setup should be manageable by in house technical staff
3.4. Support WWW to phone call center applications

Example Project Assumptions for a Data Migration Project

Example Project Assumptions for a Data Migration Project.

Data Migration projects, especially those across platforms or into new database structures, are inherently complex. Identifying project assumptions early in the project planning process is necessary to facilitate the scope of work definition. Assumptions should be documented clearly, without use of department specific acronyms or terminology which might not be understood by all members of the project team. Project assumptions, especially those initially identified by the Project Manager without input from the rest of the project team, should be distributed to the whole team as early in the project planning process as is reasonable.

Example Billing Project data migration project assumptions

  • Business rules relating to billing processes (e.g. invoice cycles, pro-rating logic, re-connection and other fee structures) remain the same. A summary of used business rules will be distributed by the Finance Department.
  • Data for active billing subscribers will be migrated. As at (date), there are 1000 active subscribers.
  • Data for recently disconnected subscribers will be migrated. As at (date), there remain 250 inactive subscribers. Given current churn rates, there is a high probability that 75% of these currently inactive subscribers will request re-connection.
  • Data for customers with an account balance (debt or credit) will be migrated.
  • Data for customers with un-returned equipment will be migrated
  • Data for customers currently in the collections queue will be migrated.
  • Data to be migrated includes (refer to data dictionary for format and detailed description of data to be migrated):
    • Customer name
    • Customer contact details
    • Customer billing package details
    • Customer equipment details
    • Customer invoices generated since (date)
    • Current, 30, 60, 90, > 90 day balances
    • Notes on customer account
    • Service call history details
    • Method of Payment details (Credit Card, Direct Deposit details)
  • Data to be migrated must be exported and cleaned before formatted for import into new platform. Cleaning can be completed by the Customer Service team before the end of (date).
  • Data transformation can be completed by the Billing Administration department.
  • The transformation tools identified and tested by the Billing Administration department will be adequate for the scope and duration of the project.
  • Existing and new platform documentation is accurate.
  • Internal staffing resources will be made available to complete required system testing.

Data Center Relocation Work Breakdown Structure

The purpose of this document is to provide project managers and team members with an overview of the requirements for a data center relocation. This data relocation plan document can also be used as a checklist in support of an existing data center relocation project.

1.1. Data Center Relocation Project Management

1.1.1. Scheduling

1.1.2. Procurement Management

1.2. New Data Center Requirements Definition

1.2.1. Business Service Level Agreement Insurance

1.2.2. Technical Current Data Center Inventory Communications Migration Requirements Contract Review New Data Center Rack Diagrams Communications Interconnects Cabling Power Environmental Controls Security Access

1.3. Acquisition

1.3.1. New Data Center Site Visit Contract

1.3.2. Hardware Issue RFP Selection Criteria Purchase

1.3.3. Communications Data Interconnect Voice Interconnect

1.4. Installation Prerequisites

1.4.1. Resource Allocation

1.4.2. Notifications Internal Customer

1.4.3. Site Preparation Circuit Cut Over Plan Rack Space Allocation Power Cabling Network IP Allocation

1.4.4. Testing

1.4.5. Configuration Backups

1.4.6. Detailed Installation Documentation

1.5. Migration

1.5.1. Hardware Installation Testing

1.5.2. Routing and Switching Cut Over Testing Cancel Circuit to Old Data Center

1.6. Operations Switch Over

1.6.1. SLA monitoring

1.6.2. Documentation

1.6.3. Disaster Recovery Testing

Microsoft Office Format of Data Center Relocation Plan Work Breakdown Structure

Office Relocation Example Risk Matrix

This example risk matrix uses the Office Relocation project assumptions and Office Relocation work breakdown structure documents as input. This is not an
exhaustive list of all Office Relocation project risks and may not be applicable to your particular project. Rather, this matrix is intended to provide a framework for
identifying, prioritizing and managing risk.

Risk Description




Mitigation Strategy

Priority Scale 1-5 (5 = most severe, greater probability)




Technology:  Data and/or Voice circuits will not be available by (date).  Company will not be able to communicate. (Note A)




1. Contact wireless solution vendor as redundant provider.
2. Seek alternate fixed data / voice provider
3. Allow employees to work from home
4. Extend existing lease by 1 mo nth to provide additional circuit implementation time.

Operations:  Inadequate insurance.  Company may be underinsured.




1. Check coverage
2. Review policy

Construction:  Construction build not complete by (date) (Note B).  Company will not be able to relocate according to schedule.




1. Delay lease termination notice

Construction:  Construction deficiencies.  Office environment may be hazardous.




1. Construction warranty
2. Phased payments
3. Use known good contractor
4. Request inspection

Move:  Equipment breakage.  Core networking gear and/or peripherals would need to be replaced.




1. Adequate packing
2. Hire professional packing/moving company
3. Employees responsible for laptops
4. Ensure spare equipment available

Note A: Historically, vendor has had difficulty deploying high speed circuits to this part of town.
Note B: Project is currently 1 month ahead of schedule. However, project is complex, so some delays are expected.

For additional reference, review the Project Risk Register and Risk Impact and Probability Assessment documents.

Trade show risk planning, identification and management

Trade shows are a fantastic opportunity for companies to showcase new products and services. If a show is well planned and managed, companies can expect to meet numerous potential customers and generate strong sales leads. A poorly planned and managed show, however, can tarnish a company’s reputation and provide a poor return on investment.

As part of the trade show project planning process, the project manager must lead the show team in identifying all risks associated with the trade show. The goal of this process is to document all essential information relating to project risk.

The below information is intended to assist in this trade show planning process and is not intended to be a complete risk assessment. Each company will have unique business objectives supporting with the trade show project. The risk identification process must support these business objectives

For additional information relating to risk, refer to the Project Diva article on project risk identification and management.

Risk ID




Impact Description

Possible mitigation



Poor event turnout

Unforeseen conditions may also contribute (e.g. weather,

Poor ROI; minimal sales leads; poor sales; over-purchase of give-aways,

Vetting of show venue; show attendee profile; purchase re-useable
give-aways; marketing campaign to target specific key



Poor ROI



Define measurement of show success; clearly define show goals and



Lack of site traffic to booth

Booth location


Staff to physically direct potential customers to



Trade show costs limit booth location and size options

Limited budget

Reduced traffic to booth; reduced sales leads; poor ROI

Consider partnering with a supporting product vendor; show business
case analysis



Manufacturer delay in shipping show materials to home


Materials not available for show; negative credibility

Research and identify alternative vendors; order materials



Booth/materials damaged in shipping to show venue



Professional packing and unpacking; contingency plan for display;
verify insurance coverage



Personnel not available; show marketing and/or execution plans are too
labor intensive.


Negative credibility; technical trade show staff are unavailable to
support normal business operations

Schedule at least 1 month in advance; identify and train alternative
staff; financial incentives



Technical display failure


Poor sales; negative credibility

Full system testing; budget for and bring redundant



Demo errors


Negative credibility

Full system testing using multiple test groups



Useless prospect data gathered from show


Poor ROI

Standardized forms; staff bonus based on data



Positive risk of overselling units


Unable to deliver on time

Review historical trade show sales records;

Trade show risk planning, identification and management (.docx format)