Site Specification
TechShop Madison TechShop people

History
Resources

Developing a site/project specification


Web 2.0 Adapted from: http://webstyleguide.com/process/specify.html

OVERVIEW

The project specification is the planning team's concise statement of core goals, values, and intent, to provide the ultimate policy direction for everything that comes next.

Designing a substantial Web project is a costly and time-consuming process. When you're up to your neck in the daily challenges of the project, it can be surprisingly easy to forget why you are doing what you are, to lose sight of your original priorities, and to not know on any given day whether the detailed decisions you are making actually support those overall goals and objectives.

A well-written project specification provides the team with a compass to keep the development process focused on the ultimate purposes of the project. As such, it quickly becomes a daily reference point to settle disputes, to judge the potential utility of new ideas as they arise, to measure progress, and to keep the development team focused on the ultimate goals.

At minimum, a good project specification should define the content scope, budget, schedule, and technical aspects of the Web project. The best project specifications are very short and to the point, and are often just outlines or bullet lists of the major design or technical features planned. The finished project specification should contain the goals statement from the planning phase, as well as the structural details of the project.

Consider the following questions:

Goals and strategies

These questions are designed to get a big-picture understanding how this project fits into your nonprofit agency and how your project is going to help the agency. Most of our agencies this semester (Fall 2009) have some idea of what they want or have some experience with some element of web 2.0 technologies. But for many of these agencies the key information they are looking for is how to tie together these elements, or how to present them to the people they wish to reach. For those of you working with these agencies, finding the answers to these questions may be a substantial part of your work.

Be sure to read the agency's application as a place to start this discussion, you will want to at least check with your agency to be sure you understand their intentions.

-What is the mission of your organization?
-How will Web 2.0 features support your mission?
-What are your two or three most important goals for the project?
-Who is the primary audience for the Web project?
-What do you want the audience to think or do after having visited your Website?
-What Web-related strategies will you use to achieve those goals?
-How will you measure the success of your project?
-How will you adequately maintain the finished project?

Production issues

This section of the interview is to help you figure out what kind of social environment your work will take place in. In the past, some students have come up on a deadline not realizing that their contact did not have the authority to sign off on changes, and that extensive consultation was necessary before a plan could implemented. A vague project is vulnerable to many problems including scope creep (see below).

-Who are the people or vendors on the development team and what are their responsibilities?
-Who signs off on marketing material? Will they have that role in this project?
-Is there a design component, do the same people sign off on content and design?
-How much material will be created/integrated (Pages/blog entries/video)?
-What is the maximum acceptable count under this budget/time committment?
-What special technical or functional requirements are needed?
-What is the dollar budget and time budget for the project? Ongoing fees?
-What is the personnel budget for this project? Ongoing personnel?
-What is the production schedule for the project, including intermediate milestones and dates?
-What is the student role (e.g. training) and what is the agency role? Are these roles sustainable?

Design considerations

Often aesthetic decisions require the most consultation. Generally, everyone has an opinion about how things should look. Negotiating among these can opinions can be tricky. On one hand, getting many conflicting opinions can make it hard to please everyone. On the other hand, if you don't get buy-in from the critical people your design may never be implemented.

-Have you seen any examples of other projects that resemble what you are looking for? -Are there other marketing material that the project should mimic or borrow elements from (typeface, colors, logos, i.e. Branding)? -Can you be sketch out your ideas on paper with me and the other stake holders? -What accommodations might be necessary to make the resulting product accessible to all users?

Other TechShop questions to consider:
What if you don't know how to do what you've been asked to do?
How can you verify that you and the client are both on the same page?

These are big questions, and the broad conceptual issues are too often dismissed as people push toward the "real work" of designing and building a Web project. However, if you cannot confidently answer all of these questions, then no amount of design or production effort can guarantee a useful result.

Avoiding "scope creep"

The project specification defines the scope of your project — that is, what and how much you need to do, the budget, and the development schedule. "Scope creep" is the most prevalent cause of Web project failures. In badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned "features" are added, content and features are padded to mollify each stakeholder group, major changes in content or project structure during project construction are made, and more content or interactive functionality than you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury what might have been an elegant original plan under megabytes of muddle and confusion. The more general the initial plan is the more likely that scope creep will be an issue.

Another kind of scope creep is shifting responsibility for parts of the project without shifting resources. For example, if the people who have accepted responsibility for technically implementing a project feature are, upon their success, asked to create the content because the content team has not met their deadline. This might be an acceptable change, but only if resources (time, job description, recognition, money) are also allocated.

Don't leap into building a Web project before you understand what you want to accomplish and before you have developed a solid and realistic project specification for creating your Web project. The more carefully you plan, the better off you will be when you begin to build your project.

One excellent way to keep a tight rein on the overall scope of the project content is to specify a maximum page count in the project specification. Although a page count is hardly infallible as a guide (after all, Web pages can be arbitrarily long), it serves as a constant reminder to everyone involved of the project's intended scope. If the page count goes up, make it a rule to revisit the budget implications automatically — the cold realities of budgets and schedules will often cool the enthusiasm to stuff in "just one more page." A good way to keep a lid on scope creep is to treat the page count as a "zero sum game." If someone wants to add pages, it's up to them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to account for the increased work involved.

Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project. Any substantial change to the planned content, design, or technical aspects of a project must be tightly coupled with a revision of the budget and schedule of the project. People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes or additions to a development plan rather than face an awkward conversation with a client or fellow team member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes rationally. The firm integration of schedule, budget, and scope is the only way to keep a Web project from becoming unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and honesty up front can save you much grief later. Make the plan carefully, and then stick to it.

 

TechShop was funded by:

The Corporation for National and Community Service

The University of Wisconsin Division of Information Technology

University of Wisconsin University Health Services

University of Wisconsin Morgridge Center for Public Service

The taxpayers who support UW faculty and staff salaries and some student tuition

 

Our Partners

University Health Services

DANEnet

UWUW Division of Information Technology

UW Morgridge Center for Pubic Service