Part one of this column focused on the symptoms of under and over-engineered Web sites. The final sentence of part one was “If we all know better, why do under and over-engineered sites happen and how can we avoid them?” I will attempt to highlight some of the causes that I’ve encountered over the years and perhaps shed some light on it as a means of avoiding the trap.
In the simplest terms there are two basic causes of under and over-engineered Web sites. The two basic causes are: 1) Wrong or lack of information from the client and 2) Not listening to the client.
To truly understand the above, one needs to define the client. In the simple terms, this is the primary stakeholder of the project. This is not the project manager, the business analyst, nor the primary contact. It is the person who ultimately holds the final say and has championed the project. Most projects that have gone astray have started with the client. No the client is not to blame, but the development process and ultimately the role of the client is.
The first mistake many people make is not listening carefully to the client. While the client has championed the company for not only the moral approval of the project, they have also secured the necessary funds to make the project a success.
This is where the biggest mistake on a project happens. All too often, the development team grabs its portion of the project along with some basic overview of what the client wants and heads straight for their computers where they set-off to build what they think the client wants. Little thought is actually placed on the budget and what it truly represents.
What the backend boys and girls need to do is figure out, exactly what the client’s vision is and be aware that it may be slightly different then what was written in a business proposal. Why this difference? Remember, that in most cases, the client doesn’t have the technological wherewithal to define the project in the required technical detail and instead paints it with broad-brush strokes of grand vision.
Another problem may have arisen by using the original business proposal.
If proposal figures are taken at face value, it is easy to over or under-buy on server capacity. Make sure that you talk to the client. Ask questions like “How long do you estimate it’s going to take to capture that 10 per cent of market referenced in the proposal”. You may be surprised by the answer. If it’s more then 18 months out, target your technical requirements for 12 to 18 months out.
Assuming the math is correct, the development team needs to determine the best technological solution for the project. All too often this fundamental decision is taken right out of their hands by corporate IT policy. These policies made to make life simpler in the corporate world, may actually be costing corporations a fortune.
They include, standardizing on specific hardware and software. If the best technological and financial solution for the project is Linux, Perl and SQL running on a small server and the company has standardized on a brand name Unix servers, Java and Oracle, the project may cost hundreds of thousands more in addition to the over-engineering of the site.
The same situation may result in an under-engineered site. In the case of the under-engineered site, a particular solution may be chosen because the development team simply wants to stick to what it knows to avoid the steep learning curve and to deliver the project within a given time frame.
So how do we learn to listen better and to build the right solution? The key is to ask the clients the right questions and to listen carefully to their answers. Don’t simply take what they say for granted. Every client in the world wants it yesterday (hey that’s when they thought of it), we need to convey to the client what a realistic development schedule is along with the requested feature set.
When it comes to choosing the technology, try to make the right decision. Not only for the short term, but the medium term as no one knows what the long term will bring. If you don’t need the latest and greatest software and hardware to build it then don’t use it. You can be the hero by bringing in the development phase of the project in under budget and on time.
These are just a few of the more obvious things that can go wrong when building the backend. With so many other possible things that can go wrong in the development of a Web site, one must always be on the lookout for other things that can go wrong. The only way to prevent under or over-engineering is to empower the entire Web development team and to have them check their egos at the office door. If a system engineer believes that forecasted volumes by the client are too high, let the engineer talk to the client or the business analyst and they booth should have a comfort level before any equipment is ordered. If the front-end developers don’t understand why a particular database or server technology is being used, let them ask why and find out. It’s only by having everyone on the project talk to each other that the group can all learn and potentially spot under or over-engineering before it gets programmed or purchased.
One last thing to consider: under this model everyone is responsible to ensure that a Web site is profitable therefore, everyone needs to know how the site is going to make money and what the forecasted revenues are. Without this information, no one can make a proper decision on how much to spend on hardware and programming.
K’necht is president of K’nechtology Inc., a Toronto-based Internet strategy & consulting company. He can be reached at alan@knechtology.com.
