I’m currently working on a near-real time reporting system for a big client, and one of the components of the work is to fix the ETL system put in place by the consultancy who were in previously. So what, you might say, they’ve been burned by a tin pot little outfit who overreached. Well, er, no. The consultancy who built it are a huge global player, and are people who should have the brightest and best working for them. They seem to have made 2 critical mistakes:
- Applied a generic methodology without customising it to the tool or situation
- Outsourced development offshore
Why can a general approach fail?
It’s true, ETL processes have general principles that should be followed in most processes, but each ETL tool has its quirks that need to be allowed for, and performance features that should be embraced. Similarly each project will have its own unique requirements that will mean the generic approach won’t be a 100% fit for the project you are working on.
For example, in the case I’m dealing with now, they have a control framework which is designed to do all sorts of logging and control – except about 50% of it simply doesn’t work because of the way the data of the project has to be handled. Similarly they have control tables whose contents have been stuffed with chunks of queries simply to make the existing framework function, rather than rework the framework to suit the need.
A general approach will fail when it is applied too rigidly by people who don’t understand the reasons for the approach in the first place. This is why lawyers have the concept of the spirit and letter of the law. With any methodology you need flexibility in how you handle each situation – the reason why there isn’t a universal ETL method used by everyone is because such a system cannot exist given the variety of demands and constraints on such systems.
Offshoring saves us money so is good for the business, surely?
Offshoring works in an IT project in a very narrow range of circumstances, and BI projects very rarely meet those circumstances. What happens when you offshore is you send your specification to a third party who cannot – because of time differences, cultural differences, language issues – communicate with you constantly and get an understanding of what you are asking for. As a result your specifications will be met exactly, with no allowance for what you wanted, because any experienced IT developer will admit the specifications often overlap – but rarely match exactly – with what the business needs. This will be fatal for a BI project because as seasoned BI professionals will warn – BI projects are first and foremost Business projects, not IT projects.
Combined with the risks in having insufficiently skilled developers sticking rigidly to a general approach that doesn’t really make any sense, and you have what we are dealing with – a dysfunctional system that may simply need to be thrown away.
So how do I protect myself against bad consultants?
This is probably a series of articles in itself, but I would give the following quick suggestions around development:
- Have development work done on site as much as possible. If the words outsource or offshore are mentioned, run away.
- Ensure that lead developers are experienced – certified if possible – in the technology you are using. Being a SSIS ace doesn’t mean you will be bale to do great work in Data Integrator
- If possible get a third party to review the work at an early stage
If anyone else has had similar experiences and ideas on how to mitigate the risks of engaging poor consultants, comment away!