Data Warehouse Identifying Stakeholders

This is probably one of the most critical factors in Data Warehousing to identify who the stakeholders are and when do you need input from them at what stages?

Most projects get dragged along because the stakeholders and what they role is in the project were not clearly defined. I have some basic Rules I apply when creating a stakeholder matrix:

A stakeholder is a person who has a direct or indirect stake in the organisation. From a project point of view, stakeholders can be categorised by various responsibilities (SMART RACI + Matrix (Hartman 2001), (Hartman and Ashrafi 2004)):

Accountable – some stakeholders are accountable for the success of the entire project or a particular phase of the project, generally they are the departmental or divisional managers or;

Responsible – some stakeholders are responsible for the deliverables generally they have been charged by management to provide a definitive outcome from the project; or

Consultation – some stakeholders are used as consultants like an Subject Matter Expert (SME); or

Informed – some stakeholders need to be kept informed, generally management who needs to know where their investment dollars have ended up or external parties.

In a Data Warehouse implementation, it is generally the stakeholders that have requested the need for decision support. Therefore it is assumed that stakeholders will be key supporters of the project as they have most likely been the ones who have identified the initial requirements for the Data Warehouse. Stakeholders require tangible outcomes that they can measure, trust and quantify consolidated data. This is important to stakeholder(s) as this will provide them with the ability to follow through with the decision making process (Westerman 2001).

A project team will generally consist of:

• a Project Sponsor;
• the steering committee;
• the review board;
• the project manager;
• the implementation team(s);
• end users;
• quality control.

But one of the questions that always appears is what is the defining roles, in my years of experience these roles are usually needed and must be identified:

• Source Data Owners
• Information Owners
• Process Owners
• Marketing
• Legal & Security
• Data Quality
• Architecture
• Infrastructure Owners
• Data and Information Consumers

These user roles will have to sign off certain sections and will have to take ownership of that section in order for a proper implementation.

Let's look a each role and when they play a part in the normal life cycle of the data warehouse:

Source Data Owners: They are always in Data Warehouse projects as they will provide the data and also when there is fixes that needs to be done they will implement it on the source side so that the fix are reflected correctly through the process. Without them the project will fail, if the data that is supplied is not from the original owners, you might just get a penalty fee or the data flow might stop. They are usually heads of system or processes in a organisation. They will be involved throughout the life cycle. Sign-off is required on all documents.

Information Owners: I have made information owners as a separate role as they translate the raw data from the source into more understandable decision support systems, they are identified usually by the business rules that are applied to the data and they will also own the business rules. They are key to the project because they need to approve all the translation and business rules that are applied on the source data. They too are heads of the MIS teams. Their major involvement will be in the Business Requirements cycle. Sign-off are required on the requirements and end results (UAT)

Process Owners: The process owner is responsible for designing the processes necessary to achieve the objectives of the business plans that are created by the Business Leaders. The process owner is responsible for the creation, update and approval of documents (procedures, work instructions/protocols) to support the process. Many process owners are supported by a process improvement team. The process owner uses this team as a mechanism to help create a high performance process. The process owner is the only person who has authority to make changes in the process and manages the entire process improvement cycle to ensure performance effectiveness. This person is the contact person for all information related to the process. This person is accountable for the effectiveness of the process. They play a role in where the data and information touches the process, sometimes documents become obsolete because the process get automated through the data and information. The process owners are involved  in the Requirement and Design of a project. Sign-off are required on Requirements and design.

Marketing: This is a interesting factor in a data warehouse, but in major corporation there is a corporate identity that governs how the look and feel will be. Because there are reports and dashboards that end users will see and even outside clients an see the reports, marketing must be involved in the requirement and report design, they will govern the colours, layout, graphs logos, fonts and sizes of all the reports. Sign-off is required in the Requirement and Design phase.

Legal & Security: Their roles will be involved if there are legal ramification in exposing the data, this includes disclaimers on reports and what data and information consumers will be able to see. In South Africa there is the POPI Act that acts on the Personal Information broadly means any information relating to an identifiable, living natural person or juristic person (companies, CC’s etc.) and includes, but is not limited to: contact details: email, telephone, address etc.; demographic information: age, sex, race, birth date, ethnicity etc.; history: employment, financial, educational, criminal, medical history; biometric information: blood type etc.; opinions of and about the person; private correspondence etc. Sign-off is required on the requirements and UAT phases

Data Quality: Data quality owners are a definition in bigger organisations where the quality of the data and information cannot be alone controlled by the source data and information owners. I have separated them as the quality of data are becoming more and more important in organisations, sometimes there are different source systems with the same data and thus data quality experts must ensure that the true and best source of data quality will come from that system, they are also involved in master data management and also they are beneficial to have if it comes to rules that needs to be verified in the translation of data into information. Sign-off is optional on Requirements.

Data Warehouse Architects: They are involved in the initial stages of projects and data model design stages, this role will govern the implementation of projects. They play key roles in data warehouses as they need to ensure that the data warehouse complies with laws, and best practices and also to ensure that the data warehouse will be able to consume the new data and that overall integration and re usability of code will be used in the process of data integration. A data architect in Information Technology is a person responsible for ensuring that the data assets of an organization are supported by a data architecture that aids the organization in achieving its strategic goals. The data architecture should cover databases,data integration and the means to get to the data. Usually the data architect achieves his/her goals via setting enterprise data standards. A Data Architect can also be referred to as a Data Modeler, although the role involves much more than just creating data models.The work profile is related to Data Modeler. Sign-off is required in the Project initiation and the Design phases.

Infrastructure Owners: Their role might fall in with the Data Warehouse Architect, but for clarification I will separate them. They will be involved in the operations of the data warehouse as they will provide the hardware and software on which the solutions will be supplied on. Their involvement in project are more with capacity planning of total data warehouses. Sign-off is optional in design, but they will need to be notified of the data coming into the infrastructure and requirements for future.

Data and Information Consumers: These are the end users that will act upon the data and information either as operational response or making decision on the data, their input is valuable in a project as they will show the success of a project by the use of the reports and/or dashboards and/or data. The project is initiated to answer their needs and questions and to help them do their jobs better. Sign-off is required at the requirements and UAT phases and final acceptance in production.

Now that I have highlighted some of the roles in a project lets have a look at some questions in the requirements.

How will you identify the data warehouse project stakeholders?

This should be done by listing methods such as conducting brainstorming sessions or interviews, process modeling, identifying use cases and creating and analyzing surveys and questionnaires. Data warehouse project stakeholders will include any person, group of people or department that may be affected by the project. For example, a data warehouse project stakeholder could include members of the data warehouse analysis team, front-line managers who request specific reports from the information housed in the data warehouse or the information system engineers who design data queries.

What methods will you use to elicit business and stakeholder requirements?

This should be done by discussing requirements gathering techniques such as document analysis, conducting requirements workshops or focus groups, observing or job-shadowing individuals who interact with the system and process data warehouse information requests regularly, and diagramming interface analysis. Business requirements can include efficiency and cost reduction; stakeholder requirements can include the ease of system usability.

What domain knowledge or experience do you have with a data warehouse?

Experience with or knowledge of the domain, or the problem area undergoing analysis, may or may not be a requirement for the job. Some data warehouse systems are proprietary, or specific to a particular organization. Knowledge of the particular data warehouse system can be gained through study of manuals and discussion with subject matter experts.

How would you manage change requests in a data warehouse project?

This should be done by discussing the steps involved in managing change requests after project requirements have been defined. Steps should include establishing the process and wording for requesting a change, determining who has authority to authorize changes and analyzing the impacts of the change on the project, including budget and effort, the benefits and risks associated with the change and how the change will be prioritized and tracked.

References
Hartman, F. a. and R. Ashrafi (2004). "Development of the SMART Project Planning framework." International Journal of Project Management 22(6): 499-510.

Hartman, F. T. (2001). "Don't Park Your Brain Outside - A Practical Guide to Improving Shareholder Value with SMART Management." International Journal of Project Management 19(8): 486-488.

Keren, G. (1990). Cognitive aids and debiasing methods: Can cognitive pills cure cognitive ills. Cognitive biases J. P. Caverni, J. M. Fabre and M. Gonzalez. Amsterdam, North-Holland, Elsevier Science Publishers: 523-555.

Sauser, B. J., R. R. Reilly, &, et al. (2009). "Why projects fail? How contingency theory can provide new insights – A comparative analysis of NASA’s Mars Climate Orbiter loss." International Journal of Project Management Available online 14 February 2009: 15.

Westerman, P. (2001). Data Warehousing: using the Wal-Mart model, Academic Press.

Yeo, K. T. a. and F. Qiu (2003). "The value of management flexibility—a real option approach to investment evaluation." International Journal of Project Management 21: 243–250.

Zwikael, O., K. Shimizu, and, et al. (2005). "Cultural differences in project management capabilities: A field study." International Journal of Project Management 23: 454–462.