The Emperor is Naked! (Umm I mean, the project is behind schedule and over budget)

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.

 

Estimating a Project Timeline for your Business Intelligence Project

Credit: http://commons.wikimedia.org/wiki/File:Schedule.pngIt 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.

Tips for a Successful Business Intelligence Knowledge Transfer Session

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.

Your Business Intelligence Roadmap

Ok, so you’re new business intelligence solution project is coming to an end. The developers have created a great new data warehouse and data marts are being designed as we speak. Your team is discussing training and user adoption strategies and then all of a sudden you have a meeting request from your vendor…”We’d like to meet with you to discuss your business intelligence plans for the future”.

You’re not alone if this type of scenario would catch you off guard. I wasn’t sure how to respond to such a request. We had barely had time to breathe since this project began, much less plan out how and when additional source systems would be brought into the business intelligence application. My team and I wondered..is it too early to have this type of meeting?

As I pondered, I recalled that just days earlier some stakeholders had inquired about data that was currently inaccessible because it hadn’t been migrated into a data warehouse. I didn’t think much of it at the time, but now I could see that even the users were forward-thinking. They were thinking of the great possibilities of our new business intelligence solution without any prompting and it seemed that they were running this race quicker than me.

So, my final conclusion is this: It is not too early to create a roadmap for your business intelligence solution, in fact, the sooner the better. I know how tempting it is to want to relax after such a major project, but once the users realize how powerful the new data is for them they are only going to want more. Don’t be reactive to such request, but take a proactive approach by planning your business intelligence roadmap early.

Why I Can do What I do

http://commons.wikimedia.org/wiki/File:SHARE_-_NARA_-_515391.jpgI am angel.

I am passionate.

I have lived a life of fear and love, and I have gained wisdom.

I have experienced loss and gain, pain and power.

I help others realize the value that they have to offer.

I don’t believe in talent.

I believe that we, as humans, are capable of whatever we set our minds to.

I am evidence of that.

Like many of us, I need to feel satisfaction at my job. I accomplish this by enabling others at my workplace to feel this same satisfaction that I seek. How do you do this? Teach others. Don’t hoard information. There is no true power, or security, in holding all the information that is required to accomplish a task.

Yes, there’s always that subtle fear, “If other people can do what I do, am I still needed?” but the answer is yes! And if the answer is no, then you will probably add more value (and have more job satisfaction) elsewhere.

Companies need people who are smart, and who are willing to share their knowledge throughout the organization. Many companies have realized the value in having people like you, and other companies are still stuck in the specialized task-specific employee–they need you more than ever.

So, if you have knowledge that is unique, find others who are curious about that knowledge. Share your knowledge, give the users documentation. Empower others by giving them the knowledge to accomplish their tasks in more efficient ways. This is not speaking about the technical type of business intelligence that I am accustomed to writing about, but this does address the key foundation of any business intelligence solution: the sharing of valuable knowledge.

Burnt out? Find the under-utilized talent in your organization!

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.

3 Steps to Bridge the Communication Gap Between IT Professionals and End Users

http://commons.wikimedia.org/wiki/File:Visegrad_Drina_Bridge_1.jpgYou 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.