Organize / Plan / Perform STUDY MATERIAL PROJECT MANAGEMENT (18ME745) ON Module-2: Planning Projects Module: 02: System of Limits, Fits,By Tolerance and Gauging: Dr. Shekharappa B Mallur Professor and former Chairman Department of Studies in Mechanical Engineering University BDT College of Engineering Davanagere- 577004, Karnataka (A Constituent College of VTU, Belgaum) Fax: 08192-233412 http://www.ubdtce.org Off.: 08192-250716: Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 1 VISVESVARAYA TECHNOLOGICAL UNIVERSITY, BELGAUM University BDT College of Engineering, Davangere Mechanical Engineering Department Sub Name: PROJECT MANAGEMENT (18ME745) Dr. S B Mallur, Professor, MED, UBDTCE, Davanagere Module-2 Planning Projects: Defining the project scope, Project scope checklist, Project priorities, Work Breakdown Structure (WBS), Integrating WBS with organisation, coding the WBS for the information system Scheduling Projects: Purpose of a project schedule, historical development, how project schedules are limited and created, develop project schedules, uncertainty in project schedules, Gantt chart. Course Outcomes (CO2): CO2: Understand the work breakdown structure by integrating it with organization. CO3: Understand the scheduling and uncertainty in projects. Course Learning Objectives: 1. To understand how to break down a complex project into manageable segments and use of effective project management tools and techniques to arrive at solution and ensure that the project meets its deliverables and is completed within budget and on schedule. 2. To impart knowledge on various components, phases, and attributes of a project. 3. To prepare students to plan, develop, lead, manage, and successfully implement and deliver projects within their chosen practice area. 4. Planning Projects: PLANNING PROJECTS 1. Defining the project scope, 2. Project scope checklist, 3. Project priorities, 4. Work Breakdown Structure (WBS), 5. Integrating WBS with organisation, 6. Coding the WBS for the information system. Scheduling Projects: 7. Purpose of a project schedule, 8. historical development, 9. how project schedules are limited and created, 10. develop project schedules, 11. uncertainty in project schedules, 12. Gantt chart. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 2 2.0. INTRODUCTION Planning is a large and critical part of project management. Planning may be largely completed before much executing work begins in traditional project management, in a completely iterative fashion using Agile, or somewhere in between in a hybrid environment. Project planning tends to be collaborative with many people involved and integrative in that many factors need to be considered. Planning cover the various aspects of planning in distinct chapters to clarify what needs to be done in each. Scope planning plan the scope by collecting requirements and creating work breakdown structures, Scheduling Projects shows how to create and communicate project schedules. 2.1. DEFINING THE PROJECT SCOPE Define Scope Define scope is the process of translating stakeholder needs and requirements into detailed specifications of the project outcomes and products. Essentially, the project scope statement includes three things regarding the total scope. First, the team needs to determine both what they will deliver to the project stakeholders at the end of the project and what they need to deliver along the way to ensure they will be successful in the end. These are the deliverables—the product scope. For example, if a final project deliverable is a new computer program; intermediate deliverables may include an outline of what will be included and a prototype. Second, the team should decide what work needs to be accomplished to create the deliverables. This is the project work statement—the project scope. Third, the team needs to determine what will limit or influence the project work— such as exclusions, constraints, and assumptions. 2.1a Reasons to Define Scope Scope definition is an important part of project planning because all other planning is based on the project scope. While the requirements collected represent the customers’ statement of what they need, the defined scope is the project team’s response—asking the customer, “If we provide this, will it solve your problem?” It is impossible to estimate how much a project will cost, how many (and what type of) workers will be needed, how long a project will take, what risks are involved, or what quality standards will be invoked without first understanding what work is included in the project. Scope definition also is vital in preventing scope creep. Scope creep happens for two common reasons. First, if the scope is not clearly defined and agreed upon, it is easy to add additional work (scope creep) to the project with or without realizing that more time and resources (additional cost) will be required. Second, sometimes when a project is going as planned, a customer is so excited that he or she asks an innocent-sounding question: “Can the project output also do … ?” The person performing the project work is often flattered and agrees without understanding the implications of making this change. In contemporary business, pleasing the customer is desirable. However, the best time to gain customer understanding is when the project team is defining the scope—not while executing the project scope work. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 3 2.1. PROJECT SCOPE CHECKLIST 2.1b How to Define Scope Scope definition can vary greatly from one project to another. For a small, routine construction project, it may be quite simple to determine what project outputs will be created and what work is involved in creating them. On other projects, such as one large company acquiring another, it may be very difficult to determine the total amount of work that needs to be accomplished. Regardless of how easy or difficult it may be to define scope and despite industry-specific methods that may be helpful in doing so, all project teams need to complete each part of this process. LIST DELIVERABLES AND ACCEPTANCE CRITERIA The first step is to list project deliverables. The requirements elicited from the customer often lead to some of the final deliverables. Project teams need to understand that there are often multiple deliverables. For example, if a project entails constructing a house, the homeowners probably want not only the house but also documentation on systems within it, perhaps an explanation (training) on how to use certain items such as an innovative thermostat, and a warranty procedure. The project team also needs to list intermediate deliverables—those things that need to be developed while making progress to complete the project. Some of these were probably listed in the charter, but others may not yet be identified. Then the project team needs to determine the acceptance criteria for each deliverable. ESTABLISH PROJECT BOUNDARIES The second step in defining scope is to establish the project boundaries. Think of the project boundaries as the side-lines on an athletic field. By understanding what is in play and what is not, athletes know clearly when to play and when to stop. Likewise, project team members need to know which tasks should be executed and which tasks need not be executed. The first part of the boundary definition is to decide which features and work elements are included (in scope) and which are excluded (out of scope). Collectively, clients and end users often request far more features and work than a project is originally planning to deliver or can deliver. Therefore, the team needs to know and decide what is included and what is not. Usually, the sponsor makes decisions regarding larger scope decisions, but the project manager and team still have many detailed scope decisions to make. The second part is to manage expectations regarding any project. The project team members need to understand the constraints imposed on the project. If the work must be delivered by a certain date or if only limited resources are available, the project may be constrained, and the team should be careful to promise only what it can deliver. In planning, people make assumptions about dates, times, and availability of resources; for example, a shipment of required materials will arrive by the date the supplier promised. These assumptions should be stated. If an assumption proves to be false, it frequently increases the project risk and may also limit the project scope. CREATE A SCOPE DESCRIPTION o The final step is to create a scope description. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 4 o This description briefly states the work that needs to be accomplished to create the project deliverables. o A project scope statement guides the project team during subsequent planning and execution. o For some very small projects, a well-developed project charter could also serve as a scope statement. o On most projects, a scope statement needs to be developed prior to development of the WBS. An example scope statement for the Alternative Breaks project is shown in Exhibit 7.4. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 5 1.3 PROJECT PRIORITIES 7-3c Defining Scope in Agile Projects Agile strives to use smaller iterations to get feedback because understanding the desired outcome tends to evolve as the customers see the work being done by the team. Humans tend to be poor estimators, and the more unique the project, where volumes of reliable data are not available for making estimates, the harder it is to be predictable. In construction, for example, there are software packages that help estimate how long it will take to hang drywall or run electrical wire. However, in more creative endeavours like creating software, there is little documented knowledge of how long a project will take. This is where the adage to under promise and over deliver becomes words to the wise. With Agile projects, the project manager is challenged with conflicting aspirations and actions between finalizing the scope specifications and maintaining flexibility to modify them to meet changing business needs or adding new requirements of stakeholders. Agile scope definition is a complex process as the scope is not clear to either the project team or the client. The project manager and the project team must demonstrate greater adaptability to frequently changing scope and employ iterative or phased planning of scope. Consequently, Agile projects present more flexibility. On Agile projects, the scope definition starts with large chunks of work; for example, we want to be able to take credit card payments on a website. This large feature, and there will be many of them for a fully functioning website, will be broken down into stories and prioritized later. The team creates “personas,” which are fictional people who represent user types. These personas provide information about what they will do with the project deliverables and how they will benefit. These user stories define scope and functionality. Acceptance tests will also be agreed upon during the scope definition phase by describing the way project deliverables will be tested and how they should prove workable. At the project outset, the overall scope is only defined at a high level, and a backlog of possible work is identified. The customer representative (sometimes called the owner) prioritizes the scope based upon business need, value, cost, and risk. The team then commits to the amount of work they can perform in the first iteration. As the project progresses, the scope is described more specifically and is documented more closely. The level of documentation is less important and takes a secondary role. The primary measure of success in an Agile project is working software. The Agile method for defining scope is primarily applicable when the project scope is unclear or poorly defined. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 6 2.4. WORK BREAKDOWN STRUCTURE (WBS), After scope definition is complete, the project manager will have a greater clarity about project work and milestones as compared to the high-level understanding of the project when the project charter is defined (discussed in Chapter 3). The milestones defined in the project charter are not necessarily accurate due to lack of complete understanding of the total project work. It is important to note that the project charter must be seen as an authorization document with accuracy of estimates (cost and time) in the range of + 50 percent. With the definition of scope, more details about the project are available to develop WBS and new milestones. A detailed understanding of the project scope and work to be performed must be simplified for execution, and it is essential to divide the total work into smaller and manageable elements. A tool that is used on virtually all traditional projects is the WBS. To understand this tool, we will first define it, tell why it is important, show several common formats to use when constructing one, and then demonstrate the steps required to construct a WBS. 2.5. INTEGRATING WBS WITH ORGANISATION, 7-4a What Is the WBS? The WBS is, or should be, a uniform, consistent, and logical method for dividing the project into small, manageable components to manage project scope and for planning, estimating, and monitoring (Rad and Anantatmula, 2009). It is a project planning tool that is defined as the concept of hierarchical decomposition for transforming the project scope into deliverable work elements at the highest level. Its composition continues until it facilitates managing these work elements effectively. The WBS helps develop an optimum project schedule and cost estimates at the work element level. The WBS is a tool that project teams use to progressively divide the deliverables of a project into smaller and smaller pieces. The project team members start by identifying the major deliverables to be created and by continuously asking: “What are the components of this deliverable?” The WBS is not a list of work activities, an organizational chart, or a schedule. The WBS is a framework that is used as a basis for further planning, execution, and control. The WBS also is an important project planning tool that uses the concept of hierarchical decomposition for transforming the scope into deliverable work elements. Typically, the WBS is created after the scope is defined on large projects. In contemporary project management, particularly on small and middle-sized projects, the WBS may be created concurrently with the scope statement. The WBS is normally developed by listing deliverables—major deliverables first and then progressively smaller ones until the team feels that every deliverable has been identified. Managers of smaller projects sometimes perform another process concurrent with WBS development: defining activities and milestones. Define activity is a project planning process that identifies and determines specific actions to develop and deliver the project outcomes, such as products, services, or results. Many people find that work activities can be easily defined once the various deliverables are itemized. To clearly distinguish between the work processes of WBS development and activity development, WBS development is covered in this chapter, and activity development is covered as part of project scheduling in the next chapter. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 7 Developing the WBS and defining the activities form an example of how two separate work processes are sometimes performed together (especially on small or simple projects) and sometimes separately (especially on large or complex projects). 7-4b Why Use a WBS? The reasons for using a WBS are many. Planning projects requires discipline and visibility. A properly developed WBS encourages a systematic planning process, reduces the possibility of omission of key project elements, and simplifies the project by dividing it into manageable units (Rad and Anantatmula, 2009). A WBS can be used as a pictorial representation of project deliverables. By using a systematic process for creating a WBS, project team members can ensure that they include all deliverables that are required to be created. Deliverables that are not planned, but need to be, often add to schedule delays and budget overruns. The WBS provides a framework of common reference for all project elements, for specific tasks within the project, and ultimately for better schedules and better estimates. It is the basis for all subsequent planning of such important functions as schedule, resources, cost, quality, and risk. It also serves as an outline for integrating all these planning elements. The WBS is easily modified and thus can handle the changes that often occur on projects. The impact of these changes is then shown in the schedule, budget, and other control documents. If a problem occurs during project execution, the WBS is helpful in understanding exactly where and why the problem occurred. This helps to diagnose problems, manage the quality of the project deliverables, and keep all the other facets of the project on schedule while the isolated problem is fixed. The WBS is also helpful in project communications. Typically, many stakeholders contribute to developing the WBS, and this effort helps them understand the project. Further, it clearly shows the importance of each work element, why it is required, and how it is integrated with project deliverables. In a nutshell, the WBS presents the entire scope of the project and serves as an excellent communication and integration tool. Software such as Microsoft Project enables a WBS to be shown in its entirety to people who need to understand the details, but it also allows project details to be hidden so that others can see the big picture. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 8 7-4c WBS Formats There are various formats for constructing a WBS, but they all have the same purpose. The overall project is considered the first level, as shown in Exhibit 7.5. In this example, a WBS for a house is presented in the indented outline format. The second level in this example depicts major deliverables from the house project, namely the house in its framed state, when it is wired, and when it is dry walled. This second level is indented one tab. Note that a section is included for the work of planning and managing the project. A WBS usually has one or more intermediate levels, which generally represent items that need to be created to produce the final deliverables, such as drafts, prototypes, and designs. These are frequently called interim deliverables. All levels of the WBS with at least one level below are considered summary levels. The completion of summary-level elements is based upon completion of all levels underneath. For example, in Exhibit 7.5, the house would not be framed until the framing contractor, wood, and assembled frame interim deliverables were complete. Exhibit 7.5 used the indented outline format for the WBS method, but other methods are sometimes used. Another method is the hierarchical or “org chart” (short for organizational chart, which it resembles) method. A third method is called free format because the facilitator is free to draw it in any manner. The same house project shown in Exhibit 7.5 in indented outline format is shown in Exhibit 7.6 in org chart format and in Exhibit 7.7 in free format. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 9 A marker board or flip chart can be used to develop all these methods and also offers plenty of room to add additional elements as the scope is revised. The WBS method using indented outlines can easily be imported into MS Project. Teams using the org chart or free format methods for WBS generally translate them into the indented outline format for input into software. 7-4d Work Packages The house example above has only three levels as follows: Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 10 1. The first level, or project title level 2. One intermediate level, or summary level 3. The lowest level, or work package level This process of dividing the deliverable items is continued until the project has been divided into manageable, discrete, and identifiable items requiring simple tasks to complete. A practical rule is to keep dividing the project until it no longer can be divided realistically. This point may differ from project to project. The lowest level is known as a work package. In a WBS, an element at the lowest level is called a work package, which is usually the work component at the lowest level of the WBS for which cost and duration can be estimated and managed. Work packages are the basis for all subsequent planning and control activities. Exhibit 7.8 shows a WBS in org chart format with work packages in solid boxes. One frequently asked question when breaking the deliverables into work packages is how small is small enough. The answer is, “It depends.” In Exhibit 7.8, work packages occur at levels 3, 4, and 5. The work package is the point from which: Work activities are defined The schedule is formed Resources are assigned Many of the control features are developed Work packages need to be detailed enough to facilitate further planning and control. If they are too detailed, the burden of tracking increases. The project manager needs to feel confident that the work to create the work package can be assigned to one person who can estimate the schedule and cost and can be held responsible for its completion. However, the work package may require multiple resources (including more than one person) to complete it. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 11 If the work is composed of a single deliverable that is well understood, it is clear how the deliverable will be judged for quality and completeness, and the assigned workers have proven credentials, then the work package may not have to be too detailed. On the other hand, if the deliverable and/or how it will be judged for its completion are poorly understood, and the assigned worker or workers are yet to be proven reliable, a more detailed work package may make sense. For ease of communication and comprehension, work packages and other components of a WBS are usually stated in very few words; one should avoid verbs and instead use adjectives to describe WBS elements at all levels. A WBS component is a work element that is part of the WBS at any level. The phrases or words to describe WBS elements should not be repeated. However, because the names are typically short, there is still the potential to get confused by exactly what is included in a work package or WBS component. Therefore, WBS components are often defined further using a WBS dictionary. A WBS dictionary is a document that provides detailed information about each work package by providing details about the associated deliverable, activity, scheduling information, predecessor, successor, person responsible for it, resources required, and associated risks. An example of a WBS dictionary entry with detailed information for a work package is shown in Exhibit 7.9. Note that some of this additional information such as activities, resource assignments, effort, and cost will be described in subsequent chapters. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 12 7-4e How to Construct a WBS The information for a WBS is drawn primarily from the project objectives statement, and from historical files containing planning information of past projects. When a project team needs to construct a WBS, it needs to include in its planning team a subject matter expert (SME) who understands how each segment of the work will be accomplished. Teams approach this task in two ways. The first approach is that teams include only the core team members and plan the WBS as in as much detail as they can. At that point, different core team members are assigned to identify and seek the SMEs to plan the remaining details. In the second approach, teams invite the SMEs to the WBS planning meeting right from the start and utilize their input throughout the WBS development. Often, the choice of how to include SMEs is determined by the size and complexity of the project and by the cultural norms of the company. The planning team uses a top-down approach in creating the WBS. This is easy to start when the type of project is familiar and at least some members of the planning team are likely to understand the general flow of work. If the project is similar to past projects, either a template or the WBS from a previous project can be used as a starting point. Then, using this template or WBS, the project team would identify additional project needs for inclusion and irrelevant elements of the previous project for deletion. Templates and previous examples can save teams a great deal of time, but caution must be exercised because each project is unique. Sometimes, however, a project is so unique and different from previous projects that the team finds it useful to jump-start the WBS construction by brainstorming to identify a list of project deliverables to help to understand and develop the overall structure of the project WBS. However, once the overall structure is understood, the team proceeds with the typical top-down approach for the remainder of the WBS development. IDENTIFY MAJOR DELIVERABLES The team defines the project deliverables by reviewing the project planning completed thus far. The team members review the projectcharter, requirements traceability matrix, and scope statement to define the project’s major deliverables. Remember that while many projects may have a primary deliverable such as a house, almost all projects have additional deliverables such as documentation and customer support. These could include training, service, or other means of helping the customer use the project’s products effectively. One of the first decisions is how to organize the second level of the WBS. (Remember, the first level is the overall project.) As defined earlier, the WBS is, or should be, a uniform, consistent, and logical method for dividing the project into small manageable components. WBS development is viewed as the process of grouping all project elements into several major categories, normally referred to as level one; each of these categories will itself contain several subcategories, normally referred to as level two. Alternately, and more accurately, development of a WBS involves dividing the project into many parts that, when combined, would constitute the project deliverable. This process of dividing the deliverable items is continued until the project has been divided into manageable, discrete, and identifiable items requiring simple tasks to complete. Three methods are shown in Exhibit 7.10. One method is by project phase, with thesecond level being the signing of a contract, building the foundation, and framing the house. Alternatively, the second level can be organized by design components (deliverable-basis), such as kitchen, bedrooms, and bathrooms. Finally, the second level can be organized by work function (resourcebasis). A house project organized this way might have carpentry, plumbing, and electrical as second-level elements. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 13 Organizing by project phase (schedule-basis) has the advantage of using the milestones in the project charter as an organizing principle. It also facilitates rolling wave planning. Rolling wave planning is a planning technique of identifying and defining the work to be completely accomplished in the near term and planning the future work at a higher level. In other words, once the near-term work is complete, the next phase of the project is planned in detail. In essence, it is an iterative process. If the planners of the project in Exhibit 7.10 used rolling wave planning, the work associated with the contract would be planned in detail immediately, and work for the foundation and framing might only be planned at a high level at first with more detail worked out as the project team worked on the contract. Rolling wave planning allows a team to get a quick start on a project—especially one in which details of later phases may depend on the results of work performed during early phases. Rolling wave planning helps a project team avoid either of two extremes. One extreme is to never start doing anything because the plan is not yet complete, which is also known as analysis paralysis. The opposite extreme is not planning at all because of fear that planning will take too long; this is known as ready, fire, aim. Organizing by either phase or design components/deliverables helps to focus communications on project deliverables and their interactions. Organizing by work function allows the functions to focus on their specific activities, but often does not promote cross-functional discussion. Handoffs of work from one group to another are not always as smooth. Therefore, if a project manager decides to organize the WBS by work function, extra care needs to be taken in establishing interfunctional communications. Of the three approaches, the most generally useful, and the most difficult, method for developing a WBS is to use design components/deliverables as the basis of the breakdown of the project. It is also known as a deliverable-based WBS. The deliverable-basis, or design-basis, is developed by looking at the project from the client’s perspective and not from the project execution perspective. Further, it makes sense to all key stakeholders and facilitates easy communication. In this deliverable-basis or design-basis mode, the project is divided into individual distinct components that ultimately comprise the project, such as hardware, software, physical structure, concrete foundation, or steel roof. This deliverable-based WBS division can be based on product, function, or physical location of the deliverable (Rad and Anantatmula, 2009). The deliverable basis of WBS development is far superior to the other bases because it is customer focused and easy to facilitate during project execution. Note that one additional second-level item is shown on all three methods—that of project management. This includes the work of planning and managing the effort and includes preparing documents, attending meetings, integrating diverse portions of the project, handling communications, and so on. Since much of the work involved in project management is the level of effort, this section may not be decomposed. If Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 14 the work of managing the project is left out, it is more likely that the project will not be completed on time and within the budget. It is very important to understand that, in many cases, the client is not concerned about the intricacies of project execution or project management activities. From a client’s perspective, the focus is only on what is delivered as the project outcome. So, project management is not typically included in a deliverablebased WBS. However, there are exceptions to this rule. For large and mega projects, programs, and federal government contracts, it is possible that the client is interested in project management activities and project progress reports. In such cases, including project management in the WBS may be sensible, even in a deliverable-based WBS. DECOMPOSE DELIVERABLES Once the major deliverables have been defined, it is time to break them into smaller deliverables or components. This is called decomposition, a method of dividing the project scope into many parts that, when combined, would constitute the project deliverable. It is the process of breaking down the project scope until it has been divided into manageable, discrete, and identifiable components requiring simple tasks to complete. The team members can use the top-down approach, asking what all the components of each major deliverable are. Alternatively, the team members may use a bottom-up approach by brainstorming a list of both interim and final deliverables that they feel need to be created. Each deliverable can be written on an individual Post-it Note. These deliverables are then assembled on a large work space where team members group the smaller deliverables either under the major deliverables that have been previously identified or into additional related groups that are then headed by major deliverables. CONTINUE UNTIL DELIVERABLES ARE THE RIGHT SIZE At this point, the WBS has been formed and can be reviewed for completeness. Once it is determined to be complete, the team can ask if the deliverables at the lowest level need to be divided further for planning and control as described above. For example, in the new car development project in Exhibit 7.11, level-two components, such as product design, are at too high of a level to plan and control. Therefore, at least one more level should be included. If some of those components, such as Product Goals, are still too broad, yet another level would need to be developed. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 15 REVIEW At this point, several things should be considered to ensure that the WBS is structured properly. One consideration with WBS construction is the parent-child concept. The higher level is considered the parent and the lower-level elements are considered children. For example, in Exhibits 7.5, through 7.7, “Framed House” is a parent to the children: “framing contractor,” “wood,” and “assembled frame.” “Framed House,” in turn, is a child to “HOUSE.” The framed house component is not complete until all of its children components are complete. The team asks if, once these elements are complete, the framing is complete. In an effort to simplify the WBS, where only one child element for a parent exists, you would not break it down. In fact, a good rule of thumb is to have somewhere between three and nine child elements for each parent. The fewer levels a WBS has, the easier it is to understand. To avoid confusion, each component in the WBS needs to have a unique name. Therefore, two similar components may be draft report” and final report,” instead of merely calling each “report.” The team also assigns a unique number to each component. In one common numbering system, the number for a child item starts with the number assigned to its parent and adds a digit. An example of a WBS with components numbered is shown in Exhibit 7.12. Different organizations sometimes develop their own unique variations of project planning and control techniques. Exhibit 7.13 describes the manner in which a large, complex organization (the U.S. Central Intelligence Agency) combines stakeholder analysis with WBS. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 16 Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 17 1.6. CODING THE WBS FOR THE INFORMATION SYSTEM. 7-6 Using MS Project for Work Breakdown Structures (WBS) As you have likely realized, the WBS is one of the most important and powerful project planning tools available to the project manager. It is one of the key building blocks on which all further project activities are based. By creating a WBS in MS Project, the project manager lays the foundation for automating many other planning and communication tools the software has to offer. Complete the following steps to set up a WBS in MS Project. 7-6a Set Up a WBS in MS Project Setting up a WBS in MS Project has five basic steps: 1. Understand the WBS definitions and displays. 2. Enter project deliverable and work package elements. 3. Create the outline of your WBS. 4. Insert a WBS code identification column. 5. Hide (or show) the desired amount of detail in the WBS. STEP 1: UNDERSTAND THE WBS DEFINITIONS AND DISPLAYS MS Project refers to WBS task elements as summary tasks, tasks, and subtasks and displays them in an indented outline table format: Summary tasks are the main or interim WBS deliverables and are displayed in bold font. Subtasks are all the tasks that make up the deliverables (work packages) and are indented below their parent summary task. WBS tasks can also be viewed in Gantt views with different graphical shapes: Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 18 For instance, a summary task might also be a milestone that you would want to denote graphically in your Gantt chart (typically a diamond in MS Project). You will see these graphical representations in future tutorials. Exhibit 7.15 shows a Gantt table view of a WBS in MS Project. Note that MS Project codes the overall project (Suburban Park Homes) as level zero, not level one. The task durations have not been defined at this point and show “1 day?” for all tasks. If you are following along in MS Project, you will notice “Start” and “Finish” columns to the right of the Duration column that also have not been defined. The Start and Finish columns are not shown in the following exhibits for clarity’s sake. STEP 2: ENTER WBS ELEMENTS (TASKS) In Exhibit 7.16, you will see WBS task elements added to the existing Suburban Park Homes project milestone list (from Chapter 3). In this WBS example, the existing milestones will double as the main deliverables (summary tasks). Enter these WBS elements to your project as follows: 1. In the Task Name field, select the row below where you want the new row to be (after making your selection, holding the SHIFT key and selecting a different row will highlight all rows between the two selections and result in that number of blank rows being inserted in the next step). 2. Click Task Tab>>Insert Group>>Task. a. Alternatively, you can Right-Click>>Insert Task. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 19 3. You will see a new row (or rows if you added multiple) with the words <New Task> in the Task Name field. Click on <New Task> and enter the name of the desired WBS element (you may have to delete <New Task> before typing in your new task name). 4. Repeat these processes as needed to enter additional tasks between the Suburban Park Homes milestones until your WBS looks like Exhibit 7.16. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 20 STEP 3: CREATE THE OUTLINE FOR YOUR WBS You now need to set up the outline structure of the WBS to show summary tasks and subtasks (deliverables, interim deliverables, and work packages). To do this, use the Indent and Outdent controls shown in Exhibit 7.17 (Task Tab>>Schedule Group>>Green Arrows). 1. Click the Task Name field of the row to be indented. 2. Task Tab>>Schedule Group>>Indent Task (right Green Arrow). a. The task element above the indented task(s) becomes a summary row as indicated by a bold font. b. Indenting a summary row will also indent its lower-level items. c. Multiple rows under a summary row can be indented (or out dented) at the same time by Shift-Click selecting all of them before clicking the Indent control. 3. Clicking Task Tab>>Schedule Group>>Outdent Task (left Green Arrow) will similarly decrease indentation of the selected row(s) or summary task. 4. Indent to create deliverables, interim deliverables, and work packages until your WBS resembles the outline shown in Exhibit 7.15. STEP 4: INSERT WBS CODE IDENTIFIER COLUMN MS Project can automatically assign identifier codes to all your WBS tasks. WBS codes allow the Project Team to easily categorize and communicate information about project tasks in the WBS. In this example, WBS codes will be assigned in a new column to the left of the Task Name column: 1. Right-click the Task Name column heading and click Insert Column. 2. A drop-down list appears in a new column. 3. From the drop-down list, choose WBS, as shown in Exhibit 7.18. a. A WBS code column is now in place. b. Resize the column to conserve space. 4. Right-click the Task Mode column heading and click Hide Column. 5. Your result should look like Exhibit 7.19. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 21 Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 22 STEP 5: HIDE (OR SHOW) SUBTASKS DETAIL Some stakeholders will not want or need to see the lower levels of WBS detail (particularly in large, complex projects with lots of WBS detail). You can easily “roll-up” (or “un-roll”) subtasks underneath their parent summary task to hide (or show) detail. To display the appropriate level of detail, complete one or both of the following steps: Click the tiny triangle before the task name of any summary task to hide underlying detail (all details will be “rolled-up” under the summary task). Click the tiny triangle again to show underlying detail (all details “un-roll” under the summary task and are again visible). In Exhibit 7.20, the underlying detail for the “Land preparation, landscape, and foundation” deliverable and the “Framing” interim deliverable summaries has been hidden. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 23 PMP/CAPM Study Ideas It has been said that the discipline of project management lends structure to common sense. Nowhere is this more true than with scope planning. If you can remember to conduct your planning with the end goal in mind, many of the processes and activities in this chapter will seem intuitive. Another way of saying his is that you will work backward from the outcome you desire (a successful product and/or project). Begin by identifying what it would take for your product—and your project—to be successful. Be sure to include your customers and end users in making this determination (“Collect requirements”), as well as subject matter experts who can speak to the technical expertise needed and the feasibility of the project plan. Identify the final deliverables, as well as any important interim deliverables. Discussing these deliverables and what it will take to produce them is a good chance for the team to further “define scope,” or determine what is included—and not included—in your project. Once you have the main deliverables, you will use the process of decomposition to break them down into smaller pieces, thus creating a Work Breakdown Structure. It is important to remember that the WBS deals with things, not activities (though on a very small project, these may be planned concurrently). The lowest level of the WBS is the “work package,” which is small enough that it can be easily planned and overseen by one person. To be sure, this is an oversimplification of everything that goes into planning scope, and you will need to be fluent in all the activities and processes in this chapter in order to pass a CAPM or PMP test. But it can be helpful to remember that there is an organizing structure to all this work—one that begins with the end result in mind. Summary Once a project is formally approved by a sponsor ratifying its charter, it is time for detailed planning. While project planning is iterative, normally the first steps are to identify stakeholders, plan communications, and determine what will be created on the project. Project teams start this process by asking customers what endof- project deliverables they want. From the customers’ response, the planning team can determine both what interim deliverables need to be created and what work needs to be performed to create all of the deliverables. Just as important as determining what will be produced during the project is determining what will not be produced. These boundaries of what will and will not be included constitute the project’s scope Once the scope is defined, it can be organized into a work breakdown structure (WBS). A WBS is used to progressively decompose the project into smaller and smaller pieces until each can be assigned to one person for planning and control. The WBS serves as a basis for determining the project schedule, budget, personnel assignments, quality requirements, and risks. As those other functions are planned, items are commonly identified that should be added to the WBS. Some teams create their WBS by hand using the org chart or free format methods, while others directly type their WBS into project scheduling software such as Microsoft Project. Project Management-18ME745 (PM) Note by – Dr. S B MALLUR, Professor, UBDTCE, Davanagere 24