0.11 Project planning  (Page 5/21)

An example of requirements

Automated teller machines (ATMs) can be used to illustrate a wide range of requirements ( [link] ). What are some of the physical features of these machines, and what kinds of functions do they perform for users? Why did banks put these systems in place? What high level business requirements did they have in mind?

The following represents one possible example of each type of requirement as they would be applied to a bank’s external ATM.

• ATM function requirement: The system shall provide users with the ability to select whether or not to produce a hardcopy transaction receipt before completing a transaction.
• ATM non-functional requirement: All displays shall be in white 14 pt Arial text on black background.
• ATM user requirement: The system shall complete a standard withdrawal from a personal account, from login to cash, in less than two minutes for a first time user.
• ATM business requirement: By providing superior service to our retail customers, Monumental Bank’s ATM network will allow us to increase associated service fee revenue by 10% annually on an ongoing basis, using a baseline of December 2008.
• ATM regulatory requirement: All ATMs shall connect to standard utility power sources within their civic jurisdiction, and be supplied with uninterruptible power source approved by said company.

The effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately specified requirements will guarantee poor project results.

Documenting requirements is much more than just the process of writing down the requirements as the user sees them; it should cover not only what decisions have been made but also why they have been made. Understanding the reasoning that used to arrive at a decision is critical in avoiding repetition. For example, if a particular feature has been excluded because it is simply not feasible, that fact needs to be recorded. If it is not, then the project risks wasted work and repetition when a stakeholder requests the feature be reinstated during development or testing. Once the requirements are documented, have the stakeholders sign off on their requirements as a confirmation of what they desire.

While the project manager is responsible for making certain the requirements are documented, it does not mean the project manager must perform this task. The project manager can enlist the help of stakeholders, business analysts, requirement analysts, business process owners, and other team members to conduct the interviews and document the requirements. The project manager then reviews the requirements and incorporates them into the project documentation and project plan.

Preparing the work breakdown structure

Now that we have the deliverables and requirements well defined, the process of breaking down the work of the project via a work breakdown structure begins. The work breakdown structure (WBS) defines the scope of the project and breaks the work down into components that can be scheduled and estimated and easily monitored and controlled. The idea behind the work breakdown schedule is simple. You subdivide a complicated task into smaller tasks, until you reach a level that cannot be further subdivided. Anyone familiar with the arrangements of folders and files in a computer memory, or who has researched their ancestral family free, should be familiar with this idea. You stop breaking down the work when you reach a low enough level to perform an estimate of the desired accuracy. At that point, it is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to estimate these factors at the higher levels. Each descending level of the WBS represents an increased level of detailed definition of the project work.