"The five basic steps you must do on a project" - Part 2

Last tip I covered step 1 - Carefully define the outcome from the project. This time we will look at step 2 - Defining and documenting requirements

The subject of requirements is one of the most discussed items in all of project management. It is also one of of the major causes of project failure. Even on small projects you must elicit the requirements to the point that they can be written down and well understood by everybody involved. There are three generic classes of requirements:

· Functional - This is what the application or final outcome must be able to do. Examples include: The new building must have a ladies' and men's washroom. The web page must allow viewers to submit questions via e-mail.

· Technical  - These are specific requirements that support functional requirements. For example, the webpage must be available to receive on-line orders 24 hours a day or the building must have a 240V service for the air compressor for the shop.

·Time Oriented - These define when key events must occur such as when the new restaurant must be ready to receive food shipments or when the webpage must be ready to handle orders.

The important point is that these requirements must be documented and validated with everybody involved. Technical requirements must be validated with the technical experts.

If you do not write the requirements down you run risk of doing too much work, delivering the wrong items, or missing a critical component. All of which will cost  you time, money, and angst. On small projects requirements can be jotted down on a punch list or written on a white board (Just don't erase it)   for all to see. On larger projects you will want to use a more formal method. Next week we will talk about plans and planning.