Print this chapterPrint this chapter

Project Planning

Scope planning

You always want to know exactly what work has to be done to finish your project BEFORE you start it. You've got a collection of team members, and you need to know exactly what they're going to do to build your product or meet the project's objectives. The scope planning process if the very first thing you do to manage your scope. Project scope planning is concerned with defining all of the work of the project and only the work needed to successfully meet the project objectives. The whole idea here is that when you start the project, you need to have a clear picture of all the work that needs to happen on your project, and as the project progresses, you need to keep that scope up to date and written down in the project's scope management plan.

 

How do you define the scope?

You already got a head start on refining the project's objectives in quantifiable terms, but now you need to go a lot further and write down all of the deliverables that you and your team are going to produce over the course of the project. Deliverables include everything that you and your team produce for the project; anything that your project will deliver. The deliverables for your project include all of the products or services that you and your team are performing for the client, customer, or sponsor. But deliverables include more than that. They also include every single document, plan, schedule, budget, blueprint, and anything else that gets made along the way; including all of the project management documents you put together. Project deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project or project phase completed. Deliverables like objectives must be specific and verifiable.

All deliverables must be described in enough detail so that they can be differentiated from related deliverables. For example:

  • A twin engine plane versus a single engine plane.
  • A red marker versus a green marker.
  • A daily report versus a weekly report.
  • A departmental solution versus an enterprise solution.

One of the project manager's primary functions is to accurately document the deliverables and requirements of the project and then manage the project so that they are produced according to the agreed upon criteria. Deliverables describe the components of the goals and objectives in a quantifiable way. Requirements are the specifications of the deliverables.


Project requirements

After all the deliverables are identified, the project manager needs to discover and document all of the requirements of the project (Figure 1). Requirements describe the characteristics of the deliverable. They may also describe functionality that the deliverable must have or specific conditions the deliverable must meet in order to satisfy the objective of the project. A requirement is an objective that must be met. The project requirements defined in the scope plan describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Requirements answer the following questions regarding the AS IS and TO BE states of the business: who, what where, when, how much, how does a business process work.

Figure 1: When you don't get project requirements.

Figure 1: When you don't get project requirements.

Requirements may include things like dimensions, ease of use, color, specific ingredients, and so on. If we go back to the example of the company producing holiday eggnog; one of the major deliverables is the cartons that hold the eggnog. The requirements for that deliverable may include carton design, photographs that will appear on the carton, color choices, etc.

Requirements specify what the project deliverable should look like and what it should do. They can be divided into six basic categories, functional, non-functional, technical, user, business, and regulatory requirements.

Functional requirements

Functional requirements describe the characteristics of the deliverable, what emerges from the project in ordinary non-technical language. They should be understandable to the customers, and the customers should play a direct role in their development. Functional requirements are what you want the deliverable to do.

Example:

If you were buying vehicles for a business your functional requirement might be; the vehicle should be able to take a load from a warehouse to a shop.

Example:

For a computer system you may define what the system is to do; the system should store all details of a customer's order.

The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered.

Non-functional requirements

Non-functional requirements specify criteria that can be used to judge the product or service that your project delivers. They are restrictions or constraints to be placed on the deliverable and how to build it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Using the vehicle example ([link]); without any constraints, the functional requirement of a vehicle to take a load from a warehouse to a shop, the solutions being offered might result in anything from a large truck to a sports car! Non-functional requirements can be split into two types: performance and development.

To restrict the types of solutions you might include these performance constraints:

  • It must take a load of at least one ton.
  • The load area must be covered.
  • The load area must have a height of at least 10 feet.

Similarly, for the computer system example (Example 4), you might specify values for the generic types of performance constraints:

  • The response time for information to appear to a user.
  • The number of hours a system should be available.
  • The number of records a system should be able to hold.
  • The capacity for growth of the system.
  • The length of time a record should be held for auditing purposes.

For the customer records example these might be:

  • The system should be available from 9 AM to 5 PM Monday to Friday.
  • The system should be able to hold 100,000 customer records initially.
  • The system should be able to add 10,000 records a year for 10 years.
  • A record should be fully available on the system for at least 7 years.

The important point with these examples is that they restrict the number of solution options that are offered to you by the developer. In addition to the performance constraints you may include some development constraints.

There are three general types of development constraints:

  • Time: When a deliverable should be delivered
  • Resource: How much money is available to develop the deliverable
  • Quality: Any standards that are used to develop the deliverable, and develop methods, etc.

Technical requirements

Technical requirements emerge from the functional requirements, they answer the question, and how will the problem be solved this time; will it be solved technologically and/or procedurally. They answer how the system needs to be designed and implemented to provide required functionality and fulfill required operational characteristics. For example, in a software project, the functional requirements may stipulate that a data base system will be developed to allow access to financial data through a remote terminal; the corresponding technical requirements would spell out the architecture of the data structure, the language in which the database management system will be written, the hardware on which the system will run, telecommunication protocols that should be used and so forth.

User requirements

User requirements are what the users need to do with the system or product. They focus on the experience users need to have with the system, they can also reflect how the product will be designed, and define how test cases must be formulated.

Business requirements

Business requirements are the needs of the sponsoring organization, always from a Management perspective. Business requirements are statements of the business rationale for the project. They are usually expressed in broad outcomes the business requires, rather than specific functions the system may perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives.

Regulatory requirements

Regulatory requirements can be internal or external and are usually non- negotiable. They are the restrictions, licenses and laws applicable to a product or business, imposed by the government.


An example of requirements

Automated teller machines (ATMs) can be used to illustrate a wide range of requirements (Figure 2). 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?

Figure 2: A typical exterior automated teller machines (ATMs).

Figure 2: A typical exterior automated teller machines (ATMs).

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. e 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.