« Did I get data quality in my data migration?? | Main | Managers : New Data Migration? Some advice. »
October 9, 2009
Balance of Power : Consultant <--> Client
As a consultant, and now as the owner of a consulting company I have worked at many client sites over my years. One thing that I often see, which is disturbing to say the least, is the balance of power in the relationship between clients and the consultants they hire.
What do I mean? This is a bit of a sensitive subject, so I will proceed with caution...
Well, just the nature of the reason to hire a consultant - a job needs to be done, and there is likely not in-house expertise (or more dangerously, knowledge) to do the job. Thus, an external resource must be resourced.
There's the crux of the problem. In the absence of in-house expertise and knowledge, there is an opportunity created for a consultant to take advantage of their client.
For example, I was recently engaged by a well known multinational to perform some data migration. The project was ongoing and they had had some very serious interpersonal problems within the team of externals, so they cleaned house and brought me in. Over the months, I was told the detailed story. There was one consultant in particular, whose work I constantly had to correct or rebuild due to errors and performance issues. No mentality of quality focussed work or adherence to standards. And a lot of mistakes.
The client was amazed at how fast I was able to deliver my work. Where, for an equivalent piece of work, I was able to deliver (a stable, high-quality standards-based product) in a day, the other consultant would take two weeks! Further, at one point, he apparently told his other external colleagues "Don't work so fast, you guys"! In his mind, the longer it took to deliver something, the more he could bill!
This guy was clearly an extreme case, but there is a lesson to be learned here. It is normal on the market that a client should bring in an external resource to deliver work that they cannot perhaps do internally. However, a small investment in preparation will not only protect you from this kind of exploitation, but also position your development environment and culture for the future.
Here are my recommendations:
- Define Standards of Development (eg. Database, Software, ETL, etc.)
- Define Naming Conventions (DB Tables, Applets, ETL jobs, objects, etc)
- Define or adopt a methodology for development.
- Define acceptance processes that enforce adherence to these
- Once work has been rejected once or twice, developers will change their mindset
and the development culture will evolve towards delivering at a higher standard
of quality and instances of rejected work should diminish.
- Establish Code Libraries; Templates; Shared objects
- Benchmark expected development time for a "standard component"
This last point serves as the tool for protection against exploitation such as I described above. My client now has the templates that I delivered, and they know the expected development time for a given "standard" piece of work.
This helps the PM with estimating the level of effort for delivery, and also gives them a tool to protect themselves against unscrupulous consultants. They are out there.
Wade C. Walker 
Methodata Sàrl
(0)78 708.36.34
www.methodata.com