Chapter 37: Estimating Activity Duration

In the previous chapter, we took a look at how to estimate resource requirement for an activity. Once you identify resources, the next step is to figure out how much time each of these activities would take. Without this information, our job as project manager will be very difficult. This is exactly what we are going to learn in this chapter.

So, lets get started!!!

What is Activity Duration?

Activity duration is the time between the start and finish of a schedule activity. For example, if we consider walking to your nearest McDonalds for a coffee an activity, it depends on how fast we walk. Lets say it is approximately 500 meters from your house, if you walk at a comfortable pace, you will take around 10 mins to reach the place.

So, the duration of the activity of walking to your nearest McDonalds is 10 mins. Once you know this number, you can prioritize or plan accordingly to meet your needs.

Why is Activity Duration Estimation Important?

Any individual who has worked in the software industry for at least 2 years will invariably agree with the fact that, we all slog. Most of our estimates miss the target by quite a bit and the whole team slogs like crazy during the last 2-3 months of the project and finish the delivery. The cause could be scope increase, attrition, or because of any numerous other possibilities. But, almost always, the reason is bad estimates. The team that estimated this work, underestimated the complexity and allotted much less time that what would be required to finish this. So, the eventual result is, the team members slog their backsides off to finish the project.

If I were project manager, I will do everything in my power to ensure that my guys don't have to slog it out in the end…

Estimating Activity Duration

Activity duration is estimated in work periods by using the Estimate Activity Durations process. A work period is a measurement of time when the work is in progress; it is measured in hours, days, or months, depending upon the size of the activity. This estimate can be converted to calendar units of time by factoring in the resource’s passive time, such as vacations.
For Ex: lets say you have estimated that, creating a new screen for your application will take 5 days (if someone works 8 hours in a day). So, if your programmer starts work on Thursday, you cannot expect him to finish by Monday EOD because, we have a weekend in between. So, the correct duration would be Thursday to Wednesday of the next week.

Look at the picture below to see how the Estimating Activity Duration activity happens.

Input to Activity Duration Estimating

To estimate the activity duration, you will need information about the activity, the resource requirements for the activity, and the resources available for the activity. This underlines the major input items to the activity duration estimating process. The Major input elements to this process are:

Activity list and activity attributes - Because you want to estimate the duration of the activities, the activity list along with the activity attributes, originally developed in the Define Activities process, are the obvious & first input item to the activity duration estimating process.
Activity resource requirements - The work periods required to complete an activity depend on the resources assigned to the activity. For example, suppose it will take four work days to complete an activity that involves having two programmers write two programs. If only one programmer is available, it will take roughly eight work days to finish this activity. However, while assigning additional resources to an activity, always consider the following:
• Sometimes assigning additional resources might reduce the overall efficiency and productivity. For example, think of two engineers with different skill levels assigned to work on the interrelated components of an activity.
• Most of the activities have a threshold beyond which assigning additional resources does not help.

I remembered this quote I read somewhere:

A Project Manager is one who thinks that 10 women can deliver a child in 1 month.
Well, the above statement by far summarizes what I want to tell about assigning extra resources to a project. Just adding more people never helps. I personally wanted to tell one of my Managers this more than once, but I dint tell it because I did not want to be Fired :)…

Anyways, coming back to topic, assigning resources to activities is critical and adding 4 people to a 40 day task will not make the task complete in 10 days. Maybe 12-15 days would be required depending on the work involved.

Resource calendar - The resource calendar, finalized (or modified) during activity resource estimating, contains the type, quantity, availability, and capability of each resource, including the skills of a human resource, which must be considered during activity duration estimating. For example, an experienced programmer can finish the same program in less time than a beginner can. Capability and quantity of available resources, both human and material, can affect the activity duration estimate.
Project scope statement - Some assumptions and constraints in the project scope statement can affect activity duration estimates and therefore must be considered. For example, there might be an assumption that part of the work related to an activity has already been performed in a previous project and can be used in this project. If the assumption is true, the activity duration will be less than otherwise.
Enterprise environmental factors - Examples of enterprise environmental factors are some databases that contain reference data relevant to the activity duration; for instance, how long it takes for a specific government agency to respond to a request. Published commercial information and metrics to measure productivity can also be helpful in duration estimates. More details on Enterprise Environmental Factors can be found by clicking here
Organizational process assets - Organizational process assets that will be useful in estimating activity duration include information from previous projects and a calendar of working days and non-working days. More details on Organizational Process Assets can be found by clicking here

Tools and Techniques for Activity Duration Estimating

The project schedule depends upon the activity duration estimates. The duration estimates of activities on the critical path will determine the finish date of a project for a given start date. However, there might be many uncertainties involved in the estimate. For example, two programmers, due to the differences in their experience, will take different amounts of time to write the same program. The good news is that there are a number of tools and techniques that you can use in activity duration estimating.

Analogous estimating - Analogous estimating techniques estimate the duration of an activity based on the duration of a similar activity in a previous project. The accuracy of the estimate depends upon how similar the activities are and whether the team member who will perform the activity has the same level of expertise and experience as the team member from the previous project. This technique is useful when there is not enough detail information about the project.
Parametric estimating - This is a quantitative technique used to calculate the activity duration when the productivity rate of the resource performing the activity is available. You use a formula such as the following one to calculate the duration:

Activity duration = Units of work in the activity / Productivity rate of the resources

For example, if you know that a team assigned to the activity of laying a road for 40 miles can lay two miles of road in one day, the duration calculation can be performed as follows:

Activity duration = 40 miles / (2 miles/day) = 20 days

Three-point estimating - This method addresses the issue of uncertainty in estimating the activity duration. The uncertainty in the duration estimate can be calculated by making a three-point estimate in which each point corresponds to one of the following estimate types:
• Most likely scenario - The activity duration is calculated in most practical terms by factoring in resources likely to be assigned, realistic expectations of the resources, dependencies, and interruptions.
• Optimistic scenario - This is the best-case version of the situation described in the most likely scenario.
• Pessimistic scenario - This is the worst-case version of the situation described in the most likely scenario.

The spread of these three estimates determines the uncertainty. The resultant duration is calculated by taking the average of the three estimates. For example, if the duration for an activity is estimated to be 20 days for the most likely scenario, 15 days for the optimistic scenario, and 25 days for the pessimistic scenario, then the average duration is 20 days, and the uncertainty is ± 5 days, which can be expressed as:

Duration = 20 ± 5 days

It’s equivalent to saying that the activity duration is 20 days, give or take five days.
However, the most likely scenario may be given more weight than the other two scenarios. Therefore, the expected duration can be calculated by using the following formula:

ED = ((N*MD) + OD + PD)/(N+2)

Here

ED = Expected Duration
MD = Most likely Duration
OD = Optimistic Duration
PD = Pessimistic Duration
N = Weightage for the Most likely Duration

Reserve analysis - Reserve analysis is used to incorporate a time cushion into your schedule; this cushion is called a contingency reserve, a time reserve, or a time buffer. The whole idea is to accommodate the possibility of schedule risks. One method of calculating the contingency reserve is to take a percentage of the original activity duration estimate as the contingency reserve. It can also be estimated by using quantitative analysis methods. Later, when more information about the project becomes available, the contingency reserve can be reduced or eliminated. Usually, while estimating for large projects, managers would like to keep a buffer of 5% or so of the total estimate for the project to account for project schedule risks, like delays in procuring hardware or unexpected human resource risks (Ex: attrition) etc

Expert judgment - Expert judgment can be used to estimate the whole duration of an activity when not enough information is available. It can also be used to estimate some parameters to be used in other methods. For example, what percentage of the original activity duration estimate should be used as a contingency reserve, and in comparing an activity to a similar activity in a previous project during analogous estimation.

Note: Estimation is a complicated activity and usually there is no rule of the thumb that says that a particular estimation technique is 100% accurate. A combination of one or more of the above mentioned techniques will usually be used to arrive at an estimate that could be as close as possible to a perfect estimate for this activity and let me say that, there is no such thing as a “Perfect Estimate”.

Output of Activity Duration Estimating

Can you guess what the output of the activity duration estimating process is. Yes, you are right: It is the activity duration estimates! Regardless of which technique you use, these estimates are quantitative assessments of the required time durations to finish activities, such as 10 days or 6 weeks and so on. As shown earlier, you can also assign an uncertainty to the estimate, such as 20±2 days to say that the activity will take at least 18 days and at most 22 days.

The duration of an activity is an attribute of the activity. Therefore, you update the activity attributes, originally developed in the Define Activities process, to include the activity durations.

To summarize, there are two output items of the activity duration estimating process:
• Activity duration estimates
• Updates to activity attributes and assumptions about skill level and availability of resources

Previous: Estimating Activity Resource Requirements

Next: Developing the Project Schedule

Chapter 36: Estimating Activity Resource Requirements

In the previous chapter, we took a look at how to sequence the activities based on the requirements and dependencies. The next step would be estimating resource requirements. After all, you need people to work on this activities right? This is what we are going to learn in this chapter.

So, lets get started!!!

Estimating Activity Resource Requirements

We all know that any activity needs people/resources in order to be executed and completed. The resource requirements for an activity are estimated by using the Estimate Activity Resources process. The main purpose of this process is to:

• Estimate the types of resources needed for a given activity
• Estimate the quantities of each type of resource needed for the activity
Simply put, you identify what kind of resources can do a particular activity and how many. For

ex: If you want a Java class, you would have to identify a Java Programmer as your resource for this activity.

Just like all other processes, this process too has inputs, uses some tools & techniques and generates an output. Look at the image below:

Let us take a detailed look at these entities.

Input to Activity Resource Estimating

The activity list and attributes are the obvious and major input to the activity resource estimating process.
• Activity list and activity attributes - The activity list originally developed during the activity definition process identifies the schedule activities that need the resources. The activity attributes provide the details for the activities, which will be helpful in estimating the resources.
• Resource calendars - Resource estimating will require information on the available quantity of resources of different types, such as human, equipment, and material. This information is usually available in the resource calendars, which may also have detailed information about human resources, such as skill level, experience, and the geographical location from where the resource will come. Typically, the resource calendar contains the following useful information about the resources:
       Days and times of day when a resource is available
       The passive time for the resource (Ex: Vacation plans for people)
       The quantity of each type of available resource
       The capability of each resource
• Enterprise environmental factors - Information about the infrastructure of the performing organization, such as existing facilities, will be used in identifying the resources and their availability. More info on the Enterprise Environmental Factors can be found by clicking here
• Organizational process assets - The organizational process assets useful for activity resource estimating include organizational policies for staffing and purchase of supplies, historical information on what types of resources were used for similar activities in a previous project, and so on. More info on Organizational Process Assets can be found by clicking here

Once you understand what activities need to be performed, the next step is to use some tools and techniques to determine the resources required to perform them.

Tools and Techniques for Activity Resource Estimating

The tools & techniques that can be used for activity resource estimation are:
• Alternative analysis - Alternative analysis is all about exploring alternative solutions to a problem. In the case of estimating resource requirements, you will need to consider alternatives available for resources needed for some schedule activities. For example, you might need to decide whether you want to buy or develop a tool needed to perform an activity, what types of machines (for example, Windows or Linux) to use, which computers to use to do the development, or what level of skills is needed etc.
• Bottom-up estimating - You might discover that it is rather complex to estimate resources for a given schedule activity. If the problem is inherent to the activity, it might be helpful in certain cases to decompose the activity into smaller components for the purpose of resource estimating and, then estimate the resource for each component, and then aggregate the resources to get an estimate for the whole activity. In aggregation, you must consider the possible relationships (overlaps and other dependencies) among different components of the activity so you don’t double-count the resources or consider a seamless summation of the smaller component estimates.
• Expert judgment - Expert judgment can be used to assess the input and determine the output of the resource estimating process.
• Published estimating data - Information published by various vendors, such as costs for resources, can also be useful in estimating the resources.
• Project management software - Depending upon the sophistication of the resource requirements and the capabilities of the available features, project management software might be useful in estimating and managing the resources. It can also be used to create resource breakdown structures.

You can use a combination of these tools and techniques to generate the output of the resource estimating process. But, at the end of the day, it is the project manager and his capabilities that determine how accurately the resource estimation happens.

Output of Activity Resource Estimating

The resource requirements are the major output of the resource estimating process. The overall elements that are the output of this process are:

Activity resource requirements - The main purpose of the activity resource estimating process is to determine the resource requirements for each activity, and therefore this is the major output item from this process. You identify the types of resources required to perform each activity and estimate the required quantity of each identified resource. If a work package in the WBS has multiple activities, the resource estimates for those activities can be aggregated to estimate the resource requirements for the work package. The requirement documents may also include information such as the basis for each estimate, the assumptions made for the estimate, and the availability of the resources.
Resource breakdown structure - The resource breakdown structure (RBS) is a hierarchical structure of resource categories and types required to complete the schedule activities of a project. The RBS can be used to identify and analyze the project human resource assignments.
Updates to project documents - The identified types of required resources for an activity and the estimated quantity for each identified resource become activity attributes and must be added to the attribute list for the activity. Activity resource estimating might generate modifications to the activity list. It may also cause you to change the resource calendar.
Once you identify the resource requirements, the next step would be to estimate the time required to complete each of these activities. This is what we will be learning in the next chapter.

Previous: Sequencing Activities

Next: Estimating Activity Effort

Chapter 35: Sequencing Activities

The next step after defining activities is to sequence them in the proper order. You cannot test a system without building it first. So if your schedule testing before the development phase, your project is almost doomed. In this chapter, we are going to learn about the activity sequencing step.

So, lets get started!!!

Sequencing Activities

The activity sequencing process is used to arrange the schedule activities in the appropriate order, which takes into account the dependencies among the activities. For example, if Activity B depends upon the product of Activity A, then Activity A must be performed before Activity B.

Let us take a look at the diagram below that explains the steps in sequencing the activities involved in our project.

As you can see, the activities list, scope statement and other organizational process assets are all the input to this phase. You then apply some tools & techniques to come up the sequence.

Tools and Techniques for Sequencing Activities

Dependency determination is the prerequisite to determine sequencing. Therefore, most of the tools and techniques used for sequencing are focused on determining and displaying the dependencies.

Determining dependencies

To properly sequence the schedule activities, you need to determine the dependencies among them. Look at the image below:

Activity A is the Predecessor and Activity B is the successor. In other words, activity B cannot happen unless Activity A is over and hence the terms. This essentially means that A must start before B.

By definition, the successor activity must start after the predecessor activity has already started. But exactly when can the successor activity start after the predecessor activity has already been started?

Well, both the predecessor and the successor have a start and a finish, and there are at maximum four possible combinations between the start and finish points of the predecessor and the successor activities. Accordingly, there are four kinds of dependencies, also called precedence relationships or logical relationships, listed here:

• Finish to start - The initiation of the successor activity depends upon the completion of the predecessor activity i.e., the successor activity cannot be started until the predecessor activity has already been completed.
• Finish to finish - The completion of the successor activity depends upon the completion of the predecessor activity i.e., the successor activity cannot be completed until the predecessor activity has already been completed.
• Start to start - The initiation of the successor activity depends upon the initiation of the predecessor activity i.e., the successor activity cannot be initiated until the predecessor activity has already been initiated.
• Start to finish - The completion of the successor activity depends upon the initiation of the predecessor activity i.e., the successor activity cannot be completed until the predecessor activity has already been initiated.

These types of dependencies describe the logical relationships between activities.

Dependencies can be grouped into three categories:

• Mandatory dependencies - These are the dependencies inherent to the schedule activities. For example, a software program must be developed before it can be tested. Mandatory dependencies are also referred to as hard logic.
• Discretionary dependencies - These are the dependencies at the discretion of the project team. For example, the development for two parts of the system can happen in parallel and then integrated at a later point in time. It is not mandatory for the second module to wait until module one is over. Some of the guidelines for establishing discretionary dependencies can come from the knowledge of best practices within the given application area and from the previous experience of performing a similar project. Discretionary dependencies are also referred to as soft logic, preferential logic, or preferred logic.
• External dependencies - An external dependency involves a relationship between a project activity and a non-project activity i.e., an activity outside the project. For example, lets say your application is migrating to a newer version of application server and it is supposed to be delivered & set up next week. You cant practically deploy and test your application until the server is delivered and set up. This is an example of an external dependency.

The dependency between two schedule activities is an example of the logical relationships defined earlier in this chapter. Logical relationships can be displayed in schematic diagrams, called project schedule network diagrams, or just network diagrams. A common method to develop network diagrams is called the precedence diagramming method (PDM).

Precedence diagramming method (PDM)

The precedence diagramming method is the method to construct a project schedule network diagram in which a box is used to represent an activity and an arrow is used to represent dependency between two activities. The boxes representing activities are called nodes.

Let’s look at a sample diagram to understand them better.

Above is a sample network diagram constructed by using PDM, in which Activity A is a predecessor of Activity B, Activity C is a predecessor of Activities D and E, and so on.
In general, PDM supports all four kinds of precedence relationships discussed earlier, but the most commonly used dependency relationship in PDM is finish to start. The start-to-finish relationship is rarely used.


Applying leads and lags

In the real world, some activities may need or lend themselves to what are called leads and lags to accurately or effectively define the logical relationships. For example, the finish-to-start dependency means that the successor activity starts where the predecessor activity finishes. Applying a lead means you allow the successor activity to start before the predecessor activity finishes, and applying a lag means you start the successor activity a few days after the predecessor activity finishes. Sometimes you might need to make such adjustments in the schedule for effectiveness and efficiency.

Schedule network templates

You can use standardized network diagram templates to expedite the process of activity sequencing. You can also use network diagrams from previous projects and modify them for the project at hand.

Output of Sequencing Activities

The goal of the activity sequencing process is to determine the dependencies among the schedule activities and sequence the activities accordingly. The sequencing is presented in network diagrams.

The output items from the activity sequencing process are:

• Project schedule network diagrams - These diagrams, discussed in the previous section, can be created manually or by using an appropriate project management software application. Depending upon a project’s size, you might have multiple network diagrams for it.
• Updates to project documents - During the process of sequencing activities, you may identify new necessary activities, split an activity into two, modify activity attributes, add new attributes, or identify a risk related to an activity. Accordingly, you may need to modify some project documents, such as the activity list, activity attributes, and the risk register.

Previous: Defining Activities

Next: Estimating Activity Resource Requirements

Chapter 34: Defining Activities

In the previous chapter, we saw that the activity list is an important part of defining the project schedule. But first, we have to prepare one so that we can use it to prepare the schedule, isnt it? In this chapter, we are going to learn just that.

So, lets get started!!!

Defining Activities:

Activities that need to be performed to produce the project deliverables are identified using the activity definition process. To understand it better, look at the picture below:

Let us look at the 3 parts of it in detail.

Input to Defining Activities

Identifying project activities starts with the work packages in the WBS, which in turn are derived from the project scope statement. The input items are:

Elements of the scope baseline, such as deliverables, assumptions, and constraints, will be useful in defining activities.

All the following three components of the project scope statement are needed to define activities:

• WBS and WBS dictionary - The work packages in the WBS are decomposed into project activities. To define activities in detail so that you can assign appropriate resources to them, you need the details about work packages, which are provided in the WBS dictionary.
• Project scope statement - The WBS is built from the project scope statement. While dealing with the WBS, you might need to go back to the project scope statement. The following elements of the project scope statement are especially important to consider while identifying activities:
     o Assumptions related to the activities or schedule planning, such as work hours per week
     o Constraints that will limit the schedule options, such as predetermined deadlines on project milestones
     o Project deliverables, to ensure that everything is covered in WBS work packages
• Enterprise environmental factors - The enterprise environmental factors relevant to identifying schedule activities include project management information systems and project scheduling software tools.
• Organizational process assets - Following are examples of organizational process assets that can be useful in the process of identifying activities:
     o Organizational policies related to activity planning
     o Organizational procedures and guidelines used in defining activities
     o Knowledge base of lessons learned from previous projects regarding activity lists
So, the major input to the activity definition process is the WBS, whose work packages are decomposed into activities using some tools and techniques.

Tools and Techniques for Defining Activities

The major task in the Define Activities process is to decompose the work packages in the WBS into activities.

Decomposition

Do you remember that we used the decomposition technique to create the WBS by subdividing the project deliverables into smaller manageable tasks called work packages. Decomposition is also used in the activity definition process for subdividing the work packages into smaller, more manageable components called schedule activities.

Component planning

If there are areas of the project scope for which sufficient information is not available yet, there will definitely be corresponding components in the WBS that are not decomposed to the level of work packages. You can only develop a high-level schedule for these planning components. You accommodate this kind of high-level scheduling by using a technique called rolling wave planning to plan the project work at various levels of detail depending upon the availability of information. Work to be performed in the near future is planned to the low level of the WBS, whereas work to be performed far into the future can be planned at the relatively high level of the WBS. So, a WBS component at the bottom level of a branch of WBS hierarchy for which some planning can be performed is called a planning component.

Templates

As a timesaver and a guide, you can use a standard activity list or an activity list from a previous project similar to the project at hand as a template. The template can also contain information about the activities in it, such as required hours of effort.

Expert judgment

Activities make the core of a project. So, it’s very important to identify and define them correctly to make the project schedule efficient and effective. Therefore, expert judgment is a very important tool that can be used in this process.

Output of Defining Activities

The key output item of the activity definition process is a comprehensive list of all the schedule activities that need to be performed to produce the project deliverables. The list of output items of this stage are:

Activity list

This is a list of all the activities that are necessary and sufficient to produce the project deliverables. In other words, these activities are derived from the WBS and hence are within the scope of the project. Also, the scope of each schedule activity should be described to sufficient detail in concrete terms, so that the team member responsible for it will understand what needs to be done.

Activity attributes

These attributes are in addition to the scope description of the activity in the activity list.
The list of attributes of an activity are:

• Activity identifier and code
• Activity description
• Assumptions and constraints related to this activity, such as target date
• Predecessor and successor activities
• Resource requirements
• Team member responsible for performing the work and information about the work; for example, where it will be performed

Some attributes evolve over time. The attributes are used to arrange the activities in the correct order (sequencing) and to schedule them.

Milestone list

A schedule milestone is a significant event in the project schedule, such as the completion of a major deliverable. A milestone can be mandatory, such as one required by a contract, or optional, such as one determined by the team to run the project more smoothly. The milestone list includes all the milestones and specifies whether a milestone is mandatory or optional. Milestones are used in building the schedule.

Trivia:
The Define Activities process generates the final output as activities and not deliverables. Therefore, ideally speaking, the WBS and the WBS dictionary should be generated before defining activities. However, practically speaking, the activity list, the WBS, and the WBS dictionary can be developed concurrently.

To wrap up this chapter, the output items of the activity definition process are a schedule activity list, a list of attributes for each activity, and a list of milestones. Before you can schedule them, the identified activities need to be arranged in the correct order, which is called sequencing – this is what we will be learning in the next chapter.

Previous: Introduction to Project Schedule

Next: Sequencing Activities

Chapter 33: Introduction to Project Schedule

In the previous set of chapters, we learnt how to create a Project Scope Statement and how to create the Work Breakdown Structure. Now that we know what needs to be done, the next step is to create a schedule of when, what activity will be done. This is what we are going to learn in this and the subsequent few chapters.

So, lets get started!!!

What is a Project Schedule?

A project consists of two main components: the project work that needs to be performed and the schedule to perform that work.

The overall project work is broken down into smaller, manageable components in the WBS. These components are called work packages. A project schedule contains not only the activities to be performed, but also the order or sequence in which the activities will be performed and a start and a finish date. The sequencing of activities is constrained by the dependencies among the various activities.

A realistic project schedule can be created from the bottom up by identifying the activities, estimating the resources for the activities, and determining the time that each activity will take with the given resources available. The resources required to complete the activities include human resources. Before, during, and after schedule development, you will need to communicate effectively.

The Project Schedule

Planning the project schedule is all about time management. To complete a project, you need to perform some activities to produce the project deliverables. To make that happen, you need to assign resources to the activities and schedule them. But before all this can happen, you need to identify the activities. Although all this sounds like common sense, it makes sense to define the following terms so we are all on the same page.

• Activity - A component of project work.
• Activity duration - The time measured in calendar units between the start and finish of a schedule activity. (Usually Man Hours or Man Days)
• Schedule activity - A scheduled component of work performed during the lifecycle of a project.
• Logical relationship - A dependency between two project schedule activities or between a schedule activity and a schedule milestone.
• Schedule milestone - A milestone is a significant point in the life of a project, and a schedule milestone is a milestone on the project schedule. A milestone refers to the completion of an activity, marking possibly the completion of a set of activities, and therefore has zero duration. The completion of a major deliverable is an example of a milestone.

Project time management includes the processes required to complete the project in a timely manner.

Let us take a look at a diagram that is going to explain how project time management is supposed to happen.

The purposes of these processes are:

• Define Activities - Identifies the specific schedule activities that must be performed to produce the project deliverables.
• Sequence Activities - Identifies the dependencies among the schedule activities and orders the activities accordingly.
• Estimate Activity Resources - Estimates the types and amounts of resources that will be required to perform each schedule activity. Examples of resources are materials, equipment, supplies, and people.
• Estimate Activity Duration - Estimates the time in work periods individually for each schedule activity required for the activity’s completion. A work period is a measurement of time when the work is in progress; it is measured in hours, days, or months, depending upon the size of the activity. This estimate is performed for given resources.
• Develop Schedule - Develops the project schedule by analyzing schedule activity sequences, schedule activity durations, resource requirements, and schedule constraints.
• Control Schedule - Monitors the status of the project progress and controls the changes to the schedule baseline.

Trivia:
The underlying philosophy of project management for schedule development is to first develop the schedule based on the work required to complete the project tasks and then see how you can make it conform to other constraints, calendar requirements, and strategic goals of the organization. You, the project manager, have to build the schedule through cold, hard mathematical analysis, and you should not just accept whatever schedule goals come down the pipeline from upstairs, such as from the customer or the project sponsor.

Previous: Important Terms - Project Scope Planning

Next: Defining Activities

Important Terms & Definitions - Project Scope Planning

Let us wrap up the Project Scope Planning topic by reviewing the important terms and definitions we have learnt as part of this topic.

• Alternatives identification - A technique used to apply nonstandard approaches, such as brainstorming and lateral thinking, to perform project work.
• Baseline - A reference plan for components, such as schedule, scope, and cost, against which performance deviations are measured. The reference plan can be the original or the modified plan.
• Brainstorming - A creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later.
• Code of accounts - A numbering system used to uniquely identify each component of a WBS.
• Configuration management - Refers to controlling the characteristics of a product, a service, or a result of a project. It includes documenting the features of a product or a service, controlling and documenting changes to the features, and providing support for auditing the products for conformance to requirements.
• Control account - A node in the WBS that acts as a management control point where scope, schedule, and actual cost are integrated and compared to the earned value to measure the project performance.
• Decomposition - A planning technique to subdivide the project scope, including deliverables, into smaller, manageable tasks called work packages.
• Deliverable - A unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project or a process or phase of the project.
• Lateral thinking - Thinking outside the box, beyond the realm of your experience, to search for new solutions and methods, rather than only better uses of the current solutions and methods.
• Planning package - A WBS component that is below the control account that has a well-defined work content but does not yet have a detailed schedule.
• Product scope - Features and functions that characterize a product, service, or result to be delivered by the project.
• Project management plan - An approved document that describes how the project will be executed, monitored and controlled, and closed.
• Project scope - The work that must be performed (and only that work) to deliver products, services, or results with specified features that were promised by the project. The project scope draws the boundaries around the project—what is included and what is not.
• Project scope statement - A document that defines the scope of a project by stating what needs to be accomplished by the project.
• Requirement - A condition, characteristic, or capability that a specific outcome of the project must have.
• Rolling wave planning - A case of progressive elaboration in which the deliverables about which full information is available are decomposed to the lowest level, whereas the deliverables for which full information is not available are left at higher levels until the information becomes available.
• Scope baseline - The reference scope against which all the scope deviations are measured. It consists of the scope statement, the WBS document, and the WBS dictionary.
• Scope definition - The process used to develop the detailed project scope statement.
• Scope planning - The process of developing the project scope management plan.
• Subprojects - Parts of the main projects that are independent enough that each can be performed by separate project teams.
• Work breakdown structure (WBS) - A deliverable-oriented hierarchical structure that displays the decomposition of deliverables into work, which must be performed to accomplish the project objectives and create the project deliverables.
• Work package - A deliverable or a task at the lowest level of each branch of the WBS.

Previous: Summary - Project Scope Planning

Next: Introduction to Project Schedule

Summary - Project Scope Planning

In the previous chapters, we have successfully completed the Project Scope Planning section of Project Planning. Let us quickly summarize the key points we learnt in this topic.

• After a project has been initiated, the project management plan is developed to specify how the project at hand will be executed, monitored & controlled, and closed.
• The project management plan can contain subsidiary plans, such as a quality management plan, a risk management plan, a project scope management plan, and a scope baseline.
• The scope baseline consists of the project scope statement, work breakdown structure (WBS), and WBS dictionary.
• Collecting requirements is part of the scope planning, which creates requirements documentation.
• The project charter and requirements documentation are used to define the scope, which creates the project scope statement.
• The project scope statement is a document that defines the scope of a project, including the product scope, by stating what needs to be accomplished by the project.
• It includes project deliverables, product description, product acceptance criteria, assumptions and constraints, and project exclusions.
• The project scope statement and requirements documentation are input items to creating the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages, which in turn are used to develop the project schedule.
• The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.
• The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated.
• The WBS is the heart of project management, as it is used in managing many aspects of the project, including developing the schedule.

Previous: Before & After WBS

Next: Important Terms - Project Scope Planning

Chapter 32: Before and After the WBS

In the previous chapter, we saw how to create the WBS. Since the WBS is an important artifact, it would be better if we take a look at it with some more details.

So, lets get started!!!

Creating the WBS:

Even though we looked at how to create the WBS in great detail, it would make it easier for you to understand the whole process if we have another picture to explain it. Below is a picture that explains how the WBS is created.

In the picture above, each of the boxes is a document/artifact and arrows indicate the direction in which data flows. The numbers indicate the order in which data flows. For ex: The contract and the SOW are inputs to create the Project Charter. Similarly the Project Charter is an input to create the Stakeholder Register and these two together are inputs to the Requirement Documentation step and so on.

The WBS is at the heart of project management. It affects directly or indirectly almost all the processes that are performed after its creation.

Processes Based on the WBS:

As part of managing the project, there are many processes that are directly based on the WBS as part of the Scope Baseline. They are:

1. Cost Estimation
2. Quality Planning
3. Risk Identification
4. Procurement Planning
5. Defining Activities for Project Schedule
6. Budget Determination

Let us look at a diagram to understand this better.

The three most important things you need to understand about Project Scope Planning are:
• You need to collect requirements by using the Collect Requirements process before you can define the project scope.
• The requirements documentation generated by the Collect Requirements process and the project charter generated during the project initiation are used to define the scope, which is documented in the project scope statement.
• The requirements documentation and the project scope statement are input items to create the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.


Previous: Creating the WBS

Next: Summary - Project Scope Planning

Chapter 31: Creating a Work Breakdown Structure (WBS)

In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Work Breakdown Structure or WBS. This is what we are going to look in this chapter.

So, lets get started!!!

What is WBS?

WBS stands for Work Breakdown Structure. It is something that helps breakdown the whole projects scope into smaller and more manageable pieces. This is also a very important process in project management. To be able to actually execute the project, the project scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project.

How to create the WBS?

Just like other documents related to project planning & management, the WBS is created using a set of inputs, by applying a set of tools & techniques to create the WBS. The picture below is a high level summary of how the WBS is created.

The project scope statement contains the list of deliverables and the product description. The requirements documentation describes the product and project requirements. Information in these two items provides the basis for creating the WBS. You should always consider organizational process assets while going through this and several other processes. In this case, the organizational policies and procedure related to creating the WBS, as well as relevant project files and lessons learned from previous projects, are some examples of organizational process assets that can be helpful.

Furthermore, even though each project is unique, there are similarities among sets of projects in an organization. These similarities can be used to prepare templates that will be used as a starting point for the WBS, to avoid the duplication of work. With or without templates, you will need to go through breaking down the deliverables, a very important step in creating the WBS.

Decomposition

Decomposition is a technique used for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition.

To understand Decomposition better, let us take a look at an example WBS of a Website Development Project

In any WBS – the lines are called “Branches” and the boxes are called “Nodes”. For practical understanding purposes, each of these nodes can be considered as one manageable piece of work.

As you can see, we have decomposed the whole project work into 3 parts:
1. User Interfaces
2. Server &
3. Database

Each of these parts is further divided into more nodes which carry out a specific function that is part of the higher level activity.

How do you decompose a Project Work?

You can decompose the project work by executing the following steps:

1. Identify the deliverables and the work involved by analyzing the project scope statement and the requirements documentation.
2. Understand the relationships among the deliverables.
3. Structure and organize the first level (Server, UI and Db in our example) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches:
     o Use the deliverables as the components in the first level.
     o Use the phases of the project as the components in the first level.
     o Use the subprojects as components in the first level. A subproject is a part of the project that is independent enough of the rest of the project that it can be performed by another project team. This approach is useful when you want to outsource parts of the project.
     o Use different approaches within each branch of the WBS, for example, a subproject and deliverables in the first level.
4. Decompose the upper level into more detailed components for the lower level.
5. Keep decomposing to lower levels until necessary and sufficient decomposition has been achieved.
6. Assign identification codes to the WBS components.

Trivia:
As the work is decomposed to lower levels of detail, work components become more concrete and manageable. However, you should avoid excessive decomposition, because it will lead to a large number of work packages, and it will not be possible to manage all of them effectively. In other words, excessive decomposition leads to inefficient use of management and other resources. Necessary and sufficient decomposition is the key.

During decomposition, the components are defined in terms of how the project work will actually be executed and controlled. You must verify the correctness of the decomposition at each level by verifying that the lower-level components are necessary and sufficient for the completion of the corresponding higher-level deliverables.

Trivia:
While using the technique of decomposition, remember a useful concept or trick: rolling wave planning. It’s a fancy term that refers to handling a deliverable or subproject that currently cannot be decomposed fully because you don’t know the details about it yet. For example, it is to be executed far into the future. You leave the decomposition of such a deliverable at a level allowed by the available information and wait for further decomposition until more information becomes available. Yes, you got it right. This is an example of progressive elaboration.
The WBS document is the key item of the Create WBS process, but there are some other output items as well.

Output of Creating WBS

The output of the Create WBS process consists of the following items:

Work breakdown structure

As explained earlier, the WBS is a deliverable-oriented hierarchical structure that decomposes the deliverables into the work that will be executed by the project team to create the planned deliverables and to accomplish the planned project objectives. The project manager creates this document with the help of the project team. Following are some important characteristics of the WBS:
• Control account - Remember that each node represents a deliverable or a component of it at certain level, and each deliverable will have scope, schedule, and cost attached to it. Some suitable nodes in the WBS are selected as management control points. At each of these control points, scope, schedule, and cost are integrated for the purposes of monitoring and controlling the performance. For example, the integrated scope, schedule, and actual cost at these points can be compared to the earned value to measure the project performance. Such management points are called control accounts. Each control account may have one or more work packages under it. Obviously, each work package must belong to only one account; otherwise, some factors, such as cost, will be double counted or counted multiple times. A WBS component that is below the control account, that has a well-defined work content but does not yet have a detailed schedule, is called a planning package.
• Code of account - Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources.
• Scope - The WBS embraces the full scope of the project. If a task is not included in the WBS, it will not be done as a part of the project.
• Step toward team building - Because the project manager creates the WBS with the help of the project team, it is also the beginning of the team-building process on the part of the project manager.
• Step toward scheduling - The WBS decomposes the project work into manageable pieces that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule.
• Reference for communication - Throughout the project, the WBS works as a reference for communication regarding what is included in the project and what is not.

WBS dictionary

This is a supporting document for the main WBS document to provide details about the components of the WBS. The details about a component might include elements such as a code of account identifier, description of work involved, quality requirements, acceptance criteria, a list of milestones schedule, cost estimates, required resources, contract information, and the organization or group responsible for this component.

Updates

During the create WBS process, the project team might realize that something out of the existing scope must be included in order to accomplish something in the scope. This will give rise to a change request, which might also come from other stakeholders during or after the first creation of the WBS. After the change request has been approved, not only the WBS will be changed—the scope statement must also be updated accordingly. The impact of the approved change request on the project scope management plan must be evaluated, and the plan must be updated accordingly.

Scope baseline

This is not a different item in and of itself. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all the change requests will be evaluated.

Trivia:
Do not confuse the WBS with other information breakdown structures, such as the organizational breakdown structure (OBS), which provides a hierarchy of the performing organization and can be used to identify organizational units for assigning the WBS work packages. Remember, the end goal of the WBS is to specify the project scope in terms of work packages; this is what distinguishes the WBS from other information breakdown structures.

A Last Word:

You might be wondering who creates the WBS. Well, as expected, it is your responsibility, and you, the project manager have to create it with the help of your team.


Previous: Defining Project Scope

Next: Before & After the WBS

Chapter 30: Defining the Project Scope

In the previous chapter, we saw how to capture requirements for a project. The next step in managing a project after we gather the requirements is to define the Project Scope. In this chapter, we are going to take a look at how exactly this project scope definition happens.

So, lets get started!!!

What is Project Scope?

We have gone through this multiple times over the course of the previous chapters but still for the sake of completeness lets define project scope here as well. A Projects Scope outlines what work will be done/accomplished as part of the project and also outlines what would not be done as part of the current project.

Why is Scope Definition Important?

Do I need to say why scope definition is important? Without a list of what needs to be done, how can you expect a team to execute a project? Without knowing what to do, the team will be lost and eventually the project will be a failure.

Beginning Scope Definition

The project charter developed during initiation and the stakeholder requirements document, also called the requirement documentation, contain enough information about the project and the product to start defining the project scope. Now that the project is in the planning stage, you have more information than you had in the initiation stage. Therefore, you are in a better position to analyze the needs and expectations related to the project and convert them into requirements. Furthermore, the assumptions and constraints can be revisited and analyzed at greater length, and additional assumptions and constraints can be identified. This will help to define the project scope with more clarity and specificity.

Purpose of the Project Scope Statement:

The Project Scope Statement is the output of the Project Scope Definition activity. The project scope statement serves the following purposes:

• It serves as a component to the baseline that will be used to evaluate whether the request for a change or additional work falls within or beyond the scope of the project.
• By providing a common understanding of the project scope, the scope statement helps bring the stakeholders onto the same page in their expectations.
• Because the scope statement describes the deliverables and the work required to create those deliverables, it is used to create a WBS, which helps in scheduling the project.
• It serves as a guide for the project team to do more in-depth planning, if necessary, and to perform work during project execution.

Scope Definition Process

The scope definition process can be summarized at a high level using the picture below:

As you can see in the picture, the scope definition process uses some inputs, applies some tools and techniques and then produces the output: which in this case will be the project scope document. Let us now take a look at these 3 steps in detail.

Input to Scope Definition

The project charter developed during project initiation presents the high-level project and product description. It also contains other information relevant to defining the scope, such as the project approval requirements. Project and product requirements listed in the requirement documentation also contain critical information for defining the scope.

Some of the organizational process assets that can be helpful in defining the scope are:

• Template for the project scope statement
• Scope-related project files from previous projects
• Lessons learned from previous projects or from previous phases of this project
• Policies and procedures relevant to defining the project scope

Trivia:
It’s critical to the success of the project that you determine the scope correctly: only the required features and functions for the product and only the required work to produce those features and functions; nothing less, nothing more.

Tools and Techniques for Scope Definition

The Tools and Techniques used for Scope Definition are:

• Identification of alternatives - This is a technique used to apply nonstandard approaches to perform project work; in this case, to define the project scope. A host of general management techniques can be used in this category; the most common ones are brainstorming and lateral thinking. Brainstorming was covered in detail in the previous chapter. Lateral thinking is synonymous with thinking outside the box. The idea is to think beyond the realm of your experience to search for new solutions and methods, not just better uses of the current ones.
• Product analysis - To finalize the details of the project scope, you might need to perform product analysis, which might include techniques such as product breakdown, requirement analysis, system analysis, system engineering, value analysis, and value engineering. The goal is to translate the project objectives into tangible deliverables and requirements.
• Facilitated workshops - The facilitated workshops described in the Previous Chapter can also be used in defining the scope.
• Expert judgment - You can use help from relevant experts in the organization to develop parts of the detailed project scope.

Output of Scope Definition

Depending on the input, the scope definition process can generate two kinds of output:
1. The project scope statement that contains the original scope definition and
2. Updates to some project documents

Changes and Updates

In the process of defining the project scope, you may end up modifying the existing requirements or adding new requirements. You may also learn more about the stakeholders. So, the documents that may be updated as a result of defining the scope are:

• Requirements documentation
• Requirements traceability matrix
• Stakeholder register

Project Scope Statement

The key output item of the Define Project process is the project scope statement, which is sometimes also called the detailed project scope statement or just the scope statement. The scope statement basically states what needs to be accomplished by the project.

It provides a documented baseline for the following:

• Developing a common understanding among the stakeholders about the project scope
• Making project decisions throughout the lifecycle of the project
• Measuring performance deviations from the scope

The specific elements of the project scope statement are:

• Project assumptions and constraints - Assumptions and constraints are initially included in the project charter. However, at this stage, you have more information about the project, and therefore you can revisit the initial assumptions and constraints, and you might be able to identify more assumptions and constraints. You should document the specific assumptions related to the project scope and also analyze their impact in case they turn out to be false. Due to the uncertainty built into them, the assumptions are potential sources of risk.

The constraints related to the project scope must also be documented in the scope statement. Because the constraints limit the team’s options, the constraints’ impact on the project must be evaluated. The constraints can come from various sources, such as a predetermined deadline for the completion of the project or a milestone, limits on the funds available for the project, and contractual provisions. However, the following are common constraints to consider across all projects:
o Quality
o Resources
o Scope
o Time

Some of the other terms which we might use in the subsequent chapters related to this topic are:

• Project deliverables - A deliverable is a unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project, a process, or a phase of the project. The deliverables can also include project management reports and documents. The scope statement provides the list of deliverables and their descriptions.
• Project exclusions - This involves drawing boundaries around the project by specifying what is included and what is not, especially focusing on the gray areas where the stakeholders can make their own assumptions, different from each other. It generally identifies what is excluded from the project, which helps to manage stakeholder expectations.
• Product description - The scope statement must describe the product scope and the product acceptance criteria.
     o Product scope description - Product scope is defined as features and functions that characterize a product, service, or result to be delivered by the project. The requirements documentation produced during the Collect Requirements process will help define the product scope.
     o Product acceptance criteria - This defines the process and criteria for accepting the completed products that the project will deliver.

Trivia:
You must be able to make a distinction between objectives, deliverables, and requirements. For example, in a project to launch a website, the website is a deliverable. That the website must print a warning message at the login time is a requirement, and that the website should increase the company revenue by 3 percent is an objective.

Previous: Requirements Collection Process

Next: Creating WBS

Chapter 29: Requirements Collection Process

As explained in the previous chapter, collecting requirements for a project is by far the most important activity of any project. Remember the restaurant, order collection activity? Would you like to eat what the restaurant wants you to eat or what you want?

In this chapter, we are going to take a look at how the requirement collection activity happens.

So, lets get started!!!

Collecting Requirements:

You collect requirements by using the Collect Requirements process as shown in the picture below

As you can see, the Project Charter and the Stakeholder Register are the inputs to the Requirements Collection process.

With these input items at your disposal, you use some tools and techniques to collect the requirements.

Tools and Techniques for Collecting Requirements

You collect the needed information about the requirements by using various techniques, such as observations, interviews, questionnaires and surveys, focus groups, facilitated workshops, group creativity and decision making techniques, and prototypes. Let us take a detailed look at these tools & techniques. Even though, you might be aware of these things, there is no harm in
revising them again...

Observations

Observation is the technique in which the requirements about a product or process are gathered by directly observing the user who is going to use the product or perform the process.

Interviews, questionnaires, and surveys

An interview is typically performed by asking predetermined and on the spot questions and recording the responses of the users/stakeholders. Depending on the situation, interviews may take several forms, such as one on one, multiple interviewees, or multiple interviewers. For example, by interviewing subject matter experts and individuals who ran similar projects before, you may identify and define some features and functions of the project deliverables.
When you want to cover a large number of respondents quickly, questionnaires and surveys will be more appropriate. These are based on written sets of questions. It is always easier to have those people answer the questions in one shot than having to meet them all one by one and collecting their response.

Focus groups

A focus group is a set of prequalified stakeholders and subject matter experts that are brought together with the purpose of learning about their opinions, expectations, and attitudes about a product, service, or result that will be the output of the project. Generally speaking, a moderator facilitates the interactive discussion to make this experience more conversational than one-on-one interviews.

Facilitated workshops

A facilitated workshop is a session that brings together the cross-functional stakeholders to focus on defining product requirements. It generally proves to be an effective technique for quickly defining cross-functional requirements and reconciling differences among the stakeholders regarding the requirements. These workshops also help in developing trust and improving communication among the stakeholders and therefore fostering relationships that will help the project to succeed.

Group creativity techniques

These are group activities organized to identify project & product requirements. Some examples are:

• Affinity diagram - In this technique, a large number of ideas are classified into different groups by using some criteria. This facilitates an effective and efficient review and analysis.
• Brainstorming - This is a creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later. This is one of the most widely used techniques where you let everyone come up with creative ideas and then consolidate/analyze them to choose the best suggestions. There are two specific kinds of brainstorming, which are:
     o Idea/mind mapping - This is an individual brainstorming technique in which a multitude of ideas are mapped around a central or key concept in order to expose commonalities and differences among ideas and generate new consolidated ideas. Mapping also helps in classifying ideas into groups by discovering relationships among them. In addition to project management, this technique is also used in other areas, such as personal, family, and education. It helps in summarizing, clarifying, and revising ideas.
     o Nominal group technique - This is the brainstorming technique with voting. The voting process is used to rank the ideas generated by brainstorming for further brainstorming or for prioritization.
• Delphi technique - This refers to an information-gathering technique used for experts to reach a consensus while sharing their ideas and preferences anonymously.
Group decision-making techniques
Group decision making is, in general, a process used to collectively assess and evaluate multiple alternatives in terms of expected outcomes. The decisions usually result in taking specific actions. This general technique can also be used to identify/generate, classify, and prioritize project requirements, including the product requirements. To reach a group decision, multiple methods are available. Some are:
• Dictatorship - One person has the authority to make the decision. While this expedites the decision making, it may not be the most effective decision-making method. This is usually because, people don't like to be told what needs to be done in a one way traffic kind of environment
• Unanimity - This is opposite of dictatorship. A decision is accepted only if everyone agrees.
• Majority - A decision must be supported by more than 50 percent of the members of the group. Like a usual election
• Plurality - The alternative supported by largest number of members wins even if this number does not make a majority. This situation arises when there are more than two alternatives. Plurality with two alternatives is simply a majority method.

Prototypes

A prototype is a working model of a product put together without developing the actual product. Organizations usually make prototypes for developing proof of concept. Prototypes can also be used to collect requirements by experimenting with the prototype and by letting stakeholders experiment with it and offer feedback. A prototype is more tangible than the abstract idea of a product. Prototypes can be improved and modified based on feedback from the stakeholders. In this way, prototypes support the progressive elaboration process of developing requirements.

Trivia:
Prototyping is a very effective way of getting new projects. Large IT organizations who serve clients, usually have senior members of their organizations (working for that client) to come up with possible enhancements to their existing IT system. These ideas are then made into small working prototypes that can be explained easily to the customer. Once the customer likes the prototype, he/she can be convinced to grant the budget required to take up this initiative as a full fledged project. In my personal experience, this method has a very good success or hit rate.

You use one or more of these techniques to generate the output of the Collect Requirements process.

Output of Collecting Requirements

During this process of collecting the requirements, you will produce two documents:

• The stakeholder requirements document and
• The requirements management plan.

Requirements documentation

Also called the stakeholder requirements document, this document consists of a list of requirements and any necessary detail for each item in the list. The details of the requirements and the format of the document depend on the project and the rules within the performing organization. CMMI level 4 or higher organizations usually have predefined formats using which they prepare such documents.

Following are some essential elements of the requirements document:

• Sources of requirements - This describes the overall project outcome to which the requirements apply and the purpose of the project, such as the opportunity being seized or the business problem being solved.
• Types of requirements - For effective management, you can organize the requirements into different categories using some criteria. For example, all requirements can be broadly organized into two categories: functional requirements, referring to the functionality of the project outcome, and nonfunctional requirements, such as compliance, compatibility, and support. Furthermore, these broad categories can be subdivided into more specific types, such as the following:
     o Quality requirements, such as not more than three bugs per software module.
     o Support and training requirements, such as that the product will be released with a manual.
     o Requirements that are based on assumptions and requirements that lead to constraints, for example, phase one of the project must be completed before a specific date.
• Impacts of the requirements - This element describes the impact of requirements on the project and on entities external to the project, such as different groups in the organization.

Requirements management plan

This plan documents how the requirements will be managed throughout the project life, which includes how they will be documented and analyzed.

The requirements management plan includes the following elements:

• Prioritization - The process and criteria to prioritize the requirements.
• Configuration management - How the changes to the requirements will be processed: initiated, analyzed, tracked, and reported.
• Reporting - How, by whom, and to whom the activities related to the requirements will be reported.
• Traceability - What the traceability structure of the requirements will be, for example, which attributes of a requirement will be captured on the traceability matrix.

Requirements traceability matrix

As the name suggests, the requirements traceability matrix is a table that traces each requirement back to its origin, such as product or business objective, and tracks its progress throughout the project life. Linking a requirement to the business objective underlines its value. Tracking the requirement throughout the lifecycle of the project ensures that it will be delivered before the project is completed. So, this table becomes a very useful tool to remind the team how important these requirements are, when they are going to be implemented, and how they are progressing in implementing them.

The requirements traceability matrix includes the following:

• Requirements linked to the origin of the project, such as the opportunity or business need
• Requirements linked to the project objectives and deliverables
• Requirements linked to the project scope and the product scope
• Requirements linked to the product design, development, and testing
• High-level requirements linked to their details
• The attributes linked to a requirement

Trivia:
The Traceability Matrix is a valuable tool at the end of the project to validate if all the requirements have been captured in the end product. Every single entry in the traceability matrix must have been addressed by the product in order for it to be a success/completed project.

Previous: Collecting Requirements for Projects

Next: Defining the Project Scope

Chapter 28: Collecting Requirements for the Project

In the previous chapter, we saw the importance of scope management and how a good project manager would manage the scope of his project. In this chapter, we are going to take a look at Gathering Requirements for the Project…

So, lets get started!!!

What is Gathering Requirements?

Gathering Requirements is the phase in the project where we begin by identifying what the user or the customer (the person who is going to use the project/product) wants. Without a clear cut idea of what the user wants, we cannot possibly give it to him.

A requirement is a condition, characteristics, or a capability that a specific outcome of the project must have.

Requirements may come from different sources, such as from standards, specifications, and contracts. Stakeholder expectations and needs often materialize into requirements as well.

A Real Life Example:

Lets say, you walk into a restaurant with your spouse. Usually the Restaurant Floor Supervisor would walk up to your table and greet you first and then ask you for the order. You will tell him all your favorite dishes and he will go place the order with the kitchen staff. If no one from the restaurant comes up to ask you what you want, can they give you what you like to eat? Unless the floor supervisor captures your order in a notepad correctly (without missing your favorite dishes) you will not leave the restaurant satisfied.

The part where the floor supervisor in the restaurant notes down all your dish orders is equivalent to the Requirements Gathering Phase of a Project.

Unless, the requirements are gathered correctly, the outcome will not be nice and the customer is going to be unhappy.

Trivia:
Generally speaking, project requirements should include the product requirements. However, you may find that, many organizations distinguish between project requirements and product requirements. The project requirements include strictly project-related requirements, such as schedule and delivery requirements, business-related requirements, and other project management requirements, whereas the product requirements include the product-related requirements, such as requirements related to performance, security, and defects.

Requirements Planning

In order to capture requirements correctly and accurately, we need to plan the whole activity. You, as the project manager need to do some requirements planning, which includes:

• Defining and documenting the project requirements
• Defining and documenting the product requirements
• Developing a plan to manage the requirements; the requirements management plan

You do all this in order to determine and fulfill stakeholder expectations and needs. In other words, get the order correctly so that the customer will eat what he wants and leave happily.

Trivia:
How effective you are in capturing requirements will directly impact how effectively you will be able to meet the stakeholder requirements/expectations. Hence it is imperative that proper requirements’ gathering is required for any successful project.

In the next chapter, we will take a look the Requirements Collection Process.

Previous: Managing Scope

Next: Requirements Collection Process

Chapter 27: Managing Scope

In the previous chapter, we saw how important it is to create the Project Management Plan and also about how to create it. Let us now get into the Scope Management part of our Project Planning phase.

What is Scope?

The scope of a project consists of the project scope and the product scope. The project scope is defined as the work that must be performed to deliver the required products, services, or results with the specified functions and features. The product scope is the set of functions and features that characterize a product, service, or result to be delivered by the current project.
It is about both what is included in the project and what is not. In other words, scoping a project means drawing boundaries around it, so that everyone knows what will be done and what will not be done. The importance of managing the project scope cannot be overemphasized because it has a profound impact on the overall success of the project.

Trivia:
Project scope is not the same thing as the product scope. Project scope is the work required to deliver the product scope.

Is Scope Management Important?

If you feel the scope management is not important, imagine this:

Let’s say you started a project to deliver an online banking website for ABC Bank and are 6 months into development. The go live date is in 12 weeks and the customer wants to include credit card information in the website. This was not part of the initial estimates & scope.
Unfortunately, your project manager accepted this because he wanted to please the customer.
Now think what will happen to you and your team mates? You all will be neck deep in unexpected work and the next 12 weeks will be most miserable work days of your life and that is only if you manage to deliver the project to the customer. If you don't, then its only going to get worse…
If your project manager had put his foot down and said, the credit card details were not part of the initial scope & estimate and a change of this magnitude cannot be taken up in such a short notice of 12 weeks, imagine the scenario…

Now you get the idea of why scope management is important?

What is Project Scope Management

The major goal of scope management is to ensure that the required work and only the required work is included and performed in the project.

Just go back to the previous paragraph and read the example. If the project manager had a scope management document that outlined the list of tasks that will be completed as part of the project, he could use that to substantiate his argument that, such a large chunk of work cannot be taken up this late in the project execution.

The Project Scope Management will do the following:

1. Collect requirements - Define the project and product requirements and develop a plan to manage those requirements. This will help clarify what needs to be done.
2. Define scope - Develop a detailed description of the project and the product that will determine what needs to be done.
3. Create work breakdown structure (WBS) - Break down the scope into concrete, manageable components.
4. Verify scope - Formalize the acceptance of the completed project deliverables. Identify how you will verify that the project scope has been executed as planned.
5. Control scope - Determine how to monitor the status of the project and product scope and monitor and control changes to the scope.

Let us take a picture to understand this better.

Note: The above picture is a high level view. Each stage may involve an in depth analysis by the Project Manager to capture accurate information.

Let us now take a look at which process group each of these activities belong to and what the output of these activities would be.

Scope Management Process	Process Group	Output
Collect Requirements	Planning	Requirement management plan and other requirement documents
Define Scope	Planning	Project scope statement
Create WBS	Planning	WBS and scope baseline
Verify Scope	Monitoring and controlling	Acceptance of deliverables and change requests
Control Scope	Monitoring and controlling	Work performance measurements

Developing the Project Scope Management Plan

Before starting to perform the five scope management processes, you develop the scope management plan. This work is recommended to be part of the effort of developing the project management plan. This plan will work as a guide for handling the following:

• How can you define the scope? To answer this question, the scope management plan includes the following:
      o A process to prepare a detailed project scope statement based on the preliminary project scope statement.
      o A process that will enable the creation of the work breakdown structure (WBS) from the detailed project scope statement and will establish how the WBS will be maintained and approved.
• How can you verify the scope? The scope management plan answers this question by including a process that describes how the formal verification and acceptance of the completed project deliverables will be obtained.
• How can you control the scope? The scope management plan answers this question by including a process that specifies how the requests for changes to the detailed project scope statement (which we also refer to as the scope statement) will be processed.

Whether the project scope management plan is informal and high-level (without too much detail) or formal and detailed depends upon the size, complexity, and needs of the project.

The project scope management plan becomes part of the project management plan.

So, the project scope planning specifies how to define, verify, and control the project. Before you can actually define the scope, though, you need to have a very crucial item in place: stakeholder requirements.

Previous: Developing Project Management Plan

Next: Collecting Requirements