Requirements Document provides a Roadmap for Future-proofing your Web Site

Outlines for building the Requirements Document (aka: Project Insurance generally begin with the following:

  • Initial Interview
    • Organizational Goals
    • Priorities
    • Target Audience
    • Budget and Time Constraints
    • Change Order Process
  • Build Requirements Document
  • Revision Review
  • Update the Requirements Document
  • Review of Revised Revision
  • Any combination of Interview/ Review/ Revise above

Setting requirements the political negotiations way for a Web project is always a dicey proposition.

The best that you can do is to keep from loosing during this phase of the project if you enact a political negotiations strategy. Do the best that you can, but don't hold delusions of success for this phase of the Web project. And, beware, the change order process!

Standards Compliance

The best way to turn the tables on this downward, time-eating, money-sapping spiral is to insist, up front, on design to standards requirements.

Slipping in an agreement that the Web design project will meet current standards represents the best risk mitigation strategy for the project. This way, when “"off the wall” changes, and ill advised “requests” (more project changes) arrive from the sponsor; you can site the inability of that request to meet standards. (Citing standards may seem like “a coward’s way out,” but “a coward’s way out,” is preferable to saying, “No” to the sponsor or superintendent.

The best antidote for resonding to unbridled ignorance is something like the following:

“Sure, we can do ’xxx,’ it will only take ’yyy’ more (days, weeks, months) and only cost ’zzz’ more dolars. We'll just bring in ’aaa’ more staff and outsource ’bbb’.”

Change Orders

The Requirements Document that you prepare during site development is your best insurance against future change orders and unpaid rework. The Requirements Document future-proofs your site before you even start coding or prototyping.

The Requirements Document is always a work in progress, but a Webmaster must step gingerly and use the Requirements Document in a politically expedient way.

The major threat in Future-proofing a site in its gestation period is the threat of rework, i.e., making so many changes that you would have been better off starting from scratch.

While sponsors, clients and bosses do not like to do the "heavy" thinking (i.e., precise, detailed, complex) needed to produce a Requirements Document, they also do not like to pay for cost of clearing log jams, rework, or retooling a site.

Building the Requirements Document is the "right" thing to do, but doing so takes a lot of time and work (i.e., money), and clients and bosses often resist doing the "right" thing because doing things right increases costs.

What you must do is cut corners and compromise, i.e., what are the priorities and "must do/ must have" components?, and what are the "would be nice to have but we don't 'wanna' pay for components?" that won't be in the designed and delivered Web site package.

Failure to agree to these issues up front, and failure to put these in writing, and failure to get the sign offs, and failure to implement an agreed upon change order system; will result in less than happy feelings (and negative opinions) about your work from all sides...and lots of uncompensated work on your part.

If you like to throw time and work (money) down a rat hole, then feel free to be shy about pinning sponsors, clients or bosses down about the Requirement Document and Change Order System. Step gingerly at the front end of the Web project, and you will stepping in deep "xxx" on the back end of the project. (No pun intended.) :-)

A note about Risk Models

Risk models do not function well for Web projects. The risks are well know, but difficult to predict and mitigate against.

For example, one risk is that the sponsor or group with political influence over the sponsor (such as a school board) can change their minds. Another risk (particularly for in-house development) is that the change order process will not be followed because the sponsors believe that the development team is on the payroll and should do whatever it takes to meet the challenges of organizational initiatives.

Another risk is that the site's development will not be adequately funded, orders will be given to cut corners, and when groups with political influence complain about the results; the sponsors will blame the site team, and not take responsibility for their decisions.

Another risk is that sponsors may define the site's requirements for themselves instead of in terms of service to visitors.

School district sites often fall into this trap. For example, these sites:

  • Develop one-size fits all navigation based upon the district's organizational chart, rather than visitor's "ease of use"
  • Are built like an online brochure. This means that visitors have little need to return to the site
  • Even though students' learning is the mission critical activity of a school district, the site offers little content, except maybe to provide links to students to leave the site, to access instructional content
  • Are viewed as a public relations tool, rather than a tool that can bring the learning community into vibrant debate concerning issues such as accountability, the subversion of instruction in pursuit of teaching to the high-stakes test, or the impact of budget cuts upon needed programs

The strategies that a Web developer can use to mitigate risks such as these are to command as high a salary as possible, keep their resume up to date, and amass a portfolio of creative work to show to a more enlightened employer; but industry standard methods of project risk management are seldom effective in cases such as these.