Joyce Norris-Montanari, CBIP-CDMP, is president of DBTech Solutions, Inc. Joyce advises clients on all aspects of architectural integration, business intelligence and data management. Joyce advises clients about technology, including tools like ETL, profiling, database, quality and metadata. Joyce speaks frequently at data warehouse conferences and is a contributor to several trade publications. She co-authored Data Warehousing and E-Business (Wiley & Sons) with William H. Inmon and others. Joyce has managed and implemented data integrations, data warehouses and operational data stores in industries like education, pharmaceutical, restaurants, telecommunications, government, health care, financial, oil and gas, insurance, research and development and retail. She can be reached at jmontanari@earthlink.net.
Let’s get this out of the way: EVERY PROJECT HAS ISSUES at one time or another. Sometimes a technical issue may need to be communicated to the project manager, escalated to gain resolution or just communicated within the project team. I seem to always hit issues during testing, and these issues never fail
Issue management defines the process of documenting and escalating any issue that the project may encounter during development, testing and implementation into production. The process document could include the following: 1. How does the project find the issue? Usually, an issue is reported by one of the business users or conversion
It is important to review any existing documents (maybe from previous projects) before re-inventing the wheel (standards and guidelines). My preference is to review existing standards with my customer and recommend any enhancements or additions that may be required for the conversion project. Consider locating the following: 1. Infrastructure guidelines - Usually
I don't know about you, but I've been on multiple conversion projects where the scope changes – especially during development. It's not that the requirements were not gathered properly; the requirements changed! The business changes and people change, so the requirements can change on large conversion projects. I like to create scope documents
I don't know about y'all, but I have quite a few customers embarking on some type of conversion. Some are converting from one CRM software system to another CRM solution, and others are doing database conversions. Whatever type of conversion you are doing, you may want to consider conducting a "readiness" in
THIS IS HARD TO DO! In our agile world we seem to never get the data model completed until two weeks after we are in production, and every project plan wants to waterfall the completion of this deliverable. I think it may be due to the rapid way we gather and refine requirements. For
How many meetings have you been in where the technical personnel start talking about the database, sizing, storage, partitioning, indexes, staging, ETL, programs, operations or performance – and the business users in the group look perplexed? When you're meeting or gathering requirements with business users, "techno lingo" can sure make
How many of you still use data modelers for projects? Well, there are quite a few companies that still use data modelers. In fact, a good data modeler is hard to come by for most consulting firms. I would never tell you that I am the BEST data modeler in the world,
When I walk into a customer’s office and they tell me that IT is the business’ consultant – BUT they don’t implement the data warehouse (or any other project) in a fashion that makes sense to the business user, I wonder if it's the methodology that's holding back the progress. Methodology is
I am constantly faced with decisions on whether to do calculations in reports or store the calculated value in the data warehouse. So, I thought, why not share these thoughts with you? Pros and cons: If I calculate a value in the report, I could be putting undue stress and complexity
