Marketing IT In-House: The Role of Failure in BI Success
Welcome failure as a source of feedback that leads to success.
By Max T. Russell, Max and Max Communications
I argued in a previous article that there's no reason to fear the BI failure statistic -- whatever it may be -- if your BI team's behaviors are consistent with success. In this article, I will emphasize the role of failure in successful BI.
Failures are inevitable. What you do with them determines whether you go down in smoke or soar to success. Squeezing insight even from the most staggering setback is a behavior that can enhance your success.
BI holds a great number of potential setbacks to evaluate and learn from as you drive forward. To do all that, IT has to get out of its traditional comfort zone and learn about business and how to communicate with people across the enterprise.
The very fact that there's a critical shortage of competent BI professionals tells us that technologists do not naturally gravitate toward the challenges of BI.
More than IT
In other words, BI is much more than IT.
Roger Cogswell brought me from the sidelines and into the BI world several years ago to help him solve communication problems between IT and business and between IT and BI.
After three years I told him, "BI is only partly IT." Roger thought about that and then restated my observation: "BI is primarily a non-technical communications solution with a complex technical component."
Shortly afterwards, I told a programmer at a major corporation that BI is only partly IT. "Thank you," he said. "My boss is trying to get me and the other programmers in our department to understand the business side of our company better and I'm just not good at that."
Not everyone in IT is cut out for BI. Those who are will venture out of the department and into the heart of their enterprise and all the variables that go with it. Only after they've gathered what they need do they return to their beloved caves to work in creative solitude.
Fail Together, Learn Together
Heavy users and seasoned BI professionals alike agree that BI is very much a matter of collaborative experimentation and interpersonal communication. Everyone's in it together.
You cannot start a proper BI program without an understanding of your enterprise's business. You have to see relationships between departments, operations, financial goals, budgets, executive vision, work culture, principles of BI, and technological capacities.
Even so, the unknown lurks at every phase. Wayne Eckerson told me that the BI failure rate is 100 percent. That indicates an expectation that you reach successful outcomes only by experimenting and causing unexpected, informative things to happen. Failure will be frequent.
This is not recklessness. Anyone who has been involved in conducting systematic experiments or analyzing them knows that the more you study anything, the more questions you generate and the more options there are to evaluate.
For instance, if your company wants to install a steel fabrication press with the latest computer interface, user management might want to know:
- Will workers need technical training off-site?
- How will the computer technology in the new press affect setup and production?
- Will we need or be able to take any new measurements?
- Will the measuring frustrate workers in any way?
- How long will it take for the line to run more productively?
- What are the potential breakdowns for the new press?
- Are the breakdowns offset by improvements over the previous press?
- Will the BI program enable workers to monitor production, quality, and safety?
- How will we measure the scrap rate?
Keeping Things Objective
Those are only a few of the questions that come to mind. Although they are only partly IT issues, they should be IT's concern.
A BI program helps keep discussions objective by (1) selecting and posing hypotheses that are important by user standards, (2) testing them with well-defined measures, and (3) methodically interpreting results at each step in order to determine how to proceed.
Does that sound nice and neat? It rarely is. I've watched my share of bad BI for almost 19 years, and it always involves terrible communication.
As long as everyone understands from the beginning that success comes on a bumpy road, and that respectful communication is indispensable at all times, a properly constructed BI "laboratory" (i.e., your data architecture) provides a safe environment for experiments. The communication challenges will be as bumpy as the technological ones.
Next we'll examine two scenarios that illustrate how failure was turned into BI success.
If Gary Had Only Known at the Beginning
A large BI program was launched in a corporation where Gary, a key IT professional, thought his employment would be eliminated by the technological advances he was asked to implement. To be sure, many of his job functions would be replaced, but his knowledge of business and information processing would become more important than ever in making the new system work.
His managers didn't think to make that known to him. They just assumed he'd continue providing the guidance they depended on long after the consultants had moved on.
"I guess they won't be needing me around here anymore after this new system is in place," Gary told the primary BI/DW architect. In truth, Gary was frightened to see the consultant in his office.
The consultant responded immediately: "Gary, the difference between consultants and you is that we'll be gone before long but your company will need your expertise more than ever. Your contribution to building and implementing this program is invaluable."
The consultant then informed the management team of the communication problem and they confirmed to Gary that his role was key to the BI program's ongoing success. With his spirits lifted, Gary became much more cooperative and learned as much as he possibly could before the consultant finished his contract.
Because of the primary architect's alertness, the communication failure benefitted Gary personally and professionally and taught the management team that the rest of the BI program had to be implemented with harmonious communication.
Just Before the Plug Was Pulled
Marissa was called to help diagnose a crisis at a large educational service center. The center had purchased a data warehouse modeled on a single school district to deliver faster and more helpful reports to its many districts.
The purchase was a horrible failure and an embarrassment to the center, which was on the verge of pulling the plug on the DW after investing millions of dollars and failing with its very first client.
By failing to purchase the right DW, the center had put itself in a position that allowed an expert to get a clear picture of the center's vision and the current architectural status. Marissa explained that the database would have to be adjusted because the center's educational philosophy required different measurements than the ones the model was based on.
This was an alarming but appreciated revelation. The people who had shaped the center's vision learned more about what was involved in delivering the correct product than they would have learned by purchasing the correct database. Now they had the necessary knowledge to understand how to translate their vision into efficient, timely, accurate reports.
A Final Word
BI is working when it leads to harmony and productivity. Failure need not stop you from getting there. You can't predict absolutely everything that can go wrong, but you can plan for it with a favorable attitude toward failure. Failure is something that happens on the way to success.
Max T. Russell is the owner of Max and Max Communications. He works behind the scenes to promote individuals and projects in a variety of industries. He and his identical twin, Max S., have been discussing and dissecting the challenges of IT in the workplace for the past 18 years. You can reach him at [email protected].