The contract is signed and you’re ready to embark on the exciting project of building a new website for your business. Before you get started, it is a good idea to look at some of the mistakes that are commonly made in all phases of website projects. Avoiding these obstacles from the beginning of the project results in a stress-free, efficiently-completed website.
The contract is signed and you’re ready to embark on the exciting project of building a new website for your business. Before you get started, it is a good idea to look at some of the mistakes that are commonly made in all phases of website projects. Avoiding these obstacles from the beginning of the project results in a stress-free, efficiently-completed website.1. Not Having a Clear Objective and a Solid Plan of Action
I previously discussed the importance of setting S.M.A.R.T. (Specific, Measurable, Attainable, Relevant and Timely) business objectives for your website. However, the objective alone is not enough. There must be a solid plan of action designed to achieve the objective. It should be backed by market research, stakeholder and customer interviews, competitive analysis, and more. Your web developer should provide you with a plan of action as part of their proposal. Make sure you read it, understand it and agree with it.
A customer came to us, and when asked repeatedly about their objective, consistently responded, “…a website that works better for my business.” We immediately slammed on the brakes and sent a worksheet to the customer to establish S.M.A.R.T. objectives. Only when concrete business objectives were set, did we continue. The customer was happy with the outcome, and as we learned later, our project was their fifth website redesign in two years. All previous websites were built with the same “better for my business” objective. None of the previous websites actually improved their business.
Bottom line: Ensure that both you and your web developer understand the key objective and that you have a specific and a realistic plan of action to arrive at your “destination.”
2. Interfering and Doing your Web Developer’s Work
Let the web developer do the work you hired them to do. When it comes to creating websites, many people think they know better than their developer. They simply don’t and neither do you. Teams of professionals spend their entire careers perfecting their skills. The best thing you can do for the project is let them do their job. Provide constructive, relevant feedback but don’t interfere, and don’t do the work for them. When in doubt, give your web developer the benefit of the doubt. Listen carefully to what they have to say. After all, you hired them for their expertise.
A customer took some graphic design classes in college many years ago. When the time came to redesign the company’s website, she dusted off her 1996 version of Corel Draw, and every revision of the design we proposed was followed by her rendition. This psychedelic nightmare looked more like a 70’s tailgating banner than a modern website. The customer was having fun designing her website. Our design department was weeping and loading up on Prozac. The catastrophe was averted when we asked if we could present her design (for feedback) to an independent expert. Feedback contained mostly expletives. CorelDraw quickly found its place back on the shelf, and the design team finished the project, which was to become an award winning website.
Bottom line: If you micro-manage your web developer, not only will it wreak havoc with your project, but it will result in a mediocre, unattractive and dysfunctional website. After the fact you will have no one to blame but yourself.
3. Designing for You or Your Boss
In addition to the previous mistake, one that unfortunately happens too often is when the customer undertakes the role of a designer. It seems so easy: “Let’s try this picture…Change that color…Move this here.” Bad idea. Again, you are not a professional web designer. It is important to understand that the website you are building is not to satisfy your personal taste, or that of your boss. It is designed for your customers. Inevitably, some may not like it, while others will love it. This is where a web developer’s expertise enters the picture.
There are bosses and then there are BOSSES. This one was THE BOSS. From the first meeting we realized it was going to be “my way or the highway.” The entire marketing team was scared to even think differently than their President (let alone voice their feelings). The President was very opinionated and, even worse, 100% wrong every step of the way. When asked about his responsibilities, the Marketing Director admitted that his head was going to be on a platter if the website didn’t perform. We mailed him a nice porcelain plate that said “His Way” on it. It was heard loud and clear, the Marketing Director found a way to take the project into his own hands and followed our lead to a successful outcome.
Bottom line: Don’t build a site that you or your top executives will like. They are not your website’s target audience. If they insist, give them this to read.
4. Making Assumptions and Lacking Proper Communication
“But I assumed this was included…I assumed you will write and populate the content!”…We assumed we can change anything we want!” Do these statements sound familiar? Have you ever been in a situation where you and another person are clearly not on the same page? Unfortunately, this also happens with website projects.
The last thing you want is a surprise that a feature you feel is essential to the project is actually outside of the project's scope or developer’s capability, and will take extra time and incur greater cost. Think about it: Did you communicate to your vendor the specific need or requirement? If not, it is unreasonable to expect that your vendor should understand your expectations. After all, they can only price out and deliver what you requested. Just as you are not going to sign a blank check for your project, you cannot hold a web developer responsible for an aspect of the project that was not communicated to them.
“Why didn’t you tell me it wasn’t included?” a customer asked. We inquired, “Did you communicate this requirement to us?”, “Did you see it in the proposal?”, “Did you ask us to include it in the proposal?” They responded “No” to every question, and subsequently got the point. We quoted and developed the feature separately, and the issue was resolved. We also explained that the customer didn’t lose any money, because if they had requested the feature initially, we would have quoted it separately anyway. We did, however, lose time, and the customer’s expected completion date was not met because of this lack of communication.
Bottom line: Talk to the web developer every time something is not clear or if you feel they’re not clear on a particular detail. Don’t be afraid to repeat yourself, and summarize what they tell you. At that point, ask them to reiterate their understanding of what you conveyed. You may be surprised how many details are caught in this process.
5. Changing Your Mind and Getting Hung Up on Details
“Let’s remove it…No, put it back…Let’s try it in green…No, blue…No, that’s too blue…Let’s go back green.” Not only will you drive the designer crazy, you are wasting time and money. At some point most companies would start billing you extra for waffling in this manner. What’s even worse is that you are throwing a wrench into the entire project flow. Change of direction is the number one enemy of proper project planning. For some people it has to do with their indecisiveness. Others decide to take the designer role by requesting that their web developer try every possible color combination (see previous section “Interfering and Doing your Web Developer’s Work”).
If you can’t adhere to the project flow, you’ll go in circles. You’ll be late and over budget. The solution is simple. If you make a decision, stick to it. If you are not sure, give the professionals you hired the benefit of the doubt because of their expertise.
Despite our advice, a customer decided that the way to achieve the best possible logo design was to try all possible combinations of fonts, colors, shapes and taglines. It took them almost six months and thousands of dollars in going back and forth to decide on something… decent. Our designer had created a logo that blew theirs out of the water in six hours.
Bottom Line: No detail is too small or insignificant, but obsessing on aspects that aren’t relevant, have little impact or marginal improvement, may cost you very real time and money.
6. Nickel and Diming
Would you ever sign a blank check for your website project? Of course you would not. Yet, this is essentially what many companies expect of their web developers when embarking on a website project – the whatever-it-takes approach for one flat fee. The philosophy is “I am paying you a lot as is, so you shouldn’t charge me extra for any add-ons.”
Always avoid this approach. Just like any other business relationship, it’s symbiotic. You need a quality website, and your developer needs projects like yours to make money. You may think you have the leverage to pressure your web developer into doing free work, but in reality you’re shooting yourself in the foot. As a customer you have to understand that it’s likely you’re paying a fixed fee for a specific project. This means that the developer evaluated the scope of work and has a certain budget for your project. Asking your web developer to add work outside of the scope will take them quickly over budget, making the project less profitable for them. This results in a web partner who loses interest in your project.
Many years ago we were working with a customer who was making highly unreasonable demands that often included adding and changing elements after the job was completed. The customer lacked direction and planned poorly at the outset of the project, so to compensate for this, he employed these tactics at the project’s end. These actions were, of course, at our expense. After several additional projects, we flatly refused to do any more work at the fixed quote and offered to transition to an hourly rate. Once faced with additional costs, because he lacked clarity, the customer’s planning and communication improved markedly, as well as the timing and the quality of the resulting product.
Bottom line: It’s important to understand that requests for anything outside the project’s scope such as additional features, changes of direction, post-approval changes, excessive revisions and ”waffling” result in an increased cost to the developer, which passes on to you. Adopt proper planning and communication from the beginning.
7. Rushing or Imposing Deadlines
A world-class website requires careful coordination of many activities performed by different teams at different stages of the project. You must factor in proper timing for communication and management, review and feedback by your team, testing and quality control, etc. All these aspects of the project must be given sufficient time. If the project is rushed, or corners cut, the compromise will most likely be evident in testing and quality. This is a bad idea. By saving a little time now, you will inevitably spend a lot more time and money to fix problems that could have been easily avoided with proper planning and timing of all activities. In the end, rushing a project guarantees a loss of quality. If a cake is taken out of the oven too soon, it won’t be done, and if you raise the oven temperature, the cake will burn. You can’t rush a project to completion. Another mistake to avoid is planning other activities (such as marketing campaigns, product launches or important presentations) that assume the date of completion will be met, without first consulting the developer. By doing so you assume all the risk if the website is not ready by the date you planned. The website project then becomes a point of stress that will incur additional cost in time and money to repair, because quality was compromised or corners were cut in order to meet unrealistic deadlines imposed.
A customer was not happy with the date of completion we set for the project, asking to get it done sooner. None of our arguments were working. “Well, I understand, but why can’t you add more programmers?” he kept saying, not realizing what every experienced project manager knows: adding more people to a project often slows it down even further. Then I remembered what my college professor said, and that got my point across, when I told him: “It takes a woman and nine months to make a baby. You can’t add eight women to make a baby in one month.”
Bottom line: Always allow the developer a reasonable amount of time to get the job done. Remember, rushing your developer will often be at your cost and peril. On the other hand, deadlines should always be in place. Proper planning and scheduling is vital to every project’s success. Have your developer set realistic deadlines, and hold them accountable for meeting them.
8. Letting IT Call the Shots: Tunnel Vision
IT departments love to put in their two cents when it comes to your company’s website. After all, it is their job to review, approve and recommend the best possible technical solutions. There is nothing wrong with that, with one significant exception. Remember, left-brain versus right-brain? A modern website is a lot more than a series of code, a database and a Content Management System. While your IT department may understand the technical side of the website very well, they most likely do not fully understand other essential components, such as marketing and design. All are critical to the success of your website.
The IT department in a medical company was insisting on using a specific programming language and a Content Management System, because they already had it in place. We asked their manager if they tell their doctors which medication to prescribe just because they “have it on the shelf.” Our point was made, and we were allowed to select the appropriate medicine for their website
Bottom Line: If you want consistent, world-class results, don’t let your internal teams implement or impose tools, solutions, technologies or otherwise force the hand of your web partner. It will cost you in extra overhead and will not lead to the expected results.
9. Avoiding Responsibility
Generally, the more experienced and expensive the web developer is, the more hands-off approach you will need to adopt when working with them. A good firm will know your specific business needs, and they will achieve the goals you set, while holding your hand throughout the process. Less experienced firms will need more guidance and input from you. Regardless of the capabilities of your web developer team, you should remain an active participant during the project. Although you should not micro-manage your web developer, you should assume responsibility for the following three roles:
- Ensure clear communication between all parties, especially on your end.
- Proactively adhere to milestones and request regular updates to stay informed on progress.
- Carefully review deliverables, and provide timely feedback so the developer can incorporate it into the project.
No matter how “hands-off” your project is, it’s your job to be proactive in seeing that these steps are completed. Avoiding responsibility during the project may result in project failure, and you will have to take on more responsibility later in damage control.
We were hired to build an internal company’s website (an Intranet). A customer representative who is always busy provided us with less than ideal requirements and then quickly approved all of the deliverables. It was clear they didn’t take the time to review, so we asked them to review it again. “Everything looks good!” was the answer. Things weren’t as good when the end users actually started using the website. Many of the key features they needed were missing. Since this was never communicated to us and wasn’t even discovered prior to the website’s launch, it required emergency upgrades, costing more money, time and stress for everyone involved.
Bottom line: Even the best web development company in the world can’t intuitively know that what they’ve built is exactly what you wanted and needed. Your thorough review and approval of the work is imperative to the success of the website.
10. Allowing Feature-Creeping
Featuritis (feature creeping) brings your project to a screeching halt. This is what the IT industry jokingly calls the tendency of uncontrollably adding features and elements to a project in progress. Featuritis is typically caused by enthusiastic customers who request additional items be added to the website because they feel the features will improve the website. Unfortunately, the result is often the opposite. First, the complexity increases as features increase. In other words, if you double the features, you can expect the complexity to quadruple. This has a similar effect on the project’s timeframe and the budget. Secondly, the rule of thumb in web development is always simpler IS better. Users expect a website, regardless of purpose or objective, to be simple to use and understand.
A customer repeatedly added features to a website delaying the project by over four months, and they showed no signs of stopping. We insisted that we finish the current phase and that we go live despite the customer wanting to add more elements. Once the website was live, it quickly became apparent that many of the features the customer initially wanted were not desired by the users. In fact, we received feedback that was quite the opposite of the customer’s expectations, and we were able to reroute resources toward the features the users ultimately wanted versus what our customer requested initially.
Bottom line: After you have a well-defined project that contains all the features integral to the concept, you should draw the line. The rule of thumb is avoid adding elements to a project unless they’re necessary to the finished product. The best approach is to break the project into separate phases or iterations. Maintain a “wish list” or a list of ideas and features as they come up, and then reevaluate the need for them following each phase.
