Let’s say that your consultants are reporting that your data warehouse is nearly complete and they are actually ahead of schedule. Your data team is busy validating the tables that have been populated in your data warehouse and documenting any discrepancies. A few days later your vendor reveals that the project is two weeks behind schedule. In the mean time your data team is finding an alarming number of errors in the data warehouse.

Yes, it’s time to say it…The emperor is naked! Everyone wants to remain respectful and a smart person knows not to piss off the vendors, but when there are some serious project issues happening and everyone seems to be avoiding the obvious, someone has to play the “bad guy” and ask what the hell is going on.

Here are some tips on how to best deal with this scenario…

• Remain calm. Yes, there is a lot wrong with this scenario, but freaking out won’t get anything solved any quicker.
• Make contact with everyone. As the project manager, send out a respectful email detailing the concerns that your data team has expressed. Be sure to only state facts, not opinions, and don’t blame anyone. Copy the email to everyone that is involved in this project, which may be 15 people or more. This is the first step in making sure everyone knows where you stand, including the vendors and the contractors.
• Negotiate a new course of action. Ideally at this point your vendor will organize a meeting that involves all parties. If this doesn’t happen then you should request a meeting. By the end of the meeting you should have answers to questions like: What went wrong? What can we do to avoid this from happening again? What is our new course of action?
• Move forward, mentally and physically. While you can’t exactly start fresh, you can move forward with your new plan. The solution may have been to add additional contractors to the project, or possibly even to hire different contractors. As long as an agreeable solution was reached, do your best to focus on implementing a successful business intelligence solution rather than focusing on all of the problems that you have had to deal with.

It is a well-known fact that the majority of IT projects (that make it to completion) are completed behind schedule and over budget. There can be dozens of reasons for this including a lack of experience, failure to foresee potential issues, the absence of a strong project manager, and often projects are given overly optimistic deadlines to appease executives. Here is how to plan your business intelligence project with a more realistic timeline.

1.What will we get? The first step is to determine what the final output will look like. When your contractors leave and your BI solution goes live what will you have to work with? Some of the main deliverables in a business intelligence solution include:

• A robust and extensible data warehouse
• Combined data from multiple source systems
• Data migrator and developer tools
• An interface for end user dashboards

2. Milestones. Next you will identify the major mile stones in your BI project. Below I have listed some common milestones for a new business intelligence implementation:

• Sign off on the mapping of data that will be migrated from your source system and into the data staging area
• Transform the data and load the fact and dimension tables into the data warehouse
• Validate the accuracy of the data warehouse data
• Cleanse, de-duplicate, and assign common keys to data from various source systems
• Finalize the merged tables in the data warehouse and remove any temporary or working tables
• Validate and sign off on the data quality layer of your data warehouse
• User training

3.Estimate the timing of each milestone. This step will require you to work closely with your vendor and contractors. I recommend estimating a time line that is independent of your vendor’s initial time estimates. You can do this even if you don’t understand all of the details of the project. List out each milestone and have your data team make an educated guess about the amount of effort and time that should logically be needed for each step. Compare your timeline with your vendor’s time estimates and ask for clarification where there are discrepancies.

4.Contingency Plan. Finally, have a plan B. What will you do if the contractors aren’t able to decipher your data as quickly as they estimated? Will you opt to bring in additional labor to keep the project on track (but over budget). Or is it OK if the project is delivered two weeks later than initially planned? At this step you have to determine who in your organization is counting on the completion of this project and who will be affected by a delay.

Following these steps for project planning should get you on the right track. Often we rely on our vendors to act as our project managers, but this leaves us clueless and disempowered. An independent project plan that is insightful will empower your team and make the vendor aware that you are paying attention.

If you hired contractors to create your data warehouse for you it is a good idea to schedule knowledge transfer sessions between the contractors and your data development team. Failing to do this could leave your team dependent on contractors when future development is needed.

1. Prepare ahead of time. Your new business intelligence solution will require you to use new software that is specific to the vendor. Before meeting with developers to discuss the logic that was used in the creation of your data warehouse you should learn as much as you can about using the new software. I was able to purchase an e-book that included tutorials on the data management tool that I will be using. After walking through some of the tutorials I had a good idea about how the data would be migrated from source systems and transformed into data that would then become our data warehouse.

2. Now that you are prepared have an interactive meeting that includes the contracted developers and your in-house data team. Hopefully this type of interaction is anticipated by the contractors, if it isn’t you should come prepared with more specific questions that will guide the contractor into the type of learning dynamic that you seek. Have the contracted developers show your data team how the software connects to your source systems and how the flow of data is configured. Your data team should pay close attention to the transformations that are taking place and how data is arranged as it flows from source systems to data staging areas and finally to the data warehouse.

3. Be sure that your data team takes a lot of notes during the learning sessions. It is easy to make sense of the data flow structure when someone is walking you through it, but after several days you may forget the little tips and tricks that the contractor used during development. I recommend typing the notes into a formal document that will grow with each new knowledge transfer session. This will serve as a resource for your current data group as well as a learning guide for future IT employees.

Knowledge transfer sessions are some of the last steps that you will take before your new business intelligence solution goes live. Encourage your team to get as much out of each of these sessions as possible because this is likely the only time they will receive this type of one-on-one training that is specific to your data set.

Implementing a new business intelligence solution is exhausting to say the least, and if any of you out there are like me, this is not your only responsibility at your job. Taking on a project as massive as over hauling the entire data structure at your organization can be overwhelming by itself, but throwing on the constant demands from other departments while also administering your current data structure can quickly lead to burnt out syndrome.

This is what I have been experiencing, so here’s my advice on how to handle it: Look for people with talent…

When I heard that the HR department was looking for an HR IT person I was thrilled! A lot of the data requests that I field come directly from this department. I spoke with one of the current payroll/HR clerks and learned that he was applying for the position. I did a quick little mock interview with him to see what he might know about querying data. As it turns out he has experience developing entire systems! After getting approval from his manager I offered to train him in the areas that would be the most beneficial for his department. He was even more excited than I.

Friday I installed SQL Server Management Studio on his machine, and Monday he’ll be learning to write SQL! This scenario was looking great so far, but I have a vision and I knew I had to clearly communicate my expections in order for this new dynamic to provide the most value to everyone. I spoke with the Director of IT, the HR Director, and the HR clerk to lay the foundation and to manage everyone’s expectations.

My goal is that the new HR IT person will serve as a bridge between the HR department and the IT department. I expect that all requests will go through the HR IT person. When the request is within his capabilities he will be able to provide the data needed, and when he needs help completing a request he will have me as a resource. The HR department will get their data quicker, the HR clerk will have the opportunity to move up in his career, the IT department will have more of my time available to help implement the new business intelligence solution, and I will no longer have burnt out syndrome! It’s a win-win-win.

So, if you’re feeling burnt out or over-whelmed, look for ambitious people who are under-utilized. They will be happy to take on more projects, and I’m sure you will be happy to let go of some.

You speak geek, they speak analytics. You want data, they want answers. You say to-mae-toe, they say to-ma-to, etc. We have many different ways of saying it, but we know that in the end we all want the same thing; a successful business intelligence solution that will empower us to stay in touch with our customers and make better business decisions. Here are 3 ways to bridge the communication gap between IT professionals and business analysts/users.

1. Listen for context clues. You have to learn their language before any true communication takes place. It is common for people (even technical people) to mis-use technical terms. Several contractors I worked with used the terms data mart and data warehouse interchangeably, even though the first is simply a subset of the latter. Listening to the context of the sentence rather than focusing on the exact meaning of each key word allowed my development team to understand what the contractors were trying to communicate.

2. Monkey see, monkey do. Mimicking the language of the person you are communicating with creates a common ground and provides a sense of understanding. If a business analyst refers to his consumers as clients rather than customers then you should also refer to them as clients. The comradery that developes from this type of interaction will lay the foundation for the next step…

3. Ask A LOT of questions. Now that you understand the users language, and you have established common ground there is less of a chance of annoying the users with all of the questions you will be asking. A common conversation might go something like:

Analyst: “I want to know everything about the customer.” Geek: “OK, what specific questions would you like answered?” Analyst: “I want to know what the customer did while they were at my business.” Geek: “OK, we have a lot of that data available. Would you like to know where they ate and what outlets they spent money in?” Analyst: “Yes, and I would like to know how much they spent and how often they visit the property.”

It’s likely that dozens of questions will stem from every question you ask. Before you sign off on the final data model of your data warehouse, you will gather all of the questions that you have collected by interviewing the users. Search through the data model for answers to each of these questions. A very smart (and patient) co-worker of mine spent many hours verifying that our data model would meet the needs of our users. While such a methodical approach is painful and boring, the results will be a robust business intelligence solution that is backed by a rich data warehouse.