Project Schedules - There are two types of schedules defined in IEEE 1220 and DoD nomenclature. One schedule is called the Master Schedule in IEEE 1220 nomenclature and the Systems Engineering Master Schedule (SEMS) or Integrated Master Schedule (IMS) in DoD nomenclature. It is an event driven schedule and is not an executable schedule; it is used by the program management for communicating status and to guide the development of detailed executable schedules. The Master Schedule maps to the WBS, identifies major milestones and deliverables.
The second type is executable, tied to calendar dates and is called the calendar schedule. The calendar schedule is also called the detail schedule or systems engineering detail schedule (SEDS). This schedule is used to develop earned value metrics for government contracts. The NASA Systems Engineering Handbook refers only to one schedule; called the network schedule, which is the same as the detail or calendar schedule. The NASA Systems Engineering Handbook provides instructions for planning and developing the schedule whereas the DoD and IEEE 1220 documents for systems engineering only discuss the planning that systems engineers must do to enable schedules to be developed.
Three schedules are necessary to achieving effective project control and communication with management and customers. First there is the Master schedule as defined by IEEE and DoD. Some slight modifications to the DoD definition are desirable. First, limit the Master schedule to about two levels for most projects. The Master schedule can then include the major phases of the planned work, the management reviews that typically gate the initiation of the next phase and the deliverables, including any long lead items that are on the critical path, and other selected items that drive the schedule. This usually permits a Master schedule to be displayed on a single page, which greatly simplifies communications with senior management.
Second tie the events to calendar dates since most customers for new product developments specify delivery dates. The reality is that product development teams typically must plan a project that meets some schedule constraints. Customers may claim they want an event driven rather than calendar driven program but it’s rare that they actually do. Also the team has less incentive to develop work arounds to hold schedule and cost if the project is truly managed as event driven. These constraints are clear to everyone if they are included in the Master schedule. Finally, use the term Master Schedule and not the terms Integrated Master Schedule (IMS) or SEMS or SEDS. The detail schedule, or network schedule as NASA calls it, is the integrated schedule and both the Master schedule and the detail schedule apply to more than the systems engineering work.
The second schedule is the detail schedule; it is an executable schedule that is calendar driven and is used by the project management, task leaders and workers. It contains all task levels and should have measureable milestones about every one to two weeks to facilitate tracking progress. It is resource loaded, should identify critical resources and allow for contingencies, i.e. lead and lag times (float in NASA nomenclature) should be maximized as much as schedule constraints allow and the critical path should be identified.
The third schedule is a weekly task schedule prepared by each worker and used by the worker to schedule his/her work in order to meet the milestones on the detail schedule. The schedule can be on a 3 x 5 card or any other tool that the worker finds effective. This schedule must be more than a list of tasks. Workers should schedule their time hourly for an entire week at a time and with contingencies to account for the unexpected interruptions that will happen. Many experienced engineers do this automatically but young or inexperienced engineers may need mentoring before they develop the habit of scheduling by the week.
The detail schedule is a critical document to get right because it is the primary tool used to assign budgets and workers to the project and to track the work compared to planned schedule and budget. Both the Master schedule and the detail schedule must map to the Work Breakdown Structure (WBS) that assigns tracking codes to each task for the financial management system in use. The WBS should be based on the hierarchical structure of the product and processes, i.e. the Product Breakdown Structure (PBS) in NASA nomenclature, or System Breakdown Structure (SBS) in IEEE 1220 nomenclature, so that it is tied as much as possible to physical products rather than functions. Readers are referred to section 4.3 of the NASA Systems Engineering Handbook (down load from http://nen.nasa.gov/nasa_nas/ops/systems_community/NASA_SP-2007-6105_Rev_1_Final_31Dec2007.pdf) for a discussion of how to structure the PBS and WBS.
The detail schedule must have all the links and precedent relationships between tasks identified. Fortunately there are software tools, like MicroSoft Project, that facilitate preparing a detail schedule. Such tools are sophisticated and considerable experience is needed to utilize them properly. This often results in persons with skills in the scheduling tool being assigned to prepare or assist in the preparation of the schedules, which can lead to problems, as described next.
A big mistake inexperienced project leaders make is scheduling the project before the tasks are defined. It’s ok to develop the Master schedule before defining and structuring lower level tasks that belong in the detail schedule because often Master schedules contain project constraints that must be accommodated. Inexperienced project leaders sometimes try to combine two planning steps by listing the tasks to be performed and working out a detail schedule for the list or even developing the task list on the fly using the scheduling tool. Defining tasks should be done first, at least for complex projects, because it’s not obvious how tasks should be sequenced and structured until tasks are fully defined. Defining tasks means defining the inputs, the tasks that are the sources of the inputs, the outputs and the tasks the outputs support. Defining tasks is work that requires analysis by systems engineers, design engineers and operations personnel. Just having a list of tasks does not mean that the inputs, outputs and the work needed to turn inputs into outputs are understood. It should be obvious that schedules constructed without such understanding are not likely to be executable without numerous corrections.
Another big mistake inexperienced project leaders often make is requiring detailed schedules for entire projects as part of the beginning planning. This is a mistake because there is insufficient information to construct such detailed schedules so that a detailed schedule becomes useless within a month or two and re-planning is required. A rolling wave scheduling process that avoids this needless rework is described after discussing tools for defining tasks.
No comments:
Post a Comment