But some of the weary techies I’ve worked with (particularly middle-management types, for some reason) go off the deep end.  I like to say that when you encounter a technical challenge – there’s likely someone else who has also needed to solve a similar problem.  In the instances where that isn’t the case – you’re in a pretty good position to gain something from solving it yourself.  But truth be told, there are very few large problems out there that people aren’t solving.  And yet IT organizations continue to re-invent the wheel – even when economics and time tell them that they should look for an off-the-shelf solution.  This only leaves one real driver for making the build decision when the buy decision is so apparent: politics.  And often it’s the politics of the grudge.

I firmly believe that every shop I’ve walked into that has rolled their own MVC framework, or RIA framework, or rules framework contains an individual who truly believes that the cost of supporting, maintaining, and continuously developing that software is still less than the cost of taking a turnkey solution – either one that is commercial or open source.  I recently had a manager tell me that there was an increasing drive through the IT management structure that the enterprise should own the source and rights to all of the systems that it supports.  This was a crazy notion – are their boundaries to this doctrine?  Will we be writing our own application servers?  RDBMS?  Messaging systems?  Where does this cult draw the line?  And with a little more digging, and without much surprise – I found that this manager had spearheaded a campaign to adopt a particular Javascript framework for client development that ultimately failed and cost the company several millions of dollars.  His dogma seemed crazy, and it was. But it was completely motivated out of fear that technology selection, no matter where the accountability lay – was an avoidable cost of enterprise IT, even if it meant adopting the more extensive cost of building all solutions from the ground up whenever the need arose.

I guess the moral of the story is really that as an IT manager, it’s important to recognize the power of the crowd (the community if you will) and the value it can add at virtually no cost to your organization.  That it’s important to understand why a 3rd party tool has been selected.  That it’s general limitations are known early on.  That your organization is prepared to adopt the tool as if it were it’s very own.  This means hiring experts who have used those technologies.  And above and beyond anything else, that when you fail – the goal must be to marginalize the cost of that failure.  You can hedge your bets, you can reduce risk.  But when the dust settles and a selected technology has failed the organization – be sure to take a good hard look in the mirror and be open about where the selection process has failed.

Sometimes it is the captain, and not the ship.

For my part, there’s only so much patience I have taking on the burden of supporting multiple browsers and dealing with performance issues.  Particularly if I’m Agile, and I’m focusing on delivering so much value so quickly, it’s very hard to explain to a client that the underlying technology creates significant overhead that adds drag to the project.  This is an even tougher sell – particularly when you’re open with your client, when alternatives that meet the non-functional needs exist.

For your standard web applications that aren’t as client-centric as today’s RIA applications, it’s certainly true that you are barking up the wrong tree with GWT.  Rails, Grails, and Zend can all give you the non-enterprise delivery tools that accelerate development from the server-side and leave the Javascript problem to be solved in a less holistic, more tactical way.

But it’s hard to argue now that anything short of the compilation semantics of GWT is useful in the RIA realm (without the need for a intermediate runtime, of course.)  Javascript is too costly and too brittle in large-scale applications to be subject to human hands.  If you’ve hired a contractor to build you a web-based RIA and they’re not using GWT – it’s well worth your wallet to ask them why.

“I have been outsourcing and modifying an Open Source project. There is about 50-100hrs of scoped development. Let me know your availability and rate.”

Jobs like this one are poison that really puts all of the burden on your shoulders.  I’ve been a consultant for several firms, and have lead delivery of many large and small projects.  Here are a few tips to make it so that you maximize the shared risk in a project, maximize your revenue, and ensure the highest possible customer satisfaction.

Always Price on Your Own Estimates

You’re the one doing the work, and you know how long it might take you to complete a given project.  If a potential client hands you an amount of scope and a timeline (like the real-world example above), I would always request to assess the scope yourself and provide your own estimate before committing to anything.  If the prospect is amenable to this, then it serves you well to give them a good faith estimate and some solutions in the case that your estimate is different.  If the prospect is time sensitive, then work with them on adjusting the scope.  If the scope is driving the project, then encourage them to consider an additional investment of time to ensure the completion of the full scope.  Be willing to make concessions on your rate in these cases – flexibility from the client should be greeted mutually with your ability to discount your own rate.

If the client is not going to be flexible, then your best bet is to walk away or mitigate your risk through a more premium rate.  Likely even in the latter case, a less saavy contractor will underbid you and find themselves in trouble.  Better them than you.

Avoid Fixed Price/Fixed Time Projects

Clients love fixed price/fixed time projects.  It removes almost all of their risk in the project and places you in the position of likely pulling quite a few late nights and reducing your hourly rate.  Large consulting shops, particularly offshore ones – have the ability to enter into these arrangements and blend their rate accordingly to account for the need for additional resources in the case that the project falls behind schedule.  For them, the cost of working a project beyond the deadline is significantly higher than it is to simply add more horsepower.  Project management and technical oversight adds overhead in the project, and vendors are more than happy to not keep them on an engagement any longer than they need to.

That said, time and materials (hourly) arrangements are the best for the independent contractor.  They place all of the burden to manage scope upon the client, and the client has to trust the vendor to report hours accordingly and honestly.  Always aim for these projects, but do be honest with your client about hours and estimates around the cost of the engagement to them.  Be willing to discount when your estimates are inaccurate.

Another option is a middle ground called target cost, but these types of projects are typically the result of significant trust between client and vendor.  Simply put, you bill at your hourly rate for the agreed upon scope and any additional scope, and a discounted rate for defects and enhancements.  This typically keeps both parties honest.  Clients look to control scope for the same reasons they do in T&M, and it’s in your interest to finish on time as to avoid continuing work at a discounted rate (when you could be taking on new projects at your standard rate).

Request Right of First Refusal

Clients are fickle.  No matter how good your work is, when times are tight (as they are now), they will search for less expensive options.  Many times when negotiating with clients, I have asked for right of first refusal in whatever contract we agree to as to ensure exclusivity.  This makes you the preferred vendor and allows you to take all work that you are interested in before it is made available to competing contractors.  Often times, this will require that you discount your rate.  Additionally, this is usually only received well once you have established a track record of delivery with a client.  But if you can negotiate this clause, it can go a long way to ensure you a consistent revenue stream and source of work.

At the end of the day, your client’s satisfaction will be the best way to maintain business and build a stable relationship built on trust.  Be open and flexible, but protect your position and never take on more risk than is neccessary, regardless of how desperately you want to land a gig.