Enterprise Initiatives

In the day and age of cheap disk, fast processors, high bandwidth, and cheap memory, companies are analyzing data more then ever before. As the components of the infrastructure become more cost effective and data is becoming more accessible, IT is being asked to create reports like never before. This is an area where IT can either be an enabler for the business or a serious bottleneck.

As partners to the business, we must educate our users on the power of business intelligence and self service. The business will typically ask for reports which is a reactive approach to solving problems. We need to offer proactive solutions that provide alerts and KPIs to address issues before they become critical. In other words, lets use information to optimize our business instead of creating more non-value add processes where countless clerks dig through hundred page printouts looking for issues. Here is my philosophy on reports. Static or canned reports should only be generated if the information is an output of the system. Here are some basic examples of when systems should create canned reports:

• Bills
• Invoices
• Purchase orders
• Confirmations
• Receipts

These reports are fairly static and should not change too often. When gathering requirements, the reports above would have been identified as outputs from the system. Notice that these are not really reports, they are outputs or artifacts of the system.

So what is the problem with reports? I have seen many applications that contain upwards of 70-100 reports over my years in IT. Usually, you could boil these down to half a dozen subject areas. Over time, different users come and go and they all have their own ideas on how they want data presented to them. So IT is asked to create more reports by adding a field here, grouping a field there, shrinking the font and printing landscape, and so on. All of these requests are a waste of money and a drain on IT resources. Often, these requests go into the black hole of the backlog of simple requests that IT can never find time to get to.

This is where business intelligence kicks in. IT should create metadata to represent the complex relationships of various databases and present the user with a simple view of data in business terms. Then through tools like Microstrategy, SAS, Cognos, Business Objects, etc. we should empower the users to create their own reports. Through self service, the users no longer have to wait months or even years for IT to get around to developing yet another report that must be maintained. The users can now react to business demands and can tailor the output to meet their needs.

This is a mindset that must be pushed from IT. When users ask for a report, the business analyst must ask the user, "What problem are you trying to solve?" I have seen all too often where the user wants a report as a quality check in response to issues found in the data. My response is to fix the root cause and eliminate the data quality issue as opposed to adding another non-value added process that may live on for years before someone realizes that the step is a waste of time.

So I ask, "Why are you still generating all of those reports?" If you follow the trends in IT you will notice that today's users are becoming more empowered then ever before. Users are leveraging various Web 2.0 technologies to service their needs and to build their own composite applications. We need to provide them with that same easy access to data. Don't give them reports, give them information!

Over the last 18-24 months I have researched and taken on a number of Enterprise Initiatives such as Enterprise Architecture, BPM, SOA, and agile development to name a few. As I researched each topic I found tons of articles recommending to steer far away from each initiative. The common theme is that it is expensive, too hard to do, and most initiatives fall. Today I was researching Enterprise Metadata and many of the search results pointed towards doom and failure.

Why is there so much failure with these all important initiatives? I did some research and found that a large amount of normal projects fail at equally high rates. The enterprise initiatives are just more visible and usually require a significant upfront investment. So what are the common reasons for failed projects? An article at Gantthead.com provides the following list:

• Inadequately trained and/or inexperienced project managers
• Failure to set and manage expectations
• Poor leadership at any and all levels
• Failure to adequately identify, document and track requirements
• Poor plans and planning processes
• Poor effort estimation
• Cultural and ethical misalignment
• Misalignment between the project team and the business or other organization it serves
• Inadequate or misused methods
• Inadequate communication, including progress tracking and reporting

For enterprise initiatives I would add these:

• Lack of strong executive sponsorship
  
• Unrealistic scope ("boiling the ocean")
  
• Lack of governance
  

So the next time you start researching a large IT initiative and you see all the negative publicity about your chances of success, ask yourself these questions:

1. Do we have the leadership required to take on this project?
2. Do we have enough change agents to change our culture?
3. Will we be able to get enough funding to adequately meet our objectives?
4. Will we get the support from the executives and/or the business?

If the answer to any of these questions is "no", then you might want to listen to the warnings from the articles. If the answers to all of these are "yes", then it all comes down to how good of a plan you put together and how well you execute the plan. Don't be risk adverse and let fear get in the way.