Myth #1: General IT workers know how to “do” business intelligence.

Many IT shops try to retrofit a BI team out of people who appear to have some of the skills that you see listed in a Monster.com job opening for a BI professional.  This is a recipe for failure as a general IT worker might be able to deliver a report to a user, but without proper data modeling skills, ETL knowledge, and OLAP cubing skills what will be delivered is what I like to call “Fake BI”. Fake BI can answer one or two business questions, but the minute the business wants to slice the data a different way Fake BI is exposed as incomplete. This is not to say that general IT workers can learn BI, but they need to be mentored by an experienced professional and be willing to learn from the ground up a different way of thinking. Successful BI teams are filled with people who have a “Do You Want Fries With That?” mentality. These folks go the extra mile to deliver added value to the solution, are innovative in using the tools they have at their disposal, and they are constantly asking themselves “How can I make this better and more valuable?” These are the kinds of people you want to place on the BI team.

Myth #2: IT can deliver Business Intelligence without the business’ involvement.

When IT assumes it knows what the business needs, it delivers a solution that isn’t used by the business. This is where the business sponsor becomes the most valuable asset on the BI Team while not really being “on the team”. The business sponsor will be the one defining the business requirements, or working as a liaison between IT and the other business users so that the requirements are captured. If you can make the sponsor happy, they will become an evangelist for business intelligence and your program can continue to grow and deliver business value as other sponsors will come forward with requirements (and hopefully dollars) to drive the project forward.

Myth #3: A BI Project has a definitive end point

General IT workers who live in an Application Development state of mind see all projects as having a beginning and an ending. Business Intelligence is a program, not a project so it is an ongoing process that is constantly evolving and adapting to the business needs as things change internally within the business and externally within the market. Businesses have to commit to a long-term strategy and vision in regards to their data and they need to view it as their most valuable asset. It is important that the business sponsor understand this fact, and if the value is being delivered through business intelligence by the development team this should be an easy thing to see for the executive leadership to see.

Next Steps

If you are the one who is hired as the Business Intelligence “expert” for the enterprise and the business and/or IT is resistant to change, be prepared to be frustrated as you try to champion change within the enterprise. Try to find support from peers and co-workers to help evangelize process change in the name of BI. Some days it may feel like you are trying to teach a pig to sing, but in the end you and I know that the end result can be amazing.

In a new BI program, the experienced party has three very important roles. The first is to build and architect the BI solution. The second is to mentor the less experienced members of the team so that they become more valuable to the BI program. Lastly, you will educating the business users in the use of BI to better their business processes. Once the users are educated, requirements become more clear and the business begins to ask more and better questions.

Next, be sure that you are listening to the business and capturing the requirements they are putting forth, because unfortunately most BI implementation get one shot at “victory”. If it falls short it is shelved for a year or until the next business sponsor comes along and gives it another try. There are many reasons why more than 75% of Business Intelligence projects fail, and unfortunately no definitive reason to keep an eye out for, but if you have a strong, engaged business sponsor and a mix of experienced BI professionals and people who are willing to learn the associated skills than you are ahead of the game.

Lastly, realize that even with the best intentions that some enterprises are not “ready” for BI and you may just have to move on and find new opportunities. If you are wondering what signs to look for to know when you have reached a dead-end with a BI project, check out Wayne Eckerson’s blog post on the B-Eye Network titled “Dead-End BI: When Is It Time to Quit”.

Business intelligence is quite possibly the most frustrating and the most rewarding undertaking you can be a part of as a computing professional. You can find advice all over the internet and in countless books and white papers, and none of it will apply 100% to your situation. The one thing I will say to you, that does apply to all situations is “Good Luck!”

In a recent “Tweet Chat” hosted by Howard Dresner a group discussed IT departments using business intelligence to measure internal performance. Internal analytical evaluation is an interesting concept, but this type of project may be a hard sell to a corporation that is looking to cut costs. Is Internal BI something companies should consider? Yes!

Until you are able to measure how productive your IT staff is, there is no other way to justify IT staffing levels or secure more budget dollars for future projects! If a CEO asks questions like “What was the labor-savings realized by Project A?”, a CIO should be able to give that answer. Performance metrics aren’t just for sales or financial dealings of the business in question. Every department in a corporation should look at internal performance metrics to see where they are spending their time, where they are adding value, and where they can ultimately make improvements, cut costs, and streamline themselves as a department… which in the end, does affect the business and their bottom line. It is surprising that CEOs don’t need this type of analytical information for an IT department (or any department) that makes up such a large part of a company’s operating budget (in some cases).

 So what do you measure and how do you measure it?

For IT to measure their productivity, they accurately track their time against the correct project or projects that they are working on or supporting. This data will show hours spent in new development verses production support issues, which projects are getting the most time, and other areas where time is spent (i.e. training and education, meetings, help desk tasks, etc). Included in this data would also be IT salary and departmental cost information so that you can measure dollars spent against time for each project. It would make sense to average departmental costs across the headcount unless there are specific costs associated with certain people or teams.

Next, you need to find a way to measure impact of IT projects and tasks to the business. This is a bit trickier to track as Project ROI is hard to nail down. A simple way to start maybe through initiating a survey of specific project users from the business, using questions like “How many hours a week does Project A save you on an average week?” and “How long have you been utilizing Application X?” You will need to ask  questions targeting for each project or application that IT is supporting. Coupling this data with salary data from HR (average salary, not actual salary) you can then see what the saving are in regards to labor costs for the business.

Once you have those pieces of data, you can start to formulate an IT Spend to Business Impact ratio. This is where it might get scary for CIOs and upper management in IT, because now the blinds are up and everyone can see what projects were worthwhile and which ones were “flops” on ROI. This exposure is a good thing however, because it helps you understand and hopefully pinpoint where projects go wrong. If there is too much time being spent on support and enhancement requests then perhaps you need to do a better job capturing requirements or perhaps a more rigorous QA process.  Do one or two project managers constantly run past SLA or production deadlines? Are they under estimating their time, or are their other issues that need addressing? The list could go on and on as far as analytical study of IT metrics.

Effective budget planning could also be affected by implementing BI within the IT structure. When developing project plans and designating resources you can show your projected spend for a project against the IT budget for the year. Another area that could be explored would be a measure of expected ROI from a project. Based on the requirements gathering, IT groups could capture the time spent on a task, and the potential time that would be saved by employees who would be using the application. This type of data could be useful during project prioritization and eventually you could show perceived savings vs. actual saving against the total cost of the project. By using BI for budgeting and project prioritization management can see the true impact of IT vs. the dollars spent and budget dollars are best used to support the business all while getting the greatest “bang for the buck”.

How accurate is the data?

This is the biggest obstacle I wrestle with on this type of reporting and questions exist in multiple places regarding the accuracy of the data.

First, is the IT staff accurately recording their time and are they recording it against the proper projects? Does 1 hour of charged time REALLY equal 1 hour or was it really a half hour and you needed to fudge your time because the management team gets upset when you time sheet isn’t at 40 hours or more? For this problem, I think IT managers need to realize that 40 hours of real work may not occur each week… some weeks it is 32 and some weeks it is 50. Lording over your employees because their time sheet appears short of the standard 40 hours per week is not a way to manage. When management adopts this more flexibility or realistic attitude, then you will see the accuracy improve on time reporting.

Secondly, is the business accurately reporting their time spent on daily tasks? It may have taken them 1 hour to put a report together, but they don’t think about the 6-12 hours of data wrangling they may have done to get ready to prepare the report. It’s very easy to forget about the steps to complete a task once you are working on the last phase of a task.

Is this project worth the investment?

Whether to invest or not in an IT BI Program is a very valid question, but it may not have a straightforward answer. In theory, it makes sense to use a sustainable method to measure departmental performance.  In practice, data validity is “iffy” if certain aspects of general “IT Culture” aren’t brought into question and ultimately changed to support this type of evaluation. With that said, I think that if an IT group “feels” like they are providing value it is positive for moral. Consequently, if the IT group actually KNOWS and can quantify their impact for the business I can only imagine that the moral would be higher, and you would see productivity improve. In addition, having this type of performance monitoring comes in handy in many situations including budget discussions for areas of IT. As the performance reporting improves you can perhaps use this data for individual performance reviews or at least supporting data for this activity. Would this investment eventual pay for itself by way of improved productivity, better project management and project planning? I think in the long run it would, but the key would be to have patience in allowing the Internal BI Solution to mature so the results become more accurate.

So, is your IT department ready to look in the mirror?