Creating a Website Project Plan

Posted by Donna Rouviere Anderson May 19, 2015

This is a sample project plan for a web project. In practice, each project is quite unique and the time frames and tasks vary accordingly.

Once a website client has approved your statement of work and gives you the go ahead to create a web project for them, the next step is to make a project plan.

We begin by making files for the project. These include a computer file, a hard copy file if we have notes on paper about the project, an email file and a project in Omnifocus. Each of these are labeled with the same name and color so we can easily find them. For hard copy files, we use colored file folders. If the project is huge, with many hard copy files, we use a bin and label it with the same name and color as the other files. We also add the client contacts to our phone contacts.

In the computer file, we set up sub files as needed, including at a minimum a file for mockups, administrative content and raw content.

We set up a simple communications plan so that we can provide regular and milestone reports to clients. We decide what contacts will receive these brief reports.

This plan includes the following procedures:

  • We provide clients with regular and milestone reports on the progress of a project.
  • We try to confirm in writing all important information from informal discussions with clients.
  • We address any surprises or major information with clients immediately rather in our regular reports.
  • As it will be necessary to communicate with clients throughout the project in phone or in-person meetings, we try to do the following in those meetings: Clarify the purpose of a meeting and who needs to attend it, give plenty of advance notice of the meeting and its agenda, keep the meetings to less than an hour, start on time and take notes of the discussion, decisions made and assignments. We make a list of action items from each meeting and assign responsibility for them in Omnifocus. Then we monitor the progress of all action items on a daily basis. When meeting with busy managers, we pick out a few key messages to emphasize in short presentations. We gear the messages to the interests of the audience and explain how the project is addressing those interests. We allow time for questions. We present information about risks involved with a project and how they are being addressed. After the meeting, we send out emails highlighting the issues raised and the actions agreed upon.

After setting up this preliminary structure for managing a web project, we create a preliminary project plan, using Omniplan as a project management tool. This includes:

  • Do a work breakdown structure, identifying all major assignments, tasks under them and sub tasks in Omniplan.
  • Make assumptions about uncertain activities and plan to change them as we proceed, recognizing that most web projects change during development. Identify all unknowns that we need to make contingency plans for.
  • Identify any preexisting templates we can incorporate into the project. Put copies of them in the computer file.
  • Identify the basic products and results and when they will be produced during the course of the project.
  • Identify roles and responsibilities and how we will work with each other on each of the project's activities.
  • Identify the required resources – funds, technology such as modules, software licenses, content, information, outside technical experts. If the project requires us to travel or take photographs, we make a sub plan that includes these tasks.
  • Identify the order in which things must be done – what tasks are dependent on preceding tasks and what tasks must be done before succeeding tasks can be completed.  Mark the activities that are dependent on each other with designated paths.
  • Mark the critical path.
  • Include tentative start and end dates for each task, recognizing that many will change but they give us an idea of the overall time the project will take.
  • Consider ways to shorten the critical path or other paths.
  • Consider any legal requirements that certain things be done before others, client company policies that require certain activities to be done before others, deadlines for having certain tasks completed, relationships between various activities, and any arbitrary decisions by the client to work on certain activities before others.
  • Make a tentative schedule based on the project plan.
  • Make task lists for each person who will be involved. Look at them with each person and see what has to be adjusted. Revise them until we get their approval.
  • Adjust the plan to accommodate other projects we are working, holidays and other work activities to avoid overcommitting ourselves.
  • Make a detailed budget estimate with labor costs for each activity and the cost of any materials, technology, travel, outside services or products or other resources.
  • Set up a way to keep track of our labor and materials costs as well as any information we will need for taxes. 
  • Add 10 percent to the time the project will take as well as the budget to make sure we get it done in plenty of time and within budget.

Consider the risks of the project and make a plan to eliminate or manage them.

Make sure the project as outlined will solve the client’s problem and that it is not too large.

Make sure you have the required skills.

Consider the risk of budget overruns and be upfront with the client about that possibility.

Consider the risk of untested technology.

Make sure the strategy for the site is clear.

Make sure that the client’s deadlines are realistic and are not made by backing into an arbitrary end date with no historical information of how long it has taken to perform similar activities in the past.

Divide the project into realistic phases.

Consider the likelihood of the risks and their impact on the total project.

The most common risks involve working with clients.

Web design and development are highly specialized skills that many new clients don’t understand well. If they haven’t worked extensively on a web project before, it is common for them to underestimate the complexity of their project and the time and effort on both their part and ours that it will take to complete it. They often make suggestions that violate standard web conventions and don’t understand the importance of sticking with those commonly understood practices. Other issues they often don’t understand well are the importance of adjusting websites for various devices, having a clear, consistent graphic style and that making websites simple and user friendly can require compensating complexity in the coding. 

Some clients start a web project and then get busy and don’t provide needed content or feedback in a timely manner.

Many if not most clients don’t have the skills to provide content in the format that is needed on the web.

The vast majority of these clients are intelligent people who are skilled in their own field, but recognize that they need our expertise to translate their vision and needs to the web. We assume that they are approaching us as an outside consultant and it is our job to help guide them through the process of creating their website. Our work approach with them is to be polite but direct and specific about the entire process and what we can provide as well as about the capabilities and limits of technology and their budget. This approach works well with most clients. 

Infrequently, we acquire a new client who wants to simply order us around and ignores the advice we give them regarding best website practices. This problem can vary in scope with clients. If they are generally good to work with but have a blind spot in a specific area, we look at whether their desire is possible technologically. If so, we inform the client of the drawbacks of their approach and how it will reduce the effectiveness of the website and then do as they instruct us even if it is less effective. If it isn’t possible, we simply tell them so and why.

In the very rare case in which a client’s general top-down approach and desires would make a site unworkable, we notify them upfront that their approach will not work. If they won’t modify it, we tell them that we can’t proceed and they’ll have to find another solution.

Some clients believe that purchasing a web project is like purchasing a pair of shoes – a one-time deal. We try to avoid this misconception by helping them to understand that websites are like pets – they are a changing and developing media from the beginning and have to be kept up to date with new content and upgraded technology as well as marketed if they are to be successful. We tell them that we try to set up a system from the beginning that can evolve over time with a minimum of their time and resources. We help them to see their responsibilities by sending them a task list of those things that they need to provide for the website.

We sometimes wind up developing the contents of their website for them. This is fine if that is what we contracted to do. If it isn't, we let them know there is a problem with content and reach a solution.When clients provide poor quality photos, we put them on line in a development environment for them to see and then ask for confirmation in an e-mail that they are satisfied. Often they provide new ones or ask us to do so at an additional charge.  If a client provides text that is unsuitable for the web, we make minor changes to make it suitable and notify the client. Sometimes we provide sample text that clients can use as a place to start and they can then edit what we have written.

Another common risk is scope creep. The statement of work should define the scope of the work clearly, but most clients will ask for more once you begin a project. If the requests are significant, we inform them that they will impact the overall cost and schedule.

As we hit each milestone at which a client needs to approve parts of the project, we make sure the client understands that after they approve that phase, further changes will require additional labor and cost. Outline the impact and give a time and cost estimate if the cost difference of a request is significant. Give the client the option to proceed or cancel the request.

Most clients have both good and bad ideas about what they want on their website. Support the good ideas and eliminate the bad ones, tactfully. Just explain your concerns and why you have them so that you show that you have the client’s best interests at heart. If the client doesn't accept your point of view, consider providing references to information that will support your point of view. If your client still wants the idea incorporated into the site, put it in if it’s technologically possible.