Data Warehouse and their stakeholders

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)):

1. 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;
2. Responsible – some stakeholders are responsible for the deliverables, generally they have been charged by management to provide a definitive outcome from the project; or
3. Consultation – some stakeholders are used as consultants like an Subject Matter Expert (SME); or
4. Informed – some stakeholders need to be kept informed, generally management who needs to know where their investment dollars have ended up or external parties.

Stakeholders do not need to know everything about the technology or even the application. A high level overview with the understanding of what is being delivered is sufficient. What stakeholders need to provide is a positive energy charge to lead the organisation through this project. Working with such stakeholders will provide the project with a boost of confidence knowing that the stakeholders are enthusiastic about this project. Given the right stakeholders in any given project, the success rate of the project will be much better than having stakeholders with judgemental bias whereby these stakeholders will reflect inappropriate reasoning compared with best practises as provided by the implementation team (Keren 1990). This behaviour is therefore considered to be incongruent with rational behaviour (Keren 1990) and these stakeholders will generally be against the project. In a project, the project team may also encounter cultural issues (Zwikael, Shimizu et al. 2005) and or personalities issues (Keren 1990) which may interfere with the project.

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:

1. a Project Sponsor;
2. the steering committee;
3. the review board;
4. the project manager;
5. the implementation team(s);
6. end users;
7. quality control.

Each member of the project team is, in fact, some type of stakeholder with respective responsibilities and interests in the project. It is crucial to ensure that all stakeholders are identified as early as possible in the project and more importantly, to engage with the stakeholders and get their ‘buy-in’ for the project. Understanding the positive and negative traits of each stakeholder will enable the project manager to work with the stakeholder to overcome any issues he or she may have concerning the project. Neglecting stakeholders especially the ones who have the accountability responsibility may lead to consistent negativity about the project no matter how highly skilled the project team was, or how good the technology platform was.

Without down-playing the roles of other members of the project team, a project without a project sponsor is most likely not going to succeed in the eyes of the client due to lack of ownership at the highest level of the client organisation.

Stakeholder management also involves ensuring a common set of understanding across the project so that success can be measured. A project is in ‘hot water’ when it shows the following traits:

1. the scoping of the data warehouse project was ambiguous and no clear sign-offs achieved;
2. unrealistic completion timeline for the data warehouse and no project plan;
3. wrong implementation or a skill-set mismatch in the development team which could lead to incompatibility of technologies used;
4. project driven by IT instead of business;
5. project manager allowing scope creep to occur;
6. data warehouse developed beyond the organisation’s maturity and capability to appreciate and utilise the wealth of information they obtained in the data warehouse.

A data warehouse project is never only about the technology. People factors and processes play equally important roles to the success of the project.
People factors take into account cultural and/or organisational change issues, process issues as well as new roles and responsibilities as a result of new technology. Project plans that incorporate change management will do far better than one that simply devotes its efforts to a ‘perfect’ implementation of the data warehouse.

Conclusion
The Data Warehouse project needs to align itself with the goals of the stakeholders and the goals of the organisation. Stakeholders needs to be comforted that their decision in embarking on this project will pay dividends (Yeo and Qiu 2003). They require the project team to:

1. obey the milestones by keeping their promises – tangible evidence of progression is visible and not just at the back-end;
2. demonstrate that the deliverables are meeting their expectations – a show and tell workshop will facilitate wonders with the stakeholders. They need to see that the project team indeed understands their requirements and that of the organisation;
3. keep within project schedule – a lot of data warehouse projects have been known to go over time and over budget and stakeholders are very well aware of this and will be monitoring this;
4. be familiar with a project management methodology – even though the project manager may have been assigned to the project, the stakeholders will still require some assurance that the project manager has indeed implemented such a system and has successfully utilised a methodology in doing so.

In the paper by Sauser (2009), it describes many reasons that attributed to the loss of the NASA’s Mars Climate Orbiter but by far it was due to poor management in addressing how to select the right approach to the project. Stakeholders will always provide input however as seen in this project, the “policy of ‘better, faster, cheaper’, led the program to its inevitable failure” (Sauser, Reilly et al. 2009).

A key factor is the project manager’s ability to strike a rapport with stakeholders and the project team. This will foster good and open communication between the team members. Communication in any project is important as there will be stakeholders with their own cognitive biases (Keren 1990) which may rail-road the discussion or the project for their own department’s or individual gain. This bias could be derived from previous exposure of projects which might not necessary be that of the current project.

Building a data warehouse is not then just about the technology. It requires a lot of understanding of who the stakeholders are, knowledge of what the client is after, the approach and methodology and knowing the limitations of the project team. Once these are understood, the project can then be mapped to provide the project plan with milestones.

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.