What determines the success (or failure) of a Web development project?
While there are many important factors (both on the client and developer side) there are two all-powerful prime lynchpins that will make or break even the most qualified participants: Perspective and expectations. Some time ago I made a blog post on perspective, in this second of two posts I’ll discuss expectations.
Success in almost any transaction or relationship is determined by establishing and meeting a set of shared expectations between parties. A $3 meal at a McDonalds can be just as successful as a $200 meal at a Smith & Wollensky Steakhouse. The same degree of success can be realized at both regardless of the vast difference between a dedicated waiter serving dry-aged prime beef and a mass produced sandwich handed to us in a crumpled paper bag. It’s all about us getting what we expect.
When a client and developer view a project from a shared perspective, setting expectations is the natural progress of collaboration. Without the collaborative systematic development of a set of shared exceptions we risk orchestrating an iPod dance party. Both parties may participate but they’ll each be in their own world and when the music stops they will have completely different perspectives from which to determine success.
Developing a shared perspective is the responsibility of the developer and starts with listening, interrogating really (in a nice way, without the light), to the client and extracting the core business goals of a project, the details of the client’s unique value proposition, the needs and profile of their customers and other such vital information.
Provocative and challenging questions should be presented to the client in this stage to help them gain an outside perspective and the developer needs to be willing to adjust their biases so that in the end there is an unambiguous meeting of the minds about the project goals. In addition to the primary goals, there are many technical parameters that need to be discussed and agreed upon including development environments, creative parameters, branding continuity, etc.
After goals and requirements have been collaboratively determined, the developer is responsible for drafting a formal systematic development process that articulates the specific developer tasks that will be provided to meet those goals, and establishes a work-flow time frame for project completion.
All of this is not that profound or new. It’s really just common sense. But from my observation, the temptation is often great to gloss over a formal development of a shared perspective and expectations. It’s usually in the context where the client and developer develop good initial rapport and feel confident that they’re “on the same page.” Feelings are great but Web development projects are too complex and expensive to rely on luck for success.