Getting Organized: Planning website projects

With the management of a large, ever-changing website comes the management of the individual projects that make up that website. The Smithsonian Libraries’ website is made up of many components, most of which were or are treated as smaller projects that have limited or ongoing scope. We’re in the process of testing and refining a documentation process by which our staff can propose and define additions to our site.

Given the diverse nature of our content and the varied expertise of our staff in a wide range of topics, we planned and developed our website such that any of our staff could manage the content for which they are an authority. At the same time, we knew we needed a process by which our staff could request changes to the site beyond simple content changes to existing pages.

To this end, the Web Services Department developed a document to help our staff plan the development of a new section of our site. The document is cleverly called the “Web Project Planning Document”.

The document is designed with two goals in mind:

1. Collect the information necessary for the Web Services Department to build the project into the website.
2. Guide our staff through all of the things that need to be considered when developing for the web.

Generally speaking, we cover the  who, what, when, where, why, and how of the project. But since that’s a bit vague, the topics that are included in the document are:

• The version of the planning document to help track changes.
• Instructions on how to use the planning document.
• An overview or summary of the project.
• The business need or problem that is being filled.
• Target audience.
• Desired time frame for completing the project.
• Staffing needs.
• Strategic information and relationships to other documents.
• Grant or funding information and requirements.
• A description of the content or data for the project.
• Specific functions or activities of the website.
• Wireframes or sketches of the pages of the website.
• Communication and “marketing” needs.
• Training plan.
• Ongoing maintenance plan.
• Technical needs and Web Services Staffing.

There are many items on this list and though it may seem like there is a lot to cover, some of these are simply yes or no questions to indicate that this is part of a larger puzzle or that there are other things that need to be considered.

Also, it should be clear that not all of these can be filled in by the staff member making the request. Some of these must be filled in by the Web Services Department staff. For example, the “Specific functions or activities of the website” can be described by the requestor, but the Web Services Staff needs to plan the technical details and implementation of the function which often raises other questions.

The ultimate goal of this document is to streamline the process, reduce the number of meetings we have, and document the project both for current , ongoing  and future needs.

So far, we have used this document for two completed projects, with two in active development, and at least two more (that we know of) in the works. The idea behind the document is that the Web Services department doesn’t really know about a project until we receive the first draft of the document per the instructions. It’s at this point that we get a chance to look at it, start our technical analysis of the project, and meet with the project owner before handing it to our Digital Library planning group for further consideration and discussion.

Up until now, we have received positive feedback on the document, but we recognize that it, and the process that supports it, can always be improved or altered to work better in our organization.

Do you work on a website? Do you have a process similar to this? If you do, let’s hear about it in the comments!

Happy coding!