View online: tdwi.org/flashpoint
October 6, 2011
ANNOUNCEMENTS
Submissions for the next Business Intelligence Journal are due December 2. Submission guidelines
New TDWI Checklist Reports: Seven Steps to Implementing Data Discovery and Real-Time Data Quality
CONTENTS
How to Build an Effective Data Warehouse Project Team
Competency Centers and Similar Organizational Structures
Mistake: Inaccurately Assessing the Maturity of the Current Environment
See what's
current in TDWI Education, Research, Webinars,
and Marketplace
How to Build an Effective Data Warehouse Project Team
Patty Haines
Chimney Rock Information Solutions
Topic:
Data Warehouse Projects
One of the critical success factors for a data warehouse (DW) project is the effectiveness of the data warehouse project team. This team determines the infrastructure, DW architecture, ETL architecture, sources and data to be populated, and the query tool interface for business users--and it plays a key role in the quality and timing of this important project. The most effective project team works as one unit--discussing, sharing, and working through ideas and issues on a daily basis.
The following guidelines will help you build a successful team that is capable of delivering a quality data warehouse that meets the business users’ needs, as well as the schedule and budget.
1. Team member selection. The project team should be created as a unit, rather than by selecting individuals because they are in the right functional area. Choose staff with the required skills and who will fit within a team environment. The most effective project team will contain people who are able to work with others and who understand the importance of interacting regularly with others on their team.
This may be difficult in an organization that normally assigns people to work on individual support tasks. In this case, the data warehouse project team may need to function outside the normal organizational units to allow it the flexibility of building team cohesiveness.
2. Use experienced data warehousing professionals. An important strategy in the selection process is to choose team members with experience in data warehousing projects. There are numerous differences between a DW project and an OLTP operational system, which makes it important to work with experienced data warehousing staff. If this is not possible, then a good practice is to create a team with a few experienced DW professionals and others who are new to the concept. This will help the newcomers complete their project tasks while learning about the project and data warehouse from more experienced team members.
3. Small and nimble. Create a project team as small as possible so it can be nimble with only one level of management. A good approach for the project team is to have a flat organization with each team member reporting directly to the project manager for the completion of the project. This direct contact helps the project manager keep track and monitor individual project tasks and allows the team members to have more input and quickly highlight issues that are preventing them from completing tasks.
It is still important to have a lead data modeler and lead ETL architect/developer to design the common footprint and technically guide the modelers and developers through the project steps.
Using a smaller team may also help the team define smaller increments that may have a higher chance for successful implementation. This should also help provide the business users with continual new capabilities within a shorter time frame as the DW program moves forward.
4. Responsibility matrix. A key document that project team members should create together is a RACI (responsible, accountable, consulted, and informed) diagram to clarify roles and responsibilities within the project. This diagram will help team members understand their roles and what is expected of them. It will also identify any outside assistance that will be needed as the project progresses.
5. Project plan and methodology. The project plan is another key document for the project team and should be based on a solid data warehouse methodology. This plan should be built with team members so they understand the methodology and how the data warehouse will be built (i.e., the steps to completion and who performs each step). This plan should also be reviewed with team members individually to review each task’s assignments, milestone dates, and duration. Each team member will then understand the project deliverables, time line, and dependencies of their tasks within the project plan.
After the plan is finalized, it should be used to direct and track the work of team members. Using functions such as notes and percentage complete will help document the progress of each team member from week to week. Setting a baseline is also a good idea if dates need to be adjusted; the original time line can then be compared to the new one and tasks that caused the delay can be easily identified.
6. Project room. Dedicating a project or “war” room for the team will help team members work as one unit for one common goal. Here team members can discuss and work through ideas without impacting others within the organization. This room should have whiteboards and paper pads where notes can be stuck on the wall for future use. Team members should be able to leave designs on the whiteboards so others on the team can review and provide input.
7. Conduct effective work sessions. Training team members to facilitate work sessions should be completed early in the project so each team member can help move the project forward when design or development issues arise. Work sessions need a purpose and a goal--and the activities in the session need to help attendees accomplish the purpose and reach the goal. Develop a list of ideas first and then work through each one to clarify the idea and identify the advantages and disadvantages of each. Make sure items that are skipped are put on a “parking lot” list to address later on. It is easy to get involved in multiple issues within work sessions, and sometimes the issue that was supposed to have been resolved does not even get addressed. It will be important for team members to understand how to use meetings and work sessions as efficiently as possible.
The data warehouse project team is one of the most important keys to a successful data warehouse project, and yet many times the team is just thrown together with people who are available. There are also times when the team is asked to move forward with the project as soon as possible with little knowledge of what they are trying to build, how they will build it, and the steps involved. Taking the time to build a project team will, along with the planning tools, help the team be successful in building and implementing the data warehouse--meeting the project goals on time and within budget.
Patty Haines is founder of Chimney Rock Information Solutions, a company specializing in data warehousing and data quality. She can be reached at 303.697.7740.
Highlight of key findings from TDWI's wide variety of research
Competency Centers and Similar Organizational Structures
TDWI Research both champions operational data integration and fears it. The problem is that TDWI has seen many organizations accelerate OpDI work by diverting people, tools, and other resources from data warehousing and business intelligence teams. In the process, mission-critical BI work is delayed or derailed completely. To test whether these fears are real, TDWI Research asked: “Have you seen work in business intelligence or data warehousing disrupted because its team was assigned to work in operational DI?” A resounding 58% said “yes,” proving that TDWI’s fears are well founded. So, a challenge organizations face is to grow OpDI by incorporating best practices in data integration learned from related disciplines like AnDI, DW, and BI, but without scavenging resources from those disciplines. Managers of data administration groups have voiced similar concerns, so it seems that the growth of OpDI is stretching resources in many places.
A knee-jerk reaction to this problem is to find funding and give OpDI its own dedicated staff, tools, and other resources. The strongest argument against dedicated staffing is that a lot of OpDI work is intermittent or seasonal, so it’s difficult to keep permanent staff engaged continuously. Indeed, this is true in some organizations, but not in all. To get a sense of how continuous OpDI work is, TDWI Research asked: “In your experience, which of the following best describes the frequency of operational DI work?” (See Figure 9.)
(Click for larger image)
Source: Operational Data Integration: A New Frontier for Data Management (TDWI Best Practices Report, Q2 2009). Access the report here.
FlashPoint Rx prescribes a "Mistake to Avoid" for business intelligence and data warehousing professionals.
Mistake: Inaccurately Assessing the Maturity of the Current Environment
By Mary Beth Kush
Many road map projects begin because the organization feels the need to improve the maturity of its BI capability. Organizations that want more sophisticated architectures need to take an honest assessment of the current state. For example, if they do not have--or follow--basic version control practices, then striving to implement predictive analytics or a service-oriented architecture (SOA) may be too aggressive and unrealistic.
Consider the following when assessing the maturity of the BI architecture:
- Standardization--includes basic configuration management (such as version control processes, separating development, test, and production environments, and processes for quality assurance and defect reporting). Standardization also includes processes that allow business users to request reports and access data.
- Consolidation--includes the ability to consolidate data in a structure (such as an operational data store or a data mart), to identify and correct data anomalies, and to develop rudimentary business intelligence.
- Integration--provides a unified view of the data and can be real time (via concepts such as data virtualization or operational BI). Business concepts such as having one view of a customer can be achieved here.
- Extensibility--improves business agility and enables integrating processes as well as data. Extensibility usually refers to an SOA and involves systems as well as data.
Other maturity models have been published that are specific to BI. Regardless of which maturity model you choose, it is critical to take an honest and realistic assessment of your current state.
Source: Ten Mistakes to Avoid When Creating a Business Intelligence Road Map (Q2 2008). Access the publication here.
