People vs Tools and Techniques
May 17th, 2008 by Jon Mead
One of the things I am doing at the moment is reviewing our delivery methodology, looking at how different techniques and can be used with the current stack of Oracle BI tools to effectively deliver projects. This involves looking the tools currently on offer, such as OBI EE or Warehouse Builder and a number of different design techniques such as dimensional modelling, dashboard design and various agile/RAD methods, and seeing what we think works the best.
My path into IT was a Software Engineering degree, so when setting out on these types of tasks I naturally revert to this subject area to feed into the process. One of the references I was using was book Facts and Fallacies of Software Engineering by Robert Glass (review here – I would also recommend the whole Coding Horror blog).
The book starts with a section about management and a couple of comments struck me. First he quotes Alan M. Davis (here and here – not the comedian):
Good management is more important than good technology.
And the first two facts in the book are:
The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
and
The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
These are long established facts/opinions (maybe controversially) and the cornerstone of books such as Peopleware.
So, I then have to ask myself if we are wasting our time putting a lot of effort into setting out a project methodology, should we just concentrate on recruitment? If we get the right people in, will our projects always be successful? As we are a service provider/consulting company trading on providing an expert service, based on experts we employ, we hope that this is something that we have got right, and (with my selling hat on), I believe that’s one of the reasons we are used.
Why care about tools and techniques?
Taking tools as an example, say an organisation is fully committed to using analytics for competitive advantage and this was driven and supported from the highest level in the organisation, then would it really matter if they use the Oracle stack or Cognos (IBM)? Sure, it may be easier to integrate if they chose the same vendor as their transactional systems, but the choice wouldn’t be the critical factor that determined the success of the project, the implementation of it would be. As a quick aside there is an interesting article here looking at the offerings of each of the ‘big four’ BI vendors.
Similarly with techniques, there are probably a number of approaches that could work, HOWEVER as a service provider/consultancy I think it is important to have a clear approach. We offer services in a niche area, and organisations will often get us in because they do not have not expertise, or enough of that expertise in house. I feel if we can initially give people a roadmap of how the project will progress, what resources will be required when and when deliverables are expected then this has got to be a good starting point, and I think our clients look to us for something like this.
I think the really important thing to realise is that by following this (blindly or otherwise) will NOT just mean the project is automatically successful. It is everything that happens after day one that will determine whether the project is successful, and this comes down to people, how the project is managed (some of which will come from our methodology) and how good the developers/consultants are. Similarly with tools, there will be features and functionality that differentiate the tools and chosing the right one will give you a better chance of success, however what is important is what the development team do with that tool after day one when it has been chosen. That is what will determine the success of the project.
May 18th, 2008 at 3:57 am
Hello Jon,
I am interested to see how your delivery methodology is going to shape-up finally. You are absolutely correct that PEOPLE make all the difference in getting the projects successfully executed. But, at the same time methodologies may provide some discipline and if everyone on the project follows the same rules, they may actually benefit the project.
Anyway, we are also currently looking at various RAD methodologies to deliver BI/DW in shorter (like 8 to 12 weeks) timeframes. Obviously the scope has to be limited as well. We believe the biggest hurdle in trying to promote BI/DW in midsize companies that everyone is afraid that these BI/DW projects take forever to implement and cost ton of money. But, I am sure there are ways doing this.
I read somewhere on couple of RAD methodologies in this space, one is Oracle’s DWM (Data Warehousing Methodology) Fast Track, and the other one is from DSDM (Dynamic Systems Development Method, http://www.dsdm.org) Consortium. Have you considered any of these?
Thanks
Ramesh Kumar
May 18th, 2008 at 10:21 am
Ramesh,
I agree, we need the framework and discipline of a methodology as a foundation to drive projects, and also to give visibility of its progress.
We aim to set up a Wiki outlining our approach in the next few weeks so I will certainly put the link to that on the blog.
Re DSDM, I have used it and researched it to a agree, but found it was too broad to use for the types of projects we deliver. We want something that covers things like dimensional modelling and dashboard design - a lot of methodologies are more functional and hence use case based, I think BI/DW need something a bit different to that.
Re Oracle’s DWM - we have not tried to implement it. I would be interested to get some more details about it, however think that we would use it as an input into defining our process, rather than the complete process. People would generally want us to a bit independent of Oracle in this respect.
Jon
May 22nd, 2008 at 2:55 pm
Ah but there is still a problem. Sometimes tools are selected for their suitability to personal (availability and price). They are then applied to solutions they were not designed for.
ETL being the grey area here as differing ETL tools provide different levels of granular functionality (however usually used for quite flat warehousing databases).
Where there are interdependant normalized relationships most ETL tools suffer.
In this circumstance the tooling phase should have taken account of the data requirements not just the personnel.
At this point the tools may still be selected but other requirements could be factored into the project plan and the structure would be reflective of the problems that would be encountered before they occur.
So whilst I agree with the adage ‘you get what you pay for’ I would always factor a requirement into the tooling phase with regard to the suitability to the data and existing technological needs.