Greenfield Business Intelligence – where do we start?

Generally, the human condition means that we often don’t know when to start doing, and don’t know when to stop. I’m sure you can think of plenty of examples in life! This happens in business a lot; as an illustrative example, some managers might not be willing to stop a strategy which the evidence shows isn’t working…. conversely, they don’t know when to start a new strategy.
 
The human condition also applies to business intelligence, since it involves people. However, there is the added problem of not knowing how to start, or how to stop. Greenfield business intelligence projects might sound like a dream; completely new technology, completely new solution to design, build and test, and there’s no hangover from previous bad coding.
 
Greenfield business intelligence does give us another set of problems, however. The human condition means that users don’t know what they want. This may sound strange, but sometimes users can perhaps lack confidence to say what they think that they might need now or in the future. After all, who wants to take the blame when something goes wrong later on? User input and experience is extremely valuable in producing business intelligence solutions and it’s very important to include them early on. So, if you can’t get the user input easily, what can you do?
 
Greenfield business intelligence isn’t all about technology; there are people issues as well.  In these situations, the following advice might help:
  • As a recommended strategy, producing reports in an agile way can help users to provide feedback. This will increase their confidence in the system, in addition to feeling that their input is valuable. It wouldn’t hurt to drive home that their input is necessary to make the project a success. This means that report changes can be done in a kaikaku way – iterative, smaller changes that constitute a part of the overall whole.
  • Remember that Excel is your friend; users love Excel. Users eally appreciate being able to see something. An ideal way to do this is to produce a few mock-up reports in Excel with some made-up data. Users tend to give an almost visceral response, for example, ‘I really like that, I really need that!’ or ‘ugh, not what I wanted  at all!’ This can help focus your efforts in planning the data that goes into the data warehouse.
  • Use a ‘traffic light’ system to identify what you must have, what you should have, and what’s not necessary. In project management speak, this is sometimes called the MosCow method: Must have, Should have, Could have. This is easy for everyone to understand, and can help move the requirements to move forward quite quickly.
  • All feedback is useful; the negative and the positive. If people don’t like a report or need the data, then it’s good to be ‘lean’ and not include it at all. Why give yourself extra work to include data which isn’t necessary?
  • In Kimball’s books, this is a real emphasis on this strategy and the first few chapters are about the ways of talking to business users. If you haven’t read any Kimball, I can really recommend the wisdom you’ll find there.
 
To summarise, although getting user input can be difficult, there are some tools to use which can help to obtain it more easily. It’s better to try and get user input in the planning phase rather than after you’ve spent months working on a business intelligence solution that does not answer the business questions. If that happens, the users won’t accept the solution and it’s ultimate failure.
 
I’d love your comments and if you’ve any other advice, please do leave a comment. I’d love to learn from your experiences!

 

Add to Technorati Favorites

Using Kaizen, Kaikaku to deliver Analysis Services 2008

I have been interested recently in applying different methodologies to delivering Business Intelligence projects, particularly in Analysis Services 2008. In particular, Agile and Kaizen seem to be ‘hot topics’ right now, particularly given the credit crunch. It wasn’t clear to me that this approach would work well in Business Intelligence, so I’m currently exploring this idea as I progress on this journey!

Kaizen is derived from Japanese: kai, meaning change, and zen, meaning good. Kaizen deals with micro-improvements, which gradually increment to make larger changes. These changes are focused on eliminating waste from the process. By keeping progress under constant review, it means that problems are exposed much earlier on in the process. In terms of customer satisfaction and project delivery, Kaizen might work well since it focuses on constantly trying to make things better, and for the customer, that can only be a good thing. In particular, it focuses on looking at the facts, rather than a ‘hunch’; looking at data, rather than following a soundbite, should be the way forward in BI in any case. However, a process of constant change can have an effect on individuals on the team, since they are working under scenarios of constant change. Generally speaking, in my opinion, people are generally opposed to change in principle, so this might not suit everyone.

Related to Kaizen is the concept of Kaikaku, which can be translated as transformation, which is usually rapid in form, and it is also aimed at eliminating waste to create greater value. Kaizen tends to be associated with small, incremental changes which are more gradual in nature. Kaikaku is a deeper, more rapid change; this might mean something more drastic, such as making a decision on the inclusion or exclusion of a data source or Analysis Services 2008 cube. In order to eliminate waste, a Kaikaku way might be to introduce this radical change without excessive documentation to achieve it; instead, a lighter documentation effort, to note what is required and agreed before moving forward, may be more appropriate. This might differentiate these approaches from more traditional Business Intelligence projects, where a great deal of documentation may be produced (and perhaps not read!)

So, when implementing projects, I see it as a process of Kaikaku and Kaizen; a radical improvement might be required first (Kaikaku), which is then followed by a process of incremental improvement (Kaizen). This could be translated into the activities of managing a Microsoft Business Intelligence project; a radical improvement could be made by the inclusion of an Analysis Services 2008 cube, for example, followed by iterative amendments to the Analysis Services 2008 cube itself. Kaizen changes might involve something small, such as renaming calculated members so that the users can navigate their way around a cube more easily: thus reducing motion and wasted value. Thus, used together, these approaches are not inconsistent with the process of producing cubes in Analysis Services, for example. This traditionally requires a lot of ‘behind the scenes’ work in cleansing the data in a format that is comfortable to use in a cube, creating and developing the cube, and so on. These activities could be seen in the Kaikaku perspective rather than a Kaizen perspective: as radical changes rather than iterative changes, but equally aimed at producing value.

It is important to note that Kaizen may offer something more to BI rather than simply a gimmick. For example, the ‘headline’ had been that Scrum meetings are normally taken standing up, and should take no more than twenty minutes. At first, this sounds a bit gimmicky but then, the reason for this tactic comes clear; for many developers, meetings are often a ‘waste’. Given that Kaikaku and Kaizen are about eliminating waste, then it becomes apparent that meetings need to be kept to a minimum in order to eliminate waste as far as possible.

So it seems to me that more traditional approaches of Business Intelligence projects could be translated to work within a Kaizen environment. By detecting problems earlier upstream, this can reduce costs in the longer term since issues are fixed earlier, and have less ramifications. On the other hand, the customer has visibility of problems early on in the process. This can mean that the customer’s initial experiences of the project are not as positive as the perceptions that might be gained through producing a lot of project and requirements documentation in a more traditional Business Intelligence project, for example. One way which this might be tackled is by allowing the users to have early visibility of the data; for example, using data visualisation such as Tableau to see the results of Analysis Services cubes or even just SQL Server views. Thus, although the customer can see issues early on, they also see results earlier as well; this might mitigate the risk around problem perception early on in the process.

To summarise, the various management methodologies around project delivery and software development are useful to know, and might be additional tools to help BI projects go more smoothly. I’m all for that!