■ 2.13 Given a project planning-scenario, demonstrate an understanding of and the ability to plan for iteration by:
o Identifying elements likely to require it o Explicitly deciding to provide for iteration in the project plan (e.g., scope approval, plan approval, project design, final deliverable turnover, etc.)
■ 2.14 Given a scenario involving tasks, resources (fixed or variable), and dependencies for a multi-phase IT project, demonstrate knowledge of the standards for creating a workable WBS. ■ Recognize and explain the need to creatively visualize all deliverables (interim and finished) and thoroughly decompose the system into all potential hardware and software components.
■ 2.15 Recognize and explain the need to obtain 1) consensus among all stakeholders regarding project deliverables and other elements of the WBS, and 2) formal approval (sign-off) of project sponsor(s) regarding project deliverables and other elements of the WBS.
■ 2.16 Given a project scenario with many phases and activities, set realistic, measurable milestones, and demonstrate understanding that measurable targets are required in order to determine if the project is proceeding on time and within budget.
■ 2.17 Given a set of specific milestones and their descriptions, specify entry and exit criteria for each.
■ 2.22 Identify the components of an adequate project plan and explain the function of each. Components include: o Table of contents o Overview o Sponsors o Team members o Requirements o Scheduled tasks (WRS) o Expected resources o Environmental issues o Business requirements o Implementation plans o Support plans o Training plans
■ 2.23 Identify the steps involved in organizing a comprehensive project plan and using it to close out the planning phase of a project, including:
o Assembling all project planning elements (estimates of deliverables, time, costs, etc.) o Creating an outline or table of contents for the comprehensive project plan o Reviewing the outline of the comprehensive project plan with sponsor and key stakeholders, obtaining feedback and concurrence, and revising as needed o Writing the comprehensive project plan by integrating all planning elements according to the outline and creating a full document with transitions, introductions, graphics, exhibits, appendices, etc., as appropriate o Circulating the comprehensive project plan to all stakeholders o Obtaining top management support of the comprehensive project plan by making certain it reflects their concerns and that they have had an opportunity to provide input o Conducting a formal review of the comprehensive project plan in which stakeholders have an opportunity to provide feedback o Adjusting the comprehensive project plan based on stakeholder feedback o Obtaining formal approval (sign-off) of the comprehensive project plan by sponsor(s) Project managers live and die by the work breakdown structure (WBS). It is the mortar that cements the project plan together into a cohesive unit. In this chapter, I' l l talk extensively about the WBS and then a bit about finalizing your project plan.
You may have to work with a WBS for a while to know how far to go with it. It's a Zen kind of thing. You start with your list of deliverables and decompose them into the elements that will make each deliverable complete—a reverse-engineering approach. But you don't get too deep in the process. There's an art to finding the right balance. A WBS to build a car, for example, won't have a task as detailed as, "Screw six lug nuts onto each of the wheels." The expert performing the task knows how many lug nuts go on each wheel, so you can leave this as, "Install lug nuts." Your WBS should boil the tasks, activities, and phases that make up a deliverable down to basic elements that you can effectively manage. The WBS isn't about microscopic detail; it's about the parts, components, or factors of the deliverables.
Was this article helpful?