Once upon a time, there was Andy, a technical engineer working for many different IT projects. In each of these projects, Andy worked on the functional and technical design of, let’s say, a Business Intelligence solution. His boss and his project managers were highly impressed with his knowledge and the customers were satisfied. One day, Andy’s boss decided to hand out a promotion. Andy was delighted to hear that he / she was going to be a project manager!
At the first day as project manager, Andy could not wait to start the project and become highly successful. But things went differently, Andy was confronted with a team of people that was not motivated at all to participate in the project. He felt that they were even trying to sabotage things! And the users of the new BI solution: they kept changing their requirements and in the User Acceptance Test they did not even see the brilliant technical design that was made by Andy and his new technical engineer. Andy could not cope with all the misunderstandings, the delay that was caused by the lack of motivation of the team members and the dissatisfied faces of his steering committee. With a burn-out and a lot of disappointment, he quit working at his employer.
This story may sound like a sad fairytale, but it is the reality in many IT projects. Since I saw a few cases from nearby, I started thinking about the cause of this situation. The main problem is that project management is seen as a promotion in the organization in comparison to a technical role. In the contrary, it is nothing like that, it is a different discipline! Why do we take extra time for training and knowledge transfer when we switch from Controlling to Marketing in our organization but leave it behind when somebody switches from Programming to Project Management?
Realizing this, it is no wonder that Andy did not immediately succeed in the new role of project manager. It is a different discipline, in which you must be able to work with many different interests and coordinate the work for and within your team. As a project manager, you leave the content of the work (the technical part) behind: you have to keep the overview and make sure that all parties involved will accept the product that your technical engineers are creating.
In many projects I have seen that the project manager was looking too much into the content of the work, since that was his / her old job and focus, and too less at the overall success of the project. This is not necessarily a flaw in the personality or skills of these people, but lack of experience in an entire new line of work. If we want to professionalize IT projects, we need to start realizing that a technical role and the role of project manager are two widely different disciplines. Starting from this idea, you could still ask a brilliant technician to become a project manager, but you have to take into consideration that he or she will need training and will start as a junior project manager (even though he or she may be a senior technical engineer). This means that in the beginning, the new project manager will need coaching and training-on-the-job, as is normal when someone starts a new position.
When I talk to people about this, everybody agrees on the differences between being an engineer and a project manager. Now it’s time to start implementing this difference in our projects in order to make sure that professional IT Project Management is no longer a fairytale but a reality!
September 15th, 2009
As I discussed in my last article, Intelligence is not only about data and information, but also incorporates the intangible tacit knowledge from your employees. As you can see in the presentation that was uploaded recently, there is a big theoretical reasoning for why an implementation of a Business Intelligence solution should also include actions to promote the sharing and use of tacit knowledge. But how can we quantify the (potential) success of Business Intelligence, and how do we show that a BI implementation that also includes tacit knowledge is better for an organization? In other words, what is the BI Business Case?
The impossibilities for a BI Business Case
Especially in times of economical recession, each new project in an organization has to show a clear Business Case. How many benefits is this project going to create? A Business Case is, as defined by the Prince 2 Project Management method: “The information about costs and benefits of the project and with this the justification of the start-up and continuation of a Prince 2 project” (van den Akker, 2002). This Business Case is leading during a project, and will be used for evaluation of the progress and the results. In order to describe the costs and benefits data and information is needed, including forecasts.
Of course, an implementation of Business Intelligence should also be started with clear goals and potential benefits. Business Intelligence is meant to support decision making in an organization, by gathering data and information from within and outside of the organization and organizing this into management reports. But how do we measure if the decision making has indeed improved? How do we quantify decision making? We could never see the difference between the result of the decision that was actually taken and the result of the other option that was there. So how do we know which decision was the better one? How do we forecast future benefits from this ‘better decision’?
Also, when tacit knowledge is added as a point of attention to the implementation of Business Intelligence, this brings an extra factor to the table. Tacit knowledge in itself is a form of knowledge that cannot be made explicit and therefore not be measured. The use of tacit knowledge in decision making can thus not be determined, it is even so that tacit knowledge probably plays a role in every decision that we make but that the amount of influence can differ per decision. Measuring an improvement in decision making based on both data and information, delivered by BI tools, and tacit knowledge seems like an impossible goal. This leaves a possible implementation of Business Intelligence with a big problem: a quantitative Business Case can hardly be created.
The possibilities for a BI Business Case?
Brockmann & Anthony (2002) seemed to have found a solution. They investigated the influence of tacit knowledge in decision making on the performance of organizations. What better Business Case could we wish for? The authors suggest that decisions on a strategic level are often “ill-defined, unstructured and lacking in precedence”. (p. 437).
Tacit knowledge is just that, and can therefore contribute to this type of decisions. Since there is little or no attention for the use of tacit knowledge in organizations, this can be an extra advantage in strategic decisions.
The authors base their assumptions on the positive relationship of tacit knowledge to decision making on research by Wagner (1987), Wagner and Sternberg (1990). These authors investigated that the use of tacit knowledge has a positive influence on managing tasks, managing oneself and managing others. Also, there was investigation on intuition (compatible with tacit knowledge) from Parikh et al. (1994), Agor (1986a) where it was stated that “faster and higher quality decisions are made when managers rely on their intuition” (Brockmann & Anthony, 2002).
This all sounds like a perfect Business Case. But if we look into the methods that were used to determine whether a person had used his tacit knowledge, we see that we are talking about questionnaires or cases that are presented to participants. Considering my previous arguments on the impossibilities of measuring the amount of use of tacit knowledge and measuring ‘improved decision making’, these methods are not giving us any insight and certainly no reliable figures on future benefits of a BI implementation.
A different kind of Business Case
A quantitative Business Case, as described in the Prince 2 Methodology (van den Akker, 2002), is not something that we can apply onto an implementation of Business Intelligence. This implementation is complex and has many facets, as discussed in earlier articles, and can therefore not be captured by numbers about costs and benefits. So how do we show that an implementation of Business Intelligence actually has value? Well, a Business Case does not always have to contain figures that will show an increase of business results to be valid. There are examples of a Business Case based on qualitative statements and not so much quantitative ones.
During a BI implementation one could for example organize a quality audit of the decision making in an organization before the start of the implementation. At the end of the track, a similar audit has to be performed to see if the decision making has improved in the view of managers and their employees. These are very subjective criteria, but these are the only criteria that you can actually use to measure if your BI implementation has been successful.
Measuring the amount of use of tacit knowledge in decision making is, in my opinion, methodologically impossible. But a focus on the use and sharing of tacit knowledge (for example by looking over the shoulder of a colleague) could contribute to the feeling of improved decision making. So what is the answer to the question that was posed in the beginning of this article: what is the BI Business Case? There is definitely a Business Case for BI, but in the preparation of an implementation it should be proven in a different way than a traditional Business Case. With a non-traditional implementation of Business Intelligence, with extra attention to tacit knowledge, there is also a need for non-traditional Business Case!
Literature
- Agor, W. H. (1986a). The Logic of Intuition: How Top Executives Make Important Decisions. Organizational Dynamics, 14(3), 5 - 29.
- Akker, Ir. A.G. van den (2002). Prince 2 compact. Methode voor Projectmanagement. Lagant Management Consultants BV.
- Brockmann, E. N., & Anthony, W. P. (2002). Tacit Knowledge and Strategic Decision Making. Group & Organization Management, 27(4), 436 - 455.
- Parikh, J.; Neubauer, F.F. & Lank, A.G. (1994). Intuition: the new frontier of management. Cambridge, MA: Blackwell.
- Wagner, A.K. (1987). Tacit knowledge in everyday intelligent behavior. Journal of Personality and Social Psychology, 52, 1236 – 1247.
- Wagner, A.K. & Sternberg, R.J. (1990). Street Smarts. In K.E. Clark & M.B. Clark (Eds.). Measures of leadership (pp. 493 – 504). West Orange, NJ: Leadership Library of America, Inc.
November 5th, 2008
How many times have you attended a meeting where the other attendants brought their own Excel-sheet showing conflicting figures? Probably way too many times… You wish for everybody to use one source, one definition, and maybe even one report or dashboard for their information needs in this meeting. Eventually a small business intelligence project is started to make some of these reports, but along the way you discover that the information quality is not okay, sources have to be integrated, uniform definitions have to be made and so on. The project scope is creeping and the budget is overrun… Familiar?
Especially when the BI project is initiated top down and organized centrally, information between different information islands (applications, business units or processes) have to and will be shared and exchanged. Both socially and technologically this can enable many consequences in the organization that are all too often not anticipated in the beginning of the project. There is more to the eye than meets the eye…
This is where information logistics come in. A couple of years ago I wrote a master thesis on the role of information in supply chain management. As you might know information is exchanged between buyers and suppliers in the supply chain in order to move goods as efficient and effective as possible to the end-consumer [1]. Besides efficiency and effectivity, exchanging information in a supply chain has many more consequences, but also needs some prerequisites… To start with the exchange of information between buyers and suppliers is only done when a certain amount of trust and collaboration is in place between the involved parties.
While on another level, it is here I see an analogy to aforementioned information islands in an organization that kick started the BI project. Just like organizations in a supply chain, information islands in the organization can be considered as business entities that exchange information in order to operate as efficient and effective as possible. The model I developed for my thesis can be put to good use here.
Namely, these islands will only share information with each other when they have a collaborational relationship and trust each other [1,3]. When they exchange information, transparency is created between them (and possibly other business units). Another side effect is that so-called white spots appear. Some information is not available, or of poor quality. To improve on this, information has to be integrated in uniform definitions or by introducing organizational or industry standards (such as XBRL) [1]. In addition, this can result in information systems that are integrated (in this case for example a datawarehouse, datamart or reporting layer) [2]. Because organizational units are gearing their activities to one another as a result business business process integration takes place which in turn will lead to increased collaboration and trust (in each other and the information) [3]. In doing so a reinforcing loop comes into existence.
So, going back to the BI project, why is it more often than not more encompassing then anticipated? Simply, because it is often not anticipated that initiating a similar project not only creates centralized reports, but as information is the lifeblood of an organization it has both technological, social and organizational effects.
Please let me know if you would like more information on the model or the thesis.
[1] Lee, H. L. and S. Whang (2000). “Information Sharing in a Supply Chain.” International Journal of Technology Management 20(3/4): 373-387.
[2] Aubert, B. A., B. Vandenbosch, et al. (2003). Towards the measurement of process integration. Scientific series. Montreal, CIRANO (Centre Interuniversitaire de Recherche en Analyse des Organisations.
[3] Premkumar, P. K. (2000). “Interorganization systems and Supply Chain management: an information processing perspective.” Information Systems Management 17(3): 56-69.
October 29th, 2008
After XBRL was already marked as a major trend during the Gartner BI Summit in Februari 2008, - provided it would become an obligation -, NuZakelijk.nl reported last month that the Securities & Exchange Commission wants to oblige this reporting standard in the U.S. to all publicly traded companies.
Very many large organizations will be influenced by this government obligation in the way they carry out their (financial) reporting. All of a sudden XBRL will get the critical mass to become the de facto standard.
Potentially, this decision has far-reaching implications for BI. In particular, the simple exchange of information is, in my opinion the most important next step in the maturity of BI, namely interorganizational BI or Business to Business Intelligence (B2BI). Besides organizational conditions like trust and type of relationship, the XBRL standard can provide organizations with the most important technical condition for B2BI. Namely, it would finally be efficient and easy to exchange reports between different organizations (or business units). Like for example, EDI that caused the widespread exchange of data between companies, I foresee that XBRL will play this role for B2BI. In a way organizations can finally exchange information after data in an easy (=broadly accepted) way.
What do you think? Will B2BI take off with XBRL? Or will it be driven by another standard?
More information on XBRL (in Dutch).
July 11th, 2008
(4.67 out of 5)
(4 out of 5)