Top Ten Risks to Your Website Project
These are not necessarily in order of severity as certain risks can be more damaging to certain projects. It isn't an exhausted list either (just our personal favourites). For each one, I've provided an explanation (and in some cases, an anecdotal admonition).
Risk Number One: Not Being Prepared Before the Project Begins
Risk Number Two: Inability to Make a Decision
Risk Number Three: Limited Accessibility to Main Contact / Project Manager
Risk Number Four: Main Contact Does Not Have Enough Authority
Risk Number Five: Too Many People Involved in the Decision Process
Risk Number Six: Fixating on Low Priority Details
Risk Number Seven: Huge Change Requests Late in the Project
Risk Number Eight: Underestimating the Project Timeline
Risk Number Nine: Unable to Appreciate Causality
Risk Number Ten: Gremlins
Before you start the clock on your project timeline (actually, before you even contact a web developer), gather all the available information you can. A basic list includes:
- Goals of the website
- Known functional requirements
- Ideas and requests from people you have consulted within your organization
- Design details including copies of images, logos and banners that will appear on the site
- Branding information
- Inventory of Content (types of content that will be on the site and a record of existing content)
- Information regarding existing providers (e.g. email hosts or merchant accounts for e commerce you currently use). It's helpful to plan who will be responsible for communicating with these organizations should the need arise and to be aware of any relevant contractual obligations/compatibility issues that will affect the new site
- A list of content contributers, migration team, planning team/contacts, and people who will need to be trained
Nothing has to be written in stone. A development team can help you refine and adjust the details as you go along. Being armed with information not only speeds up the development process, but helps to clarify your needs and expectations.
Until you tell the developer how you want a particular section of the website to function, that section cannot be built. Until you provide the designer with answers to questions about basic visual details, your mockups (preliminary designs) cannot be started. Until you provide the information architect with answers to questions about content, it can stall design AND development. Until you tell the project manager that specs on functional requirements and quotes have been approved, the whole team stops. Sometimes what might seem like a small decision is in fact a big decision, and it can cause serious delays to all areas of the project.
When entering into the development process, the client is asked to identify who the 'Main Contact' will be on their team. This is the person within the client's organization who is responsible for communicating - and approving - details about the new website to the development team.
Whenever the development team has questions, answers are needed before they move forward. The longer it takes to get those answers, the longer the project is delayed. For a full explanation of expectations, please read Clients: Before You Utter the Words "Yes, I'm available"...
So you've picked a Main Contact on your team who is familiar with the content that will appear on the site and who will be available to answer questions during the design process. Great. But does that person have final sign off on decisions? If this person does not have the authority to green-light action on the website, it will cause delays while whomever DOES have the authority finds time to meet with the contact, review the proposed plan, approve it and communicate that to the team.
For example, I worked on a project where the main contact had to go to his supervisor, who then went to HIS supervisor, who THEN took it to a board of directors. Needless to say, sometimes it took over two weeks to get a simple yes or no answer.
You've heard the saying "Too many cooks in the kitchen", right? It is so very true in the development process of your website. Asking various members of staff (and potential users) their opinion on what they would like to see on the site can be very beneficial. It can give you a sense of what is missing on your current site, or what the expectations are for the new one. This could and should be done before the website development team has even started their work, especially if a number of staff members will be hands-on once the site is launched.
INVOLVING this large group of diverse people directly in decision making during the development process is something altogether different. The longer it takes to make a decision, the longer the development process will take. Allowing too many people a 'final say' in major decisions makes it more difficult to schedule meetings and to bring the group to a consensus. You also open yourself up to conflicts that are about 'office politics' and personal agendas rather than the goals of the website.
If you like, you can skip the story below and go straight to the next risk.
I was once working on a project for a huge website with countless - and I mean 35 or so - departments who were accustomed to having control over their section of the website. This had resulted in thousands of pages of content that was unnavigable, disconnected and often duplicated. Each click lead to pages that were so different (in layout, information presentation and even design), it made you feel like you had accidentally left the client's website altogether as you viewed each department's information. The client's goal was to reorganize the site into a cohesive layout that highlighted resources and information that had been lost in the labyrinth of content.
The heads of the departments had been consulted on what they hoped to find in regards to their section of the website. They were even involved in rating the importance of existing content within their department's pages (i.e. what should stay, what could go).
Near the end of the planning process, the client's team invited someone new from within the organization into our meetings. That person then invited someone else from another department. Suddenly, a review meeting with an agenda based on confirming the past two month's decisions and starting the next building phase had turned into an arena of (aggressive) dissatisfaction.
The new visitors had not been present for the painstaking brainstorming sessions that had taken place for weeks, so they did not understand the logic behind what was being presented at the meeting (they also made it clear that their department deserved more recognition than other departments). They were still attached to how the old site was run and laid out, despite the dysfunctional, messy eyesore it had resulted in. They couldn't envision the plan for the new site and therefore couldn't see the benefit of the new structure.
Almost the entire outline for the website was scratched (initially).
It delayed the project another three weeks. Two of those weeks were spent letting the two disgruntled employees (and who knows who else) take a stab at the main website navigation menu. The last week, after it became apparent why certain decisions had originally been made, was spent on tiny details that could have been addressed once building of the site had begun.
Don't sweat the small stuff.
During the development process, items for the website should be identified as being Low Priority and High Priority. Low Priority are details that can easily be changed, or items that "would be nice to have" if time and budget allows. High priority are items that are time consuming, sometimes difficult to change, and a "must have". The status of these items can be revised throughout the process. The point is to focus on the high priority items to make sure they are implemented first before the lower priority items are started. Don't cause a delay by fixating on a low priority your development team assures you can - and should - be dealt with at a later date.
This is pretty straightforward. If you decide to add to the original functional requirements (which generally outline all the 'High Priority' bits of customization you want) or make drastic changes to the way parts of the site will function, be ready for the delay this will create. Discuss with the development team what affect the proposed changes will have on the project timeline and budget.
It is commonly thought that a large website can be planned, designed, built, tested and launched within four weeks. People are shocked when they are told this generally isn't the case. Sure, a new basic site with little to no customization and an "out of the box" design (e.g. an existing drupal theme used exactly as it is) can be accomplished within 4 weeks assuming there are no delays.
The truth is, the planning phase alone can take from one week to two months depending on the project. Then you have to factor in the time it will take to build the functional requirements, to have the design created and approved, to have the templates for the design built, to migrate existing content or populate the site with new content, and to tackle problems found while testing. There is also training that needs to be scheduled on how to use the site.
A timeline is meant to act as a guideline to follow when it comes to the goals you wish to accomplish within a reasonable timeframe. It is better to overestimate the amount of time each phase will take.
Now that you have a better understanding of what can happen during the development process, I hope you have an appreciation for causality. Each phase of development affects the next. A decision about content affects when development or design can happen. If you don't know, say, how a list of content needs to be sorted, the developer can't build it. If you don't know the specific details of items that will appear on the homepage, the designer can't incorporate them. If one phase of development comes to a standstill, the rest of the project will most likely be delayed.
Something will go wrong. I don't know what. No one will know how. But something won't work the way it is supposed to. A little code demon will sneak in and cause some sort of conflict. It will defy logic, and will take some time to make right.