Gathering Requirements for Archival Projects

Requirements for archival projects are different from goals and objectives. Requirements specify what the deliverables of the completed project must be. Requirements define the final product, service, or result. These are statements of quantitative criteria, each of which provides a measure of one or more of the project’s critical success factors. You can visualize the requirements when you consider the current condition of an organization and then examine its future state once the project is completed.

Managing Expectations

As a project manager, you may handle gathering the requirements—although this responsibility often rests with the business analyst. It is helpful for you to understand the process techniques and outputs of collecting requirements so that you can form a complete picture of how the project is defined and what the stakeholders are anticipating from your project.

Requirements should be detailed and specific, and usually vary in type and intention. They can be:

• External: Requirements from outside the organization to which the project must adhere.
• Functional: Requirements relating to the performance of the project result.
• Operational: Requirements concerning the use of the project result.
• Design: Requirements pertaining to the realization of the project result.

Requirements must meet several conditions to be part of a successful project. Some of these conditions include:

• Complete: Requirements define constraints, assumptions, and risks. There is enough accurate information that the team may create the requirements based on the documentation provided.
• Consistent: Requirements should complement other project requirements.
• Correct: Requirements should describe the functionality accurately.
• Feasible: Requirements should be possible to implement based on the resources, schedule, cost, quality, and risks.
• Modifiable: Similar requirements should be grouped together so that changes can be made. When requirements are grouped, it is easy to see how a change in one requirement affects other requirements.
• Necessary: Requirements should have value and contribute to meeting goals and objectives as stated in the project charter.
• Testable: Each requirement must be verified upon delivery by testing to confirm their completeness.
• Unambiguous: The requirements documentation should be written in clear, concise language so readers arrive at the same understanding of what the requirements demand.

Keep two components in mind as you determine requirements: gathering the correct information and translating it into workable requirements with measurable deliverables.

Evolving Requirements

Requirements may start out broadly, but as the collection process evolves, they may be reduced into smaller requirements. At that level, requirements tend to be interrelated. For example, a high-priority requirement may be dependent on a lower priority one. Requirements also necessitate documentation at the start of the project so that, throughout the project, the fulfillment of the requirements can be gauged.

A Consultative Process

Stakeholders often combine wish-list items with conditions. Sometimes, people who are not stakeholders append their requirements onto your project. As the project manager and archivist, you must distinguish between essential, desirable, and unnecessary requirements. Essential requirements are what the project must deliver. Desirable requirements are included in the scope but could be dropped without damaging the project. Unnecessary requirements can be excluded without impact on the project. One approach you can use to prioritize the requirements is the MoSCoW Analysis, which breaks out each requirement into one of four imperatives:

• Must: These requirements must be implemented for the solution to be deemed a success.
• Should: These requirements should be implemented in the solution, but are unnecessary for the solution’s success.
• Could: These requirements would be nice to include in the solution if possible, but they are not the most important of the requirements.
• Will not: These requirements have been identified but are now not going to be implemented in the project solution due to cost, complexity, timing, or any number of other reasons. These requirements may be implemented into the solution later.

To prioritize your requirements, you will need to decide—with the assistance of your stakeholders—what requirements are must-haves, good-to-haves, or like-to-haves. Requirements prioritization is a consultative process with the stakeholders making the final decision.