Project Management Basics - Module 3 PDF

Summary

This document is a module on project management basics, focusing on project initiation and scope definition. It explains the importance of project scope, provides a checklist for defining project scope, and discusses project charters and scope creep.

Full Transcript

PROJECT MANAGEMENT BASICS MODULE 3 Students are encouraged to turn on their cameras during the VIRTUAL class discussion. CLASSROOM Be participative during discussions. Let your voice and thoughts be heard. RULES Assignments should be submitted within t...

PROJECT MANAGEMENT BASICS MODULE 3 Students are encouraged to turn on their cameras during the VIRTUAL class discussion. CLASSROOM Be participative during discussions. Let your voice and thoughts be heard. RULES Assignments should be submitted within the set deadline Recitations will be done during class discussions for Synchronous students and during weekly consultations for Independent Study students. Quizzes should be answered within the set deadline and with the time limits. Midterm and Final Exams should be answered within 24 hours with a time limit of 3 hours for a 50-item exam. Late submissions will be allowed up to 24 or 48 hours after the original deadline. No further extensions. Students should communicate early if he/she will not be able to participate during a class discussion or any class activities. When stepping out from class, drop a message on our chatbox so when called during recitation, professor would know. 2 Module Overview Discuss and understand the project life cycle: Conception or project initiation Planning, design, and scheduling 3 CONCEPTION OR PROJECT INITIATION 4 CONCEPTION OR PROJECT INITIATION Defining the project scope sets the stage for developing a project plan. Project scope is a definition of the end result or mission of your project—a product or service for your client/customer. The primary purpose is to define as clearly as possible the deliverable(s) for the end user and to focus project plans. The scope should be developed under the direction of the project manager, customer, and other significant stakeholders. The project manager is responsible for seeing that there is agreement with the owner on project objectives, deliverables at each stage of the project, technical requirements, and so forth. Your project scope definition is a document that will be published and used by the project owner and project participants for planning and measuring project success. Scope describes what you expect to deliver to your customer when the project is complete. Your project scope should define the results to be achieved in specific, tangible, and measurable terms. 5 CONCEPTION OR PROJECT INITIATION Clearly, project scope is the keystone interlocking all elements of a project plan. To ensure that scope definition is complete, you may wish to use the following checklist: PROJECT SCOPE CHECKLIST Scope definition should be as brief as possible but complete; one or two pages are typical for small projects.  Project Objective  Deliverables The project scope checklist in Step 1 is generic. Different industries and companies will develop unique checklists and templates to fit their  Milestones needs and specific kinds of projects. A few companies engaged in  Technical Requirements contracted work refer to scope statements as “statements of work” (SOW).  Limits and Exclusions  Reviews with Customer Project Charter Scope Creep 6 CONCEPTION OR PROJECT INITIATION Project Charter A project charter refers to a document that authorizes the project manager to initiate and lead the project. This document is issued by upper management and provides the project manager with written authority to use organizational resources for project activities. Often the charter will include a brief scope description as well as such items as risk limits, business case, spending limits, and even team composition. Scope Creep the tendency for the project scope to expand over time—usually by changing requirements, specifications, and priorities. Scope creep can be reduced by carefully writing your scope statement. 7 PROJECT PRIORITIES 8 PROJECT PRIORITIES One of the primary jobs of a project manager is to manage the trade-offs among time, cost, and performance. To do so, project managers must define and understand the nature of the priorities of the project. They need to have a candid discussion with the project customer and upper management to establish the relative importance of each criterion. One technique found in practice that is useful for this purpose is completing a priority matrix for the project to identify which criterion is constrained, which should be enhanced, and which can be accepted 9 PROJECT PRIORITIES Priorities vary from project to project. Some would argue that all three criteria are always constrained and that good project managers should seek to optimize each criterion. If everything goes well on a project and no major problems or setbacks are encountered, their argument may be valid. However, this situation is rare, and project managers are often forced to make tough decisions that benefit one criterion while compromising the other two. The purpose of this exercise is to define and agree on what the priorities and constraints of the project are so that when “push comes to shove,” the right decisions can be made. Developing a priority matrix for a project before the project begins is a useful exercise. It provides a forum for clearly establishing priorities with customers and top management so as to create shared expectations and avoid misunderstandings. The priority information is essential to the planning process, where adjustments can be made in the scope, schedule, and budget allocation. Finally, the matrix is useful midway in the project for approaching a problem that must be solved. 10 WORK BREAKDOWN STRUCTURE 11 WORK BREAKDOWN STRUCTURE Once the scope and deliverables have been identified, the work of the project can be successively subdivided into smaller and smaller work elements. A work breakdown structure (WBS) is an outline of the project with different levels of detail. Major project work deliverables/systems are identified first; then the subdeliverables necessary to accomplish the larger deliverables are defined. The process is repeated until the subdeliverable detail is small enough to be manageable and where one person can be responsible. This subdeliverable is further divided into work packages. Because the lowest subdeliverable usually includes several work packages, the work packages are grouped by type of work—for example, design and testing. These groupings within a subdeliverable are called cost accounts. This grouping facilitates a system for monitoring project progress by work, cost, and responsibility. 12 WORK BREAKDOWN STRUCTURE Each item in the WBS needs a time and cost estimate. With this information it is possible to plan, schedule, and budget your project. The WBS also serves as a framework for tracking cost and work performance. As the WBS is developed, organizational units and individuals are assigned responsibility for executing work packages. This integrates the work and the organization. In practice, this process is sometimes called the organization breakdown structure (OBS). Use of the WBS provides the opportunity to “roll up” (sum) the budget and actual costs of the smaller work packages into larger work elements so that performance can be measured by organizational units and work accomplishment. 13 WORK BREAKDOWN STRUCTURE 14 WORK BREAKDOWN STRUCTURE The lowest level of the WBS is called a work package. Work packages are short duration tasks that have a definite start and stop point, consume resources, and represent cost. Each work package is a control point. A work package manager is responsible for seeing that the package is completed on time, within budget, and according to technical specifications. Practice suggests a work package should not exceed 10 workdays or one reporting period. If a work package has a duration exceeding 10 days, check or monitoring points should be established within the duration, say, every three to five days, so progress and problems can be identified before too much time has passed. Each work package of the WBS should be as independent of other packages of the project as possible. No work package is described in more than one subdeliverable of the WBS. 15 ORGANIZATION BREAKDOWN STRUCTURE The WBS is used to link the organizational units responsible for performing the work. In practice, the outcome of this process is the organization breakdown structure (OBS). The OBS depicts how the firm has organized to discharge work responsibility. The purposes of the OBS are to provide a framework to summarize organization unit work performance, identify organization units responsible for work packages, and tie the organizational unit to cost control accounts. The OBS defines the organization subdeliverables in a hierarchical pattern in successively smaller and smaller units. Frequently, the traditional organization structure can be used. Even if the project is completely performed by a team, it is necessary to break down the team structure for assigning responsibility for budgets, time, and technical performance. The WBS is best suited for design and build projects that have tangible outcomes such as an offshore mining facility or a new car prototype. The project can be decomposed or broken down into major deliverables, subdeliverables, further subdeliverables, and ultimately to work packages. It is more difficult to apply WBS to less tangible, process-oriented projects in which the final outcome is a product of a series of steps or phases. 16 ORGANIZATION BREAKDOWN STRUCTURE 17 PROCESS BREAKDOWN STRUCTURE 18 PROCESS BREAKDOWN STRUCTURE Information systems projects typically fall in this category— for example, creating an extranet website or an internal software database system. Process projects are driven by performance requirements, not by plans/blueprints. Some practitioners choose to utilize what we refer to as a process breakdown structure (PBS) instead of the classic WBS. An example of a PBS for a software development project is shown on the next slide. Instead of being organized around deliverables, the project is organized around phases. Each of the five major phases can be broken down into more specific activities until a sufficient level of detail is achieved to communicate what needs to be done to complete that phase. People can be assigned to specific activities, and a complementary OBS can be created just as is done for the WBS. Deliverables are not ignored but are defined as outputs required to move to the next phase. The software industry often refers to PBS as the “waterfall method” since progress flows downward through each phase. 19 PROCESS BREAKDOWN STRUCTURE Checklists vary depending upon the project and activities involved but typically include the following details: Deliverables needed to exit a phase and begin a new one. Quality checkpoints to ensure that deliverables are complete and accurate. Sign-offs by all responsible stakeholders to indicate that the phase has been successfully completed and that the project should move on to the next phase. As long as exit requirements are firmly established and deliverables for each phase are well defined, the PBS provides a suitable alternative to the standard WBS for projects that involve extensive development work. 20 PROCESS BREAKDOWN STRUCTURE Checklists that contain the phase exit requirements are developed to manage project progress. These checklists provide the means to support phase walk-throughs and reviews. Checklists vary depending upon the project and activities involved but typically include the following details: Deliverables needed to exit a phase and begin a new one. Quality checkpoints to ensure that deliverables are complete and accurate. Sign-offs by all responsible stakeholders to indicate that the phase has been successfully completed and that the project should move on to the next phase. As long as exit requirements are firmly established and deliverables for each phase are well defined, the PBS provides a suitable alternative to the standard WBS for projects that involve extensive development work. 21 RESPONSIBILITY MATRICES 22 RESPONSIBILITY MATRICES The RM (sometimes called a linear responsibility chart) summarizes the tasks to be accomplished and who is responsible for what on a project. In its simplest form an RM consists of a chart listing all the project activities and the participants responsible for each activity. 23 RESPONSIBILITY MATRICES Responsibility matrices provide a means for all participants in a project to view their responsibilities and agree on their assignments. They also help clarify the extent or type of authority exercised by each participant in performing an activity in which two or more parties have overlapping involvement. By using an RM and by defining authority, responsibility, and communications within its framework, the relationship between different organizational units and the work content of the project is made clear. 24 PROJECT COMMUNICATION PLAN 25 PROJECT COMMUNICATION PLAN Communication is a key component in coordinating and tracking project schedules, issues, and action items. The plan maps out the flow of information to different stakeholders and becomes an integral part of the overall project plan. The purpose of a project communication plan is to express what, who, how, and when information will be transmitted to project stakeholders so schedules, issues, and action items can be tracked. Project communication plans address the following core questions: What information needs to be collected and when? Who will receive the information? What methods will be used to gather and store information? What are the limits, if any, on who has access to certain kinds of information? When will the information be communicated? How will it be communicated? 26 PROJECT COMMUNICATION PLAN Developing a communication plan that answers these questions usually entails the following basic steps: Stakeholder analysis Information needs Sources of information Dissemination modes Responsibility and timing 27 PROJECT COMMUNICATION PLAN The advantage of establishing a communication plan is that instead of responding to information requests, you are controlling the flow of information. This reduces confusion and unnecessary interruptions, and it can provide project managers greater autonomy. The importance of establishing up-front a plan for communicating important project information cannot be overstated. Many of the problems that plague a project can be traced back to insufficient time devoted to establishing a well-grounded internal communication plan. 28 QUESTIONS? 29 THANK YOU! See you on our next class 30

Use Quizgecko on...
Browser
Browser