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:
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:
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!