On the business side you have project managers, new business types (aka salespeople), and other bean counters.   These people basically care about money: making it and not losing it.  Making cool stuff is a fortunate side effect at best.

On the tech side you have developers and (in a way) UX types.  These people love solving problems.  Give them a problem, they want to solve it – preferably in the most awesome, beautiful and elegant way possible.  On a deep, soul searching, emotional level, they don’t give a flying crap about the money.

Funny things happen when members of these two groups speak with each other.  They describe things using the same words, but they mean fundamentally different things.

It’s very common for the business types in Group A to approach the problem solvers in Group B and ask them a question like “would it be possible to add some snazzle on the frozbot”?  At this point the problem solver gets a far-away look in their eyes and replies “yes, it’s possible”.

Hey, business types: the problem solvers are talking about something entirely differently than what you have in mind.  If you’ve just inferred from their response that you can squeeze that new feature into the project, you’re wrong.  At least potentially you’re wrong.  You actually don’t have any more information than when you started, because the problem solver’s answer actually contains no useful information to you whatsoever.

What you wanted to know was:

“Can I get this extra feature into this project,  it in a way so that I continue to make money?”

What they just really answered was:

“Yes, with nigh infinite time, resources and money, this snazzle can be retrofitted onto the frozbot, in a fabulous dimension of mind over matter where this crappy project doesn’t exist”.

Which, business person, was, of course, not your question.

You see, you thought the money part was implied.  And, to another business type, it would have been.  But as was noted above, the problem solver is not inferring that part.

So I propose you stop asking the question “Is It Possible” altogether.  It’s a useless question.  Instead, I suggest you ask “does it FIT”.

My new favorite acronym – FIT.  Feasible Inside Triangle.  The triangle being, of course, the classic project triangle of Scope, Schedule and Budget.  By including the triangle within the question, the problem solver has to take its constraints as part of the equation.

This is an adjustment at first, but they’ll get used to it.  The barre has been raised.  Business types can expect a lot more up-front pushback to “does it FIT” than “is it possible”.  A lot more “no way”s.  However this is better than the alternative, where people say “yes” and then a project disaster ensues.  FIT forces people to be realists.

This communication barrier between business and problem solver types is really dysfunctional, and has probably led to millions and millions of dollars of waste.  Let’s stop lying to ourselves about feasibility in projects, and keep our problem solving powers relevant to reality.

The idea of maintaining a single technology stack in a development shop is quite appealing.  If everyone knows the same programming language (the thinking goes), the same web framework, the same RDBMS and so forth, then life would be better.  Business really likes this kind of thinking.  It promises efficiencies of scale, reduced training costs, and easily replaceable employees.  This kind of “one true technology” approach is the foundational philosophy of corporate darlings Java and .NET.    Once you have the organization standardized on the tech, it is promised, then every part will play nicely with every other part, critical dependencies (such as employees) will be reduced, and the whole “what are we doing about technology” question just goes away.

Now, of course I support operational efficiencies, reducing training costs (well, to an extent: I view training as an investment), and so forth, but I think that the idea of “one true stack”, especially in service-oriented tech shops like web agencies, is a pipe dream.  The advantages of standardizing an entire company on a single tech stack are outweighed by the disadvantages.

Before I get into that, however, I want to introduce the idea of a “jealous” technology.  A jealous technology tries to take over as many aspects of the stack as possible; mandating a specific component at each level.  Some technologies are more “jealous” than others.  Microsoft is notoriously jealous:  the Microsoft web framework, ASP.NET, really wants to be deployed on the Microsoft web server: IIS, on the Microsoft operating system: Windows, backed by the Microsoft RDBMS: SQL Server.  Other combinations (yes, I know about Mono) simply don’t work as well.  And, on the other hand, Windows is something of a second-class deployment platform for most other web technologies (ever try to deploy Rails on Windows…with IIS?  Yuck…)

Speaking of Ruby on Rails, they’ve become a bit of a jealous technology themselves.  Rails projects now prefer a particular JavaScript framework (Prototype), version control system (Git), editor (TextMate), build system (Capistrano) and development operating system (OS X).  (As well as, obviously, programming language: Ruby). While it’s certainly not as bad as the Microsoft scenario,  I do have to ask the question as to why the web framework has any influence over what version control system I use.  Do you have to use all the technologies that I’ve listed above with Rails?  No, of course not.  But they are preferred.  Things go better with Coke Capistrano.

The point is that some technologies are better suited towards certain problems than others, and a blanket organizational standardization on a single tech stack leads to a tremendous amount of wasted energy spent on driving square pegs into round holes.  Ruby is not a great foundation for an enterprise-class messaging framework.  Java is not a good choice for a lightweight CMS.  And anything other than .NET is a bad choice for an app destined to be maintained by a bunch of MSDN types.

In fact, I’d argue that the cost of operation efficiencies lost by maintaining multiple tech stacks is exceeded by the cost of jamming technologies into inappropriate use cases.  So, as messy as it sounds, any technical organization that is project or service based (as opposed to being exclusively product based) should maintain a strategic “quiver” of different technologies, so it can deploy the best choice when faced with a business problem.  Otherwise a fragile monoculture is created, wasting a tremendous amount of developer effort, and adding artificial risk and expense to projects.

Over time I have identified 5 factors that clients bring to the table, that directly affect the outcome of a web project.  These factors can accumulate and ultimately swing the fate of a project from success to failure or vice-versa.

Here they are:

Don’t Be Overly Price Sensitive

Guess what?  Agencies are expensive.  If you want to build a website on the cheap, you probably don’t want to deal with an agency, you want to keep the project in-house as much as possible, and outsource the rest to individual contractors.  Quality can suffer this way, because you are now the web project manager (and presumably you have something else to do), but it theoretically can be cheaper.  Trying to pinch pennies with an agency can cause compromises in the quality or scope of your project that can be hard to predict.

Be Flexible on Features

Clients who want to control every last feature can lose sight of the main goal: getting a working web site that meets their business goals launched. In my experience, the best projects are ones with strict deadlines, but with some flexibility in scope.  Over the course of production, hard decisions may need to be made about whether features should be included in the upcoming release.  Generally speaking, being flexible on features, but sticking to the established release schedule, is the right decision almost every time.

Be Decisive

Clients who are indecisive, or who have decision-by-committee issues, bring risk to web agency projects.  The best projects are ones where there is a single project owner on the client’s side, who is empowered to make decisions and grant approvals about the web site.  The ability to provide clear, timely feedback and direction to the web agency is essential.  On the other hand, a client that waffles, takes forever to make approvals, or sends mixed signals to the agency just makes everything harder.

Trust and Defer

Trust the web agency, they know the web, that’s what you’re paying them for.  If you don’t feel like you can trust them, then you shouldn’t hire them in the first place.  In order for an agency to operate efficiently, it needs a certain amount of autonomy and independence from the client.  Only then can it employ its internal best practices, and do the best job it can.  Micromanaging an agency actually removes value for the client.

Be Savvy

Understand the web.  Understand your own business.  Understand how web agencies work, if possible.  The more sophisticated you are, the better the project will run.  In the past I’ve known clients who have asked for web sites, who never actually use the Internet themselves.  How could they make informed decisions about their own web site, if they spend no time on the web?  By taking the time to educate yourself about the environment in which your project lives, you’ll be stacking the odds in your favor.

There it is – clients that get all of these items right are a pleasure to work with, and they tend to get fantastic results from the agencies they use.  At the other end of the scale, clients that come down on the wrong side of all of these points can create situations that can be difficult or impossible for agencies to rescue.  By mastering these factors as a client, you’ll be doing the most you can to ensure the success of your project.