tag:blogger.com,1999:blog-5996062652829415230.post4361188890568164862..comments2010-02-02T23:28:27.838-05:00Steve Hornhttp://www.blogger.com/profile/11799829988971859359noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5996062652829415230.post-87770694940843525962009-03-30T21:38:00.000-04:002009-03-30T21:38:00.000-04:00I agree with the developers bringing their own tools. My father is a carpenter and he brings the best tools to get the job done. I've tried to bring my own tools and had to fight with the admins to let me hook-up to their network. Unless you don't need any resources they have, then no problem. Also, if you are turning over source code for them to maintain in-house, just make sure they can continue without your tool belt.<BR/><BR/>I've seen my share of duct-taped systems. It's what I like to call the V'ger Syndrome (from Star Trek). The systems have been pieced together to a point that they are monsters looking to "join with their creators". They are out of control. However, this leads into your point of Less Tech and More Domain... it's usually a cost factor. All you can do is point it out without insulting (or chuckling too loudly) and just add some more duct-tape and twisty-ties and move on. Actually, I’m working on two projects now that require me to go to the hardware store every day. It’s amazing anything runs at all.Vgernoreply@blogger.comtag:blogger.com,1999:blog-5996062652829415230.post-51911149900987320622009-01-23T13:28:00.000-05:002009-01-23T13:28:00.000-05:00Probably the point I agree with most, but the hardest for the client to accept is the "Developers provide their own tools". Personally, I don't ask the plumber to leave his tools in the truck and use the tools I inherited from my grandfather. I can't say what the best way to accomplish this with security and compliance issues, but it is huge when you can't bring tools to the table for getting the job done. Tools for code refactoring, project communication, database syncronization, profiling and a host of others. Without these, you nearly neuter the developer and force him to spent his time doing manually what the tools would do automatically.<BR/><BR/>However, your emphasis on trust and partnerships have a shortcoming. Here's the rub...the contractor comes in and puts in the "quick fix" to "save the day" because that's what get the client back to making money. Was it the "right fix"? Was it fully tested? Will it be maintainable?<BR/><BR/>Yeah...by the next guy.<BR/><BR/>Personally, I think the bigger thing is always to create the trust relationship. If you can get the client to trust that you have their best interest in mind they'll generally let you do what needs to be done. You must prove that everything you do is going to add value to what they are doing.<BR/><BR/>Keep in mind...consulting should never be about "experimenting" unless the client knows it ahead of time. I have always hated the consulting company that will try to make every consultant an "expert" at all technologies just to get them billable.<BR/><BR/>As a consultant, does your company expect/reward you for being one of the best or is it for being the most billable?<BR/><BR/>If I were your client, and I know you are driven by being billable, I will always be a bit skeptical that you are working your hardest to "get done and get out".<BR/><BR/>When was the last time your consulting company left a client not because they couldn't pay, but because the project was finished and they were happy with the work done?<BR/><BR/>When was the last time you told a client you weren't adding value to the project and it was time to shake hands and part ways? I have--and it gained the respect that would get me invited back.Brian Sherwinnoreply@blogger.com