In project management, defining and agreeing on the scope of the project is probably the most important task.  Burke (2017) defines scope management as the processes required to ensure that the project includes all the work required, and only the work required to complete the project successfully.  It is primarily concerned with defining and controlling what is or is not included in the project.  The challenges in defining the project scope and aiming for successful completion are more around “agreeing with everyone’s expectations” and having a clear project definition. The Japanese practice of “Nemawashi” which involves negotiating with all stakeholders to obtain agreement from everybody, is a good example/technique aiming for all processes to be near perfect. Try to research the term ‘Nemawashi’ and review how this approach may be of benefit in agreeing to the expectations in a project.

It is critical to have a clear and well-defined scope for the success of the project. Project Scope Management includes the processes required to ensure that the project includes all the work required to complete it successfully. Project scope management is primarily concerned with defining and controlling what is and is not included in the project. The following figures provides an overview of the Project Scope Management processes, and a process flow diagram of those processes and their inputs, outputs, and other related Knowledge area processes.

In the project context, the term scope can refer to:

• Product scope. The features and functions that characterise a product, service, or result
• Project scope. The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.

This module focuses on the processes used to manage the project scope. We will examine the concept stage (the first stage) of a project and discuss the importance of ‘scoping’ and ‘scope creep’.

Note: Not all process interactions and data flow among the processes are shown.

Project Scheduling and developing a Work Breakdown Structure is a topic that some people perceive as being slightly ‘technical’. In reality, nothing could be further from the truth.  Projects involve a beginning and an end date and a series of tasks to deliver the required outcomes.  Scheduling is simply listing these tasks, linking them as appropriate, and determining not only how the various tasks are interdependent, but which ones occur independently, sequentially, and concurrently.  It’s a bit like a flow chart.

Scheduling involves breaking down the tasks required to complete the project into individual activities, hence the term Work Breakdown Structure (WBS).  A WBS is a series of parent and child tasks.  Imagine if you had to prepare a plan of how you wake up, get out of bed in the morning, have a shower, dress yourself, have breakfast, and prepare to leave for work or university.  You would probably group various tasks into logical functions and list the tasks in some workable structure.  For example, it would be a little difficult to start dressing yourself before you have woken up (apologies to those of you who can do this, but I can’t!).  So, Scheduling and WBS are not technical, they are common sense management activities that people involved with projects do constantly.

This module focuses on how schedules are developed, the initial supporting information required, the tools used, and the overriding importance of performing schedule iterations.  Some of the devices and techniques that we will examine in this module include:

• Work Breakdown Structure
• PERT networks
• Critical path analysis
• Network analysis
• Gantt Charts
• Task relationships.

Project Scheduling

The Project Management Institute defines scheduling as an essential element of project management because it makes clear to all participants when work is expected to be completed.  It also shows the time-related dependencies between different project tasks.

A detailed project plan must include a schedule indicating the time and resources for each activity described in your work breakdown structure.  Unfortunately, as easy as this sounds, scheduling tasks can be a challenge for project managers when aiming to reflect the reality of the project, as well as the customer’s ongoing requirements.  If the project is large, the challenge will be larger still and it may be appropriate to break the project into smaller, more manageable sub-projects.  Whatever the size of the project, a schedule is created keeping in mind potential changes.  The schedule should be easy to understand and easily refined and expanded as the project proceeds.

Factors necessary to develop a framework that will help create and maintain your project schedule include:

• Project start date
• Task specifications:
  • durations
  • interdependencies
  • constraints and deadlines
  • types
• Predetermined Project calendars
• Resource allocation and requirements (refer to Module 8)

Project Plan

The project plan must contain a short scope summary and a detailed statement of the business’s mission, goals and objectives.  It should also have a detailed description of the approach to the work with specifications of the overall project resources and intended evaluation tools.  Meredith and Mantel (2019) point out that any project plan must have the following main elements:

• A project overview
• Detailed objectives addressing the general organisation’s goal(s)
• General approach: managerial and technical approaches to the work
• Contractual aspects
• Schedules
• Resources
• Personnel
• Evaluation methods
• Potential problems and risk plan

According to the Project Management Institute, the project plan defines how the project is going to be executed, monitored, controlled, and closed. Consequently, the project plan would document and include:

• Project management processes and activities to accomplish any specific project
• The level of implementation of each of these processes and relevant activities
• How these processes will be used to manage the specific projects
• How work will be executed to accomplish the project objectives
• Key management reviews for processes

Project plans are usually developed once the above elements are clearly identified.  There are also various ways in which a project plan can be constructed, but usually, this is done by listing the activities required to carry out the project from start to completion in a sequential manner.  The classic and common understanding is that a project plan will give you the detailed activities and processes of the project deliverables.  A precise, detailed, and coordinated activity list is required to complete the project successfully.

The table below lists some traditional tools and techniques for project planning. Yet, in this study term, we will use a conceptually simple method to assist us in sorting out and planning the project proposal: The Work Breakdown Structure (WBS).

Defining the Scope

You always want to know exactly what work has to be done before you start it. You have a collection of team members, and you need to know exactly what they’re going to do to meet the project’s objectives. The scope planning process is the very first thing you do to manage your scope. Project scope planning is concerned with the definition of all 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.

You already have a head start on refining the project’s objectives in quantifiable terms, but now you need to plan further and write down all the intermediate and final deliverables that you and your team will produce over the course of the project. Deliverables include everything that you and your team produce for the project (i.e., 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. They include every intermediate document, plan, schedule, budget, blueprint, and anything else that will be made along the way, including all of the project management documents you put together. Project deliverables are tangible outcomes, measurable results, or specific items that must be produced to consider either the project or the project phase completed. Intermediate deliverables, like the objectives, must be specific and verifiable.

All deliverables must be described in a sufficient level of 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 of the project and then manage the project so that they are produced according to the agreed-on criteria. Deliverables are the output of each development phase, described in a quantifiable way.

Let’s revise the scope definition in the following video.

_{(Click the image below to access the video)}

Project Requirements

After all the deliverables are identified, the project manager needs to document all the requirements of the project. Requirements describe the characteristics of the final deliverable, whether it is a product or a service. They describe the required functionality that the final deliverable must have or specific conditions the final deliverable must meet in order to satisfy the objectives of the project. A requirement is an objective that must be met. The project’s 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, and how does a business process work?

Requirements may include attributes 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 final project deliverable should look like and what it should do. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. They can be divided into six basic categories: functional, non-functional, technical, business, user, and regulatory requirements.

Functional Requirements

Functional requirements describe the characteristics of the final deliverable 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.

Army Defence Autonomous Vehicle Example

If you were buying autonomous vehicles for an Army Defence unit in charge of emergency disaster management, your functional requirement might be: “The autonomous vehicles should be able to take up to a one ton load from a warehouse to an emergency distribution destination point.”

Emergency Response Computer System Example

For a computer system you may define what the system is to do: “The system should store all details of missing people.”

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 final 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 autonomous army vehicle example, the functional requirement is for an autonomous vehicle to take a load from a warehouse to an emergency distribution destination point. Without any constraints, the solutions being offered might result in anything from a small to a large truck. Non-functional requirements can be split into two types: performance and development.

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

• The purchased autonomous trucks should be Australian-made trucks due to government incentives.
• The load area must be covered.
• The load area must have a height of at least 10 feet.

Similarly, for the emergency response computer system example, you might specify values for the generic types of performance constraints:

• The response time for information is displayed on the screen for the 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 should be built in.
• The length of time a record should be held for auditing purposes.

For the customer records example, the constraints might be:

• The system should be available 24/7.
• The system should be able to hold 200,000 customer records initially.
• The system should be able to add 100,000 records a year for 10 years.
• A record should be fully available on the system for at least seven years.

One 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 non-functional 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, development methods, etc.

Technical Requirements

Technical requirements emerge from the functional requirements to answer the questions: how will the problem be solved this time and will it be solved technologically and/or procedural? They specify how the system needs to be designed and implemented to provide the required functionality and fulfill required operational characteristics.

For example, in a software project, the functional requirements may stipulate that a database system will be developed to allow access to financial data through a remote terminal. The corresponding technical requirements would spell out the required data elements, the language in which the database management system will be written (due to existing knowledge in-house), the hardware on which the system will run (due to existing infrastructure), telecommunication protocols that should be used, and so forth.

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, satisfying the business needs, rather than specific functions the system must perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives.

User Requirements

User requirements describe what the users need to do with the system or product. The focus is on the user experience with the system under all scenarios. These requirements are the input for the next development phases: user-interface design and system test cases design.

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 that are imposed by the government.

An Example of Requirements

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

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

• ATM functional requirement: The system will enable the user to select whether or not to produce a hard-copy transaction receipt before completing a transaction.
• ATM non-functional requirement: All displays will be in white, 14-point Arial text on black back­ground.
• ATM technical requirement: The ATM system will connect seamlessly to the existing customer’s database.
• ATM user requirement: The system will complete a standard withdrawal from a personal account, from login to cash, in less than two minutes.
• 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.

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 why they have been made, as well. Understanding the reasoning that was used to arrive at a decision is critical in avoiding repetition. For example, the fact that a particular feature has been excluded, because it is simply not feasible, 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 that the project manager performs this task. The project manager enlists the help of all the stakehold­ers (business analysts, requirement analysts, business process owners, customers and other team members) to conduct the discussions, brain-storming, and interviews, and to document and sign off the requirements. The project manager is responsible only for enabling the process and facilitating it. If the project manager feels that the quality of the document is questionable, his or her duty is to stop the development process.

The project manager reviews the requirements, incorporates them into the project documentation library, and uses them as an input for the project plan.

Software Requirements Fundamentals

This section refers to requirements of “software” because it is concerned with problems to be addressed by software. A software requirement is a property that must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization that has commissioned the software, to correct shortcomings of existing software, to control a device, etc. The functioning of users, business processes, and devices is typically complex. Therefore, the requirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.

An essential property of all software requirements is that they be verifiable. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on a call center may necessitate the development of simulation software. Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.

Requirements have other attributes in addition to the behavioral properties that they express. Common examples include a priority rating to enable trade-offs in the face of finite resources and a status value to enable project progress to be monitored. Typically, software requirements are uniquely identified so that they can be monitored over the entire software life cycle.

Measuring Requirements

As a practical matter, it is typically useful to have some concept of the volume of the requirements for a particular software product. This number is useful in evaluating the size of a change in requirements, in estimating the cost of a development or maintenance task, or simply in using it as the denominator in other measurements (see Table below).

Scope Inputs

The project manager gathers initial project facts from the project charter. In addition, background information on the stakeholder’s workplace, existing business model and rules, etc. assist in creating the vision of the final product/service, and consequently, the project scope (see Figure below).

Techniques

Certainly being a seasoned project manager broadens the repertoire of one’s scope planning techniques. An experienced project manager can draw on past experiences with like projects to determine the work that is realistically doable, given time and cost constraints, for a current project. Communication and negotiation skills are a “must-have” as well. Project managers need to educate stakeholders about the project impacts of some requirements. Adding complexity to a project may require more staff, time, and/or money. It may also have an impact on project quality. Some aspects of the project may be unfeasible – stakeholders need to know this so they can adjust their vision or prepare for future challenges.

Gathering requirements is part of scope definition, and it can be done using one or more of following techniques:

• Interviews
• Focus groups
• Facilitated groups such as JAD (joint application development)
• Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity diagnostics
• Prototyping
• Observation
• Questions and surveys
• Group decision-making techniques: unanimity, majority, plurality, dictatorship

Requirements Traceability Matrix

The requirements traceability matrix is a table that links requirements to their origin and traces them throughout the project life cycle. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. This process includes, but is not limited to, tracking:

• Requirements to business needs, opportunities, goals, and objectives
• Requirements to project objectives
• Requirements to project scope/work breakdown structure deliverables
• Requirements to product design
• Requirements to product development
• Requirements to test strategy and test scenarios
• High-level requirements to more detailed requirements

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), and date completed. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

Matrix Fields

These are suggestions only and will vary based on organizational and project requirements.

• A unique identification number containing the general category of the requirement (e.g., SYSADM) and a number assigned in ascending order (e.g., 1.0, 1.1, 1.2)
• Requirement statement
• Requirement source (conference, configuration control board, task assignment, etc.)
• Software requirements specification/functional requirements document paragraph number containing the requirement
• Design specification paragraph number containing the requirement
• Program module containing the requirement
• Test specification containing the requirement test
• Test case number(s) where requirement is to be tested (optional)
• Verification of successful testing of requirements
• Modification field (If a requirement was changed, eliminated, or replaced, indicate disposition and authority for modification.)
• Remarks

Work Breakdown Structure

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

WBS describes the products or services to be delivered by the project and how they are decomposed and related. It is a deliverable-oriented decomposition of a project into smaller components. It defines and groups a project’s discrete work elements in a way that helps organize and define the total work scope of the project.

A WBS also provides the necessary framework for detailed cost estimating and control, along with providing guidance for schedule development and control. A WBS is a hierarchical, deliverable, and oriented representation of all areas of work involved in a project. WBS is the spine of our project plan. It’s not a “Must Do” list. It should be developed from the project’s scope so we can’t just dive into listing “to-dos.” It is often portrayed graphically as a hierarchical or top-down tree; however, it can also be a tabular list of “element” categories, activities, and tasks or the indented task list that appears in your Gantt chart schedule.

The WBS creation involves:

• Listing all the project outputs (deliverables and other direct results)
• Identifying all the activities required to deliver the outputs
• Subdividing these activities into sub activities and tasks
• Identifying the deliverable and milestone(s) of each task
• Identifying the time usage of all the resources (personnel and material) required to complete each task

The purpose of developing a WBS is to:

• Allow easier management of each component
• Allow accurate estimation of time, cost, and resource requirements
• Allow easier assignment of human resources
• Allow easier assignment of responsibility for activities

Example of a WBS

If I want to clean a room, I might begin by picking up clothes, toys, and other things that have been dropped on the floor. I could use a vacuum cleaner to get dirt out of the carpet. I might take down the curtains and take them to the cleaners, and then dust the furniture. All of these tasks are subtasks performed to clean the room. As for vacuuming the room, I might have to get the vacuum cleaner out of the closet, connect the hose, empty the bag, and put the machine back in the closet. These are smaller tasks to be performed in accomplishing the subtask called vacuuming. The figure below shows how this might be portrayed in WBS format.

It is very important to note that we do not worry about the sequence in which the work is performed or any dependencies between the tasks when we do a WBS. That will be worked out when we develop the schedule. For example, under 3.0 Vacuum, it would be obvious that 3.3 Vacuum carpet would be performed after 3.4 Connect hose and plug! However, you will probably find yourself thinking sequentially, as it seems to be human nature to do so. The main idea of creating a WBS is to capture all of the tasks, irrespective of their order. So if you find yourself and other members of your team thinking sequentially, don’t be too concerned, but don’t get hung up on trying to diagram the sequence or you will slow down the process of task identification. A WBS can be structured any way it makes sense to you and your project. In practice, the chart structure is used quite often but it can be composed in outline form as well.

You’ll notice that each element at each level of the WBS in both figures is assigned a unique identifier. This unique identifier is typically a number, and it’s used to sum and track costs, schedules, and resources associated with WBS elements. These numbers are usually associated with the corporation’s chart of accounts, which is used to track costs by category. Collectively, these numeric identifiers are known as the code of accounts.

Lets revise with this video:

_{(Click the image below to access the video)}

There are also many ways you can organize the WBS. For example, it can be organized by either deliverable or phase. The major deliverables of the project are used as the first level in the WBS. For example, if you are doing a multimedia project the deliverables might include producing a book, CD, and a DVD.

Many projects are structured or organized by project phases. Each phase would represent the first level of the WBS and their deliverables would be the next level and so on.

The project manager is free to determine the number of levels in the WBS based on the complexity of the project. You need to include enough levels to accurately estimate project time and costs but not so many levels that are difficult to distinguish between components. Regardless of the number of levels in a WBS, the lowest level is called a work package.

Work packages are the components that can be easily assigned to one person or a team of people, with clear accountability and responsibility for completing the assignment. The work-package level is where time estimates, cost estimates, and resource estimates are determined.

100 Percent Rule

The 100 percent rule is the most important criterion in developing and evaluating the WBS. The rule states that each decomposed level (child) must represent 100 percent of the work applicable to the next higher (parent) element. In other words, if each level of the WBS follows the 100 percent rule down to the activities, then we are confident that 100 percent of the activities will have been identified when we develop the project schedule. When we create the budget for our project, 100 percent of the costs or resources required will be identified.

Scope Statement

Scope statements may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include measurable success criteria for the project.

A scope statement  captures, in very broad terms, the product of the project: for example, “development of a software-based system to capture and track orders for software.” A scope statement should also include the list of users using the product, as well as the features in the resulting product.

As a baseline scope statements should contain:

• The project name
• The project charter
• The project owner, sponsors, and stakeholders
• The problem statement
• The project goals and objectives
• The project requirements
• The project deliverables
• The project non-goals (what is out of scope)
• Milestones
• Cost estimates

In more project-oriented organizations, the scope statement may also contain these and other sections:

• Project scope management plan
• Approved change requests
• Project assumptions and risks
• Project acceptance criteria

In order to develop our schedule, we first need to define the activities, sequence them in the right order, estimate the resources needed, and estimate the time it will take to complete the tasks.

Defining Activities

The activity definition process is a further breakdown of the work package elements of the WBS. It docu­ments the specific activities needed to fulfill the deliverables detailed in the WBS. These activities are not the deliverables themselves but the individual units of work that must be completed to fulfill the deliverables. Activity definition uses everything we already know about the project to divide the work into activities that can be estimated. You might want to look at all the lessons learned from similar projects your company has done to get a good idea of what you need to do on the current one.

Expert judgment in the form of project team members with prior experience developing project scope statements and WBS can help you define activities. If you are asked to manage a project in a new domain, you might also use experts in that particular field to help define tasks so you can understand what activities are going to be involved. You may want to create an activity list and then have the expert review it and suggest changes. Alternatively, you could involve the expert from the very beginning and ask to have an activity definition conversation with him or her before even making your first draft of the list.

Sometimes you start a project without knowing a lot about the work that you’ll be doing later. Rolling-wave planning lets you plan and schedule only the portion that you know enough about to plan well. When you don’t know enough about a project, you can use placeholders for the unknown portions until you know more. These are extra items that are put at high levels in the WBS to allow you to plan for the unknown.

A Case Study

Susan and Steve have decided to get married, but they don’t have much time to plan their wedding. They want the big day to be unforgettable. They want to invite many people and provide a great time. They’ve always dreamed of a June wedding, but it’s already January. Just thinking about all of the details involved is overwhelming. Susan has been dreaming of the big day since she was 12, but it seems that there’s so little time for all the tasks to be completed. When they were choosing the paper for the invitations, the couple realized that they needed help.

Much work has to be done before June. First, Sally figures out what work needs to be done. She starts to put together a to-do list:

• Invitations
• Flowers
• Wedding cake
• Dinner menu
• Band

Since many different people are involved in the making of the wedding, it takes much planning to coordinate all the work in the right order by the right people at the right time. Initially, Sally was worried that she didn’t have enough time to make sure that everything would be done properly. However, she knew that she had some powerful time management tools on her side when she took the job, and these tools would help her to synchronize all the required tasks.

To get started, Sally arranged all the activities in a work breakdown structure. The next exercise presents part of the WBS Sally made for the wedding.

WBS Exercise

Arrange the following activities into the WBS  to show how the work items decompose into activities.

• Shop for shoes
• Create guest list
• Have the tailoring and fitting done
• Shop for dress
• Find caterer
• Cater the wedding
• Wait for RSVPs
• Mail the invitations
• Finalize the menu
• Print the invitations
• Choose the bouquet

_{Scan the code below for an alternative answer.}

Activity List

Now that the activity definitions for the work packages have been completed, the next task is to complete the activity list. The project activity list is a list of everything that needs to be done to complete your project, including all the activities that must be accomplished to deliver each work package. Next you want to define the activity attributes. Here’s where the description of each activity is kept. It includes all the information you need to figure out plus the order of the work. Any predecessor activities, successor activities, or constraints should be listed in the attributes along with descriptions and any other information about resources or time that you need for planning. The three main kinds of predecessors are finish-to-start (FS), start-to-start (SS), and finish-to-finish (FF). The most common kind of predecessor is the finish-to-start. It means that one task needs to be completed before another one can start. When you think of predecessors, this is what you usually think of; one thing needs to end before the next can begin. It’s called finish-to-start because the first activity’s finish leads into the second activity’s start .

The start-to-start predecessor is a little less common, but sometimes you need to coordinate activities so they begin at the same time.

The finish-to-finish predecessor shows activities that finish at the same time.

It is possible to have start-to-finish (SF) predecessors. This happens when activities require that another task be started before the successor task can finish. An example might be that the musicians cannot finish playing until the guests have started leaving the ceremony. In addition, there are some particular types of predecessors that must be considered.

External Predecessors

Sometimes your project will depend on things outside the work you’re doing. For the wedding, we are depending on the wedding party before us to be out of the reception hall in time for us to decorate. The decoration of the reception hall then depends on that as an external predecessor.

Discretionary Predecessors

These are usually process- or procedure-driven or best-practice techniques based on past experience. In the wedding example, Steve and Susan want the bridesmaids to arrive at the reception before the couple arrives. There’s no necessity; it is just a matter of preference.

Mandatory Predecessors

You can’t address an invitation that hasn’t been printed yet. So printing invitations is a mandatory predecessor for addressing them. Mandatory predecessors are the kinds that have to exist just because of the nature of the work.

Leads and Lags

Sometimes you need to give some extra time between activities. Lag time is when you purposefully put a delay between the predecessor task and the successor. For example, when the bride and her father dance, the others wait awhile before they join them.

Lead time is when you give a successor task some time to get started before the predecessor finishes. So you might want the caterer preparing dessert an hour before everybody is eating dinner.

Milestones

All of the important checkpoints of your project are tracked as milestones. Some of them could be listed in your contract as requirements of successful completion; some could just be significant points in the project that you want to keep track of. The milestone list needs to let everyone know which milestones are required and which are not.

Some milestones for Susan and Steve’s wedding might be:

• Invitations sent
• Menu finalized
• Location booked
• Bridesmaids’ dresses fitted

As you figure out which activities will need to be done, you may realize that the scope needs to change. When that happens, you need to create a change request and send it through the change control system.

Some things that could go wrong:

The Activity Sequencing Process

Now that we know what we have to do to make the wedding a success, we need to focus on the order of the work. Sally sat down with all of the activities she had defined for the wedding and decided to figure out exactly how they needed to happen. That’s where she used the activity sequencing process.

The activity attribute list Sally created had most of the predecessors and successors necessary written in it. This is where she thought of what comes first, second, third, etc. Sally’s milestone list had major pieces of work written down, and there were a couple of changes to the scope she had discovered along the way that were approved and ready to go.

Creating the Gantt Chart

A Gantt chart is a type of bar chart, developed by Henry Gantt, that illustrates a project schedule. Gantt charts are easy to read and are commonly used to display schedule activities. These charts display the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency relationships (i.e., precedence network) between activities.

Gantt charts show all the key stages of a project and their duration as a bar chart, with the time scale across the top. The key stages are placed on the bar chart in sequence, starting in the top left corner and ending in the bottom right corner. A Gantt chart can be drawn quickly and easily and is often the first tool a project manager uses to provide a rough estimate of the time that it will take to complete the key tasks. Sometimes it is useful to start with the target deadline for completion of the whole project, because it is soon apparent if the time scale is too short or unnecessarily long. The detailed Gantt chart is usually constructed after the main objectives have been determined.

In this example,  key stage K (Organize distribution) starts at week 23 so that its end point coincides with key stage L (Distribute directory). However, K could begin as early as week 17, as soon as key stage J is completed. Key stage K is therefore said to have “slack.” Key stage H (Agree print contract) has been placed to end at week 12. However, it could end as late as week 22, because key stage I (Print directory) does not begin until week 23. Key stage H is therefore said to have “float.” Float time can be indicated on the chart by adding a line ahead of the bar to the latest possible end point. Slack and float show you where there is flexibility in the schedule, and this can be useful when you need to gain time once the project is up and running.

You can add other information to a Gantt chart, for example:

• Milestones could be indicated by using a symbol such as a diamond or triangle.
• Project meetings could be indicated by another symbol such as a circle.
• Reviews of progress could be indicated by a square.

For a complex project, you may decide to produce a separate Gantt chart for each of the key stages. If you do this shortly before each key stage begins, you will be able to take any last-minute eventualities into account. These charts provide a useful tool for monitoring and control as the project progresses.

Gantt charts are relatively easy to draw by hand, but this doesn’t offer the same level of flexibility during monitoring that you would get from a software package. Various programs are available to assist project managers in scheduling and control. Once the data have been entered, a program helps you to work on “what if” scenarios, showing what might happen if a key stage is delayed or speeded up. This is more difficult if you are working manually.

Creating the Network Diagram

Many project managers use network diagrams when scheduling a project. The network diagram is a way to visualize the interrelationships of project activities. Network diagrams provide a graphical view of the tasks and how they relate to one another. The tasks in the network are the work packages of the WBS. All of the WBS tasks must be included in the network because they have to be accounted for in the schedule. Leaving even one task out of the network could change the overall schedule duration, estimated costs, and resource allocation commitments.

The first step is to arrange the tasks from your WBS into a sequence. Some tasks can be accomplished at any time throughout the project where other tasks depend on input from another task or are constrained by time or resources.

The WBS is not a schedule, but it is the basis for it. The network diagram is a schedule but is used primarily to identify key scheduling information that ultimately goes into user-friendly schedule formats, such as milestone and Gantt charts.

The network diagram provides important information to the project team. It provides information about how the tasks are related, where the risk points are in the schedule, how long it will take as currently planned to finish the project, and when each task needs to begin and end.

In our wedding planner example, Sally would look for relationships between tasks and determine what can be done in parallel and what activities need to wait for others to complete. As an example, the figure below shows how the activities involved in producing the invitations depend on one another. Showing the activities in rectangles and their relationships as arrows is called a precedence diagramming method (PDM). This kind of diagram is also called an activity-on-node (AON) diagram.

Another way to show how tasks relate is with the activity-on-arrow (AOA) diagram. Although AON is more commonly used and is supported by all project management programs, PERT is the best-known AOA-type diagram and is the historical basis of all network diagramming. The main difference is the AOA diagram is traditionally drawn using circles as the nodes, with nodes representing the beginning and ending points of the arrows or tasks. In the AOA network, the arrows represent the activities or tasks.

All network diagrams have the advantages of showing task interdependencies, start and end times, and the critical path (the longest path through the network) but the AOA network diagram has some disadvantages that limit the use of the method.

The three major disadvantages of the AOA method are:

• The AOA network can only show finish-to-start relationships. It is not possible to show lead and lag except by adding or subtracting time, which makes project tracking difficult.
• There are instances when dummy activities can occur in an AOA network. Dummy activities are activities that show the dependency of one task on other tasks but for other than technical reasons. For example, one task may depend on another because it would be more cost effective to use the same resources for the two; otherwise the two tasks could be accomplished in parallel. Dummy activities do not have durations associated with them. They simply show that a task has some kind of dependence on another task.
• AOA diagrams are not as widely used as AON diagrams simply because the latter are somewhat simpler to use, and all project management software programs can accommodate AON networks, whereas not all can accommodate AOA networks.

The Critical Path

The critical path describes the sequence of tasks that would enable the project to be completed in the shortest possible time. It is based on the idea that some tasks must be completed before others can begin. A critical path diagram is a useful tool for scheduling dependencies and controlling a project. In order to identify the critical path, the length of time that each task will take must be calculated.

Let’s take a look at an example. The length of time in weeks for each key stage is estimated:

We have given the key stage “Secure funds” an estimated time of zero weeks because the project cannot start without the availability of some funding, although estimates would provide detail at a later stage. The stages can now be lined up to produce a network diagram that shows that there are three paths from start to finish and that the lines making up each path have a minimum duration .

If we now trace each of the possible paths to “Distribute directory” (the finishing point), taking dependencies into account, the route that has the longest duration is known as the critical path. This is the minimum time in which it will be possible to complete the project.

In this example, the critical path is A–B–C–D–E–F–I–L, and the earliest completion date for the project is the sum of the estimated times for all the stages on the critical path – 28 weeks – from the point of securing the funding. All the key stages on the critical path must be completed on time if the project is to be finished on schedule.

If the projected total time is much longer than the project sponsor’s expectations, you will need to renegotiate the time scale. Mapping the critical path helps to identify the activities that need to be monitored most closely.