Chapter 3: The Project Plan

1. Chapter 3: The Project Plan ISE 443 / ETM 543 Fall 2013

2. Recall the essentials of PM

3. The project plan has 7 essential elements: • Needs, goals, objectives, and requirements • Task statements, a statement of work (SOW), and a work breakdown structure (WBS) • The technical approach to the project • A project schedule • Organization, staffing, and a task responsibility matrix (TRM) • The project budget • Risk analysis

4. What is the project plan used for? TABLE 1.1 • To allow all project team members, including newly assigned personnel, to understand the essentials of the project • To provide corporate management, to whom the project reports, with an understanding of the project • To convey to the customer the project essentials, as perceived and formulated by the project team • To form the basis for a proposal to the customer, where such a proposal is called for • etc. The Plan is updated periodically (at least quarterly) to ensure it remains useful for all of these.

5. The plan starts with an explicit statement of what is required ... FIGURE 1.2 • These come from the customer, and are restated in the plan • Needs • Identify that part of the overall mission of the organization that drive the project • Example • “Meet the transportation needs of the city of Macon through 2060.” • “Reduce greenhouse gas emissions by 50%.” • Goals and Objectives • Broad goal statements, e.g. “Increased efficiency” • Specific, measurable objectives that will achieve the goal, e.g. “Average trip time < 15 minutes.” • See Table 3.1, pg. 74 for more examples • Requirements • More on this later ...

6. YOUR TURN... • This is part of your first project assignment. • In your group: • Read through the project assignment • Identify and WRITE DOWN the statement of need • Identify and LIST the project goals • For each goal, LIST the associated objectives

7. There are 2 types of Requirements • Requirements to be fulfilled by the project (project requirements) • For example, if the project is to design (but not build) the city’s transportation system, one requirement might be: “The contractor shall identify specific vehicle types and numbers to meet transportation fleet requirements.” • Requirements of the “system” that the project addresses (system requirements) • For example, a requirement for the final system might be: “Total fuel costs for the system shall not exceed 15% of the total budget.” The PM’s job is to be aware of both types of requirements, focus on the project requirements, and ensure that the system requirements are brought forward (usually as a reference).

8. To achieve project requirements, a number of subordinate requirements will be identified • These may be described as • minimum position qualification requirements • estimated staffing requirements • special contract requirements, such as • printing and duplicating • internal documentation requirements • contract office requirements • These requirements are listed in an appendix or cited by reference

9. YOUR TURN... • This is part of your first project assignment. • In your group: • Read through the project assignment • Identify and WRITE DOWN the requirements stated in the project assignment • Combine these requirements with the statement of need, goals, and objectives you developed earlier. • Identify and justify a number of subordinate project requirements. Keep these requirements as a separate appendix.

10. The tasks to be accomplished are defined in the Statement of Work (SOW) • Project Scope • A definition of the end result or mission of the project—a product or service for the client/customer—in specific, tangible, and measurable terms. • Purpose of the SOW • To clearly define the deliverable(s) for the end user. • To focus the project on successful completion of its goals. • To be used by the project owner and participants as a planning tool and for measuring project success. • Task statements are drawn directly from the SOW • May be organized into task areas • See, for example, exhibits 3.4 – 3.6, pp. 78-80

11. YOUR TURN... • This is part of your second project assignment. • In your group: • Read through the SOW • Identify and WRITE DOWN a list of Task Statements • Group the Task Statements into appropriate Task Areas

12. The Work Breakdown Structure (WBS) is a complementary way of defining the work • Sometimes this is provided by the customer • If so, it may be necessary to develop a “cross-walk” between the task statements and the WBS. For example, see Table 3.2, pg. 82. • If not, the WBS should be developed by breaking down the task statements into more detailed subtasks and work packages, as described in the next slides ...

13. The WBS organizes the work so that it can be assigned to specific organizational and budget areas • An hierarchical outline (map) that identifies the products and work elements involved in a project • Defines the relationship of the final deliverables to tasks, and in turn, their relationships to work packages • Best suited for design and build projects that have tangible outcomes rather than process-oriented projects

14. Hierarchical breakdown of the WBS May be the same if there is only one deliverable may be combined into a single level Lowest management responsibility level Grouping of work packages for monitoring progress and responsibility

15. For Example,

16. Another example, from: Gray & Larson (2008). Project management: the managerial process (4th ed.) McGraw-Hill Irwin. ISBN 978-07-352515-0.

17. Why Create the WBS? • WBS helps the PM by • Facilitating evaluation of cost, time, and technical performance of the organization on a project • Providing management with information appropriate to each organizational level • Helping in the development of the organization breakdown structure (OBS), which assigns project responsibilities to organizational units and individuals • Helping manage plan, schedule, and budget • Defining communication channels and assists in coordinating the various project elements

18. YOUR TURN... • This is part of your second project assignment. • In your group: • Break your task statements into subtasks (when appropriate) • Identify the specific work packages associated with each task or subtask • (optional) Assign each work package to a member of the team to manage.

19. The Technical Approach is a task by task description of how the work will be done • May be defined in detail in response to an RFP • i.e., part of a formal proposal (TCO 341) • if so, it is pulled from the proposal as part of the project plan • A narrative of what is to be done, why, where, when, and by whom • Starts from the beginning (developing the Project Plan) • Ends with the project close-out • Consistent with, but not identical to, the WBS • Include a description of the final product(s) from each task • see, for example, http://www.fayettecountyga.gov/planning_and_zoning/pdf/CTPGlatting-Jackson-Proposal.pdf

20. The Schedule puts the tasks and activities on a timeline • Allows the project team to maintain awareness of the schedule and potential problems • Identify critical path based on task precedence and time requirements • Include resource requirements • Is consistent with customer delivery requirements • The schedule in the body of the plan is a top-level overview • major tasks, not detailed work packages • detailed schedule is in the appendix and kept up to date online by the project management

21. The schedule serves as a visual reminder to the project manager and team • Two methods • Gantt chart • CPM or PERT

22. The Task Responsibility Matrix (TRM) identifies the personnel and time associated with each task • Developed from task list, WBS, and schedule • May be specific names or personnel types • Ultimately, the personnel must be named • The time required (in person-weeks) for each staffing category is derived from the schedule and WBS • Is used for staffing decisions and budgeting

23. The Budget is developed from this information and additional cost data • Direct labor • from TRM and hourly/weekly rates • include fringe benefits • Indirect costs • Overhead, general & admin (G&A), profit/fee, etc. • Vary by organization and contract type • Materials and supplies • Subcontract costs

24. The Risk Analysis focuses on identifying & mitigating potential problems before the project starts • Technical performance risk • What in the design, development, and construction of the system may result in not meeting the technical requirements set forth by the customer? • Schedule risk • What will cause the team to not meet project milestones? • Cost risk • Where have “guesses” regarding costs put the team at risk of not staying within budget? • Administrative risk • What administrative changes might affect the schedule or budget?

25. The risk analysis answers the following questions ... What specific risks are present for this project? What are the likelihoods of experiencing these risks? What are the likely consequences if indeed the risks occur? Based on 2 and 3, how can we prioritize the risks that have been identified? What can we do to minimize the likelihood of occurrence as well as the consequences of high-priority risks?