Building a data warehouse is not a simple task and should not be done by one person alone. Since data warehousing is best integrated with business practices and information systems technology, a successful data warehouse implementation requires constant coordination of both aspects to balance all of its needs, requirements, tasks and results. I would be happy to share with you the methods I used to plan and manage any database project, including transaction databases, data warehouses, and hybrid databases. Because I live in relational databases and data warehouses and in the process of data extraction, transformation, and loading (ETL) to support them, I focus on these areas to discuss my approach. However, you can extend these methods to the entire stack--olap cubes and information transfer applications such as reports, profiling (Ad-hoc analysis), scorecards, and dashboard presentations.
I'm not eating. To tell a real project manager (PM) How to do his or her job, instead, I write these for database administrators and developers who have no good luck working with experienced project managers, and also for IT professionals who are suddenly asked to "build a data Warehouse" and need to play the role of project manager. My discussion will not be complete, but I hope this will give you enough information to get your project ball rolling.
As shown in Figure 1, the Data Warehouse project has 3 tracks (tracks): Data orbit, technology track, and application layer track. When you are organizing any database project plans, I recommend that you manage and synchronize your activities with these three tracks as templates. You can also use Figure 1 as an advanced profile when you explain your plans to technical decision makers (TDMS), business decision makers (BDMs), and all other data Warehouse project participants.
Using a lifecycle management approach
I encourage you to take advantage of the resources your organization can provide, such as the technologies and methodologies for designing, developing, and deploying systems and software. If your company does not use any formal approach to these tasks, move on, and you can use the 7D database lifecycle management method I developed for my own database project (Discover, design, develop, Deploy, day to day, defend, De Commission), nickname "7D method".
My "7D" Database Lifecycle management approach is about database lifecycle management, not the lifecycle of related software (applications) and hardware. Figure 1 includes the software and hardware tracks, but I will not elaborate on their management. In order to successfully implement the database lifecycle, it is necessary to adjust and synchronize the milestones, hardware, and application software for the database life cycle.
The building of a data warehouse never really ends. Unlike traditional databases that remain relatively unchanged for a period of time after deployment, data warehouses are constantly changing to cope with changes in the business environment it serves. Today's business environment is more complex and involves changes that are faster than ever before. Dealing with this almost constant change is one of the biggest challenges for businesses. This is why everyone in the data warehousing team, including technology decision makers (TDMS) and business decision makers (BDMs), must be on the same front, using the same lifecycle management approach to make their knowledge fully unified. Only in this way can it be possible to adjust the data warehouse, the concept and the purpose of the enterprise. In Figure 1, I have shown the 7 steps of my 7D method, which will lead you through each step.