Processes and Tools for Planning a Program - 2

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.

Processes and Tools for Planning a Program - 1,

The first activity for systems engineers on a new product development program is to assist in planning the program. Although planning a program is the responsibility of the program leadership a product development program cannot be properly planned without systems engineering work. Program planning involves defining the tasks to be performed, scheduling the tasks and developing the planning documentation needed to guide the work and the workers. One of the primary reasons product development programs fail to achieve the expectations of management and customers is poor planning. This chapter presents processes and tools that reduce the chances that a product development fails to meet expectations due to poor planning.

This chapter discusses the various plans and documentation making up a product development plan, scheduling the development and touches on the important program management issues of design reviews and supplier relationships that involve systems engineering. This chapter does not distinguish whether systems engineering or program management is responsible for any specific plan item. That decision is up to the development team management. Allocating budget for each task and assigned people to each task are additional planning functions that are not treated here as these activities usually don’t rely on systems engineering other than for estimating the cost of the systems engineering work.

Product development programs are called projects here even though the term projects refer to both product and service developments. The planning for a new product or service development is similar so there is no reason to restrict this chapter to products; besides project is a shorter term than product development program.

Planning Documentation

Documentation is an integral part of project planning. Although not many projects fail due to poor documentation good planning documentation makes a project easier to manage and easier for the workers assigned to the project. Four types of documentation that are typically used on complex projects are discussed. These are the Integrated Management Plan (IMP), the Schedules, the Systems Engineering Management Plan (SEMP) and the System Design Document (SDD). The first three comprise the top level planning documentation. Of course there is considerable documentation needed to back up these top level plans. The SDD is not strictly a planning document but it should be started during the planning phase.

There are two ways to produce poor documents and one way to produce good documents. Poor documents are either so brief or poorly written that there is little useful information for managers overseeing the project and new workers assigned to the project or the documents are so long and detailed that no manager and few workers will ever read them. Surprisingly, most bad documents are those that are far too long to be useful. This is because the project leaders have slavishly followed advice to include everything but the kitchen sink description in these documents.

In the an earlier post it was stated that where ever possible labeled graphical models should be used rather than textual documents. Plans are one of the areas that require a significant amount of text. However, the goal should be to make as much of the plans as possible graphic models such as diagrams and tables. (Tables are included as graphic models here because they are less ambiguous than pure text.)

The Integrated Management Plan - A concise IMP is preferred because the IMP should be viewed as a “contract” between the project team and their senior management. Therefore the document need only address issues at a summary level. This allows the team and management to focus on the important issues without getting mired in detail. Mature organizations have standard procedures and processes for items like configuration management and product assurance. Management needs to know if any tailoring is needed for standard processes but they don’t need to wade through the details of standard processes. Certainly documents like a Product Assurance Plan are necessary but hopefully the organization is mature enough that the plan for any specific project is a tailored version of a standard plan.  Summarizing how the plan is tailored to the specific project is sufficient for the IMP. Any manager or worker that needs to know the details can read the detailed plan.

A good IMP is about ten pages long or less. If it is any longer it won’t be read by managers who are expected to have oversight of the project or by few workers that are assigned to the project. It is quite difficult to cover all the items that are recommended for an IMP in ten pages but it is far better to put effort into a good ten page document than to put even more effort into 80 pages that are never read. A template is provided here for a ten page IMP. Many books and web sites advise far more material be included in an IMP but it’s not effective to produce such tomes and it costs precious time and money to produce them. If a project leader insists that all the detail is needed then include a seven to ten page Introduction and Summary for managers because that is all they are likely to read.

The table shown here is an outline for a seven to ten page IMP. Your project may not have the same required items but this outline illustrates that a useful IMP can be ten pages or less. The suggested number of pages in this table adds to ten pages if the maximum suggested amount is used for every item. The recommended topics provide managers a concise overview of a project and are sufficient to orient new workers assigned to the project. If the resulting IMP is well written then, together with the project schedules, it provides senior managers all the information they need to conduct oversight that ensures that the project is progressing adequately or that the project leaders need help. New workers do need additional information but that is better provided in the SEMP and SDD.

Topic	Number of pages
Program Overview (Milestones, Deliverables with quality level required, Fit with Strategic Goals and a one page Top Level Schedule)	1.5 to 3 pages
Technical Description of System (Intended function, hardware/software overview and any make/buy issues)	1 to 2 pages (Include a top level System Breakdown Structure (SBS) and link to more detailed breakdowns in the SEMP.)
Key Performance Characteristics	0.25 to 0.5 pages (Include links to a Specification document for those needing more detail.)
Work Breakdown Structure (WBS)	1 page of top level only (Put the detail, if needed, in an appendix or link to a separate document, e.g. the SEMP.)
Cost target, Preliminary budget & Sources of funding	0.25 page
Staffing Plan (Preliminary manning forecasts, any critical resources, & any teaming arrangements)	0.25 to 0.5 pages
Key Assumptions	0.25 to 0.5 pages
Summary of major risks and plans to mitigate	0.25 to 0.5 pages and reference a risk register in an appendix
Inter-project cross feeds and dependencies	0.25 page
Capital and facility requirements	0.25 to 0.5 page
Status of Preliminary Support Plans (Configuration Mgmt. Plan, Product Assurance Plan, Environmental Health and Safety Issues/Plans, Logistics and Field Support, etc.)	0.5 to 1 page (Which are standard and which are to be tailored. Say why tailoring is appropriate.)

If an enterprise accepts the definition of the IMP as a contract between the project team management and the enterprise management then there is no reason that the IMP always be a text document. It may be acceptable that the IMP is a set of briefing charts that the team presents to the management and receives acceptance or guidance from the management at the end of the briefing. Since most briefings today use electronic data projected on a screen it is easy to include links to the more detailed plans just in an electronic text document. Including appropriate links to more detailed planning documents makes the briefing charts as complete as any text document.

There are several advantages to this approach. First, it is easier to prepare a set of briefing charts covering the topics of an IMP than it is to write a high quality document. Second, if the team can get the management to set through a briefing then there is no question about whether the management has read the IMP and there should be no question about whether the IMP is approved or not. Also, a briefing allows any ambiguities to be resolved in real time. Finally, the 80 page tome is discouraged because senior management isn’t likely to sit through a briefing that long.

A last but important reminder is to prepare the IMP using an IMP from a previous project as a template and strive to make the new IMP an even better template for future IMPs. This advice isn’t limited to the IMP. Where ever possible look for opportunities to build on previous work and structure work so that the result makes future work easier and faster. This approach to fundamental to executing systems engineering rapidly and accurately.

System Engineers in the Organization

Let’s assume a product development organization practices concurrent engineering and organizes in a set of interlocking teams. The top level team is often called the core team. A core team for a medium to large development program is composed of representatives from the major contributing functional organizations in the enterprise and might look like Figure 3-6.

Figure 3-6 A typical core team for a medium to large product development program has representatives from all the contributing functions.

A circle structure rather than a tree is used for the organization because each member of the core team is functionally independent and has responsibilities both to the product development or core team and to his/her functional organization. This means for example that the contracts representative operates within the team in the best interests of the product development program but is also constrained to follow the policies and procedures the parent organization defines for the contracts function. Similar rules apply to the other members of the core team. Each member of the core team is a leader of a support team, e.g. the engineering member of the core team is the lead engineer for the engineering team.

Now we can look at how the engineering work is organized and how its organization fits with the core team. This is shown in Figure 3-7.

Figure 3-7 The engineering integrated product team (IPT) is typically organized with a Systems Engineering and Integration Team (SEIT) and a number of teams responsible for the various systems or engineering functions such as software or test.

In Figure 3-7 SE stands for a systems engineer and DE stands for an engineering specialist other than a systems engineer. The engineering leader is called the project engineer, as in this figure, or chief engineer, or lead engineer. The leader of the System Engineering and Integration Team (SEIT) is usually called the lead systems engineer. The engineering IPT is thus composed of a number of subordinate IPTs, here labeled A through N, which are responsible for subsystems or for specialty functions like test or software. The systems engineers shown under the subordinate teams in Figure 3-7, or the subordinate team leaders, are members of the SEIT as well as their respective IPTs. If the system being developed is large and complex than there are likely many more layers of IPTs. Think of each of the DE blocks being an IPT with the SE block being a lower level SEIT.

Not explicitly shown in Figure 3-7 is how members of the operations team, the product assurance team and key suppliers support the engineering team and vice versa. In some cases it may be sufficient to only have the structure shown in Figures 3-7 and 3-8 but in most cases an operations engineer and a quality engineer should be a member of the SEIT and a member of the SEIT should be a member of the operations IPT and possibly the product assurance IPT. Usually an engineer knowledgeable about a supplier’s product is responsible for coordinating with the supplier and bringing the expertise of the supplier into the design process at each phase of the design work.

The principle to be followed in organizing the engineering team is to break down work so that at the lowest level IPT the craftsman model applies. This is the work assigned to each of the lowest level IPTs can be thoroughly understood by the team leader. Thus the team leader is a “chief engineer” for the work assigned to his/her team.

The nesting of interlocking IPTs can continue as necessary to handle the size and complexity of any large system. This nesting of teams reduces the time non managers spend in communications meetings. In the three tier example shown in Figures 3-7 only the lead engineer, here called the project engineer, needs to attend core team meetings although sometimes the lead systems engineer may attend. Engineering coordination meetings are held at two levels. The project engineer meets with all the team leaders and then the team leaders meet with their respective teams. This approach limits the amount of time workers spend in coordination meetings and limits the meeting topics to just those items of interest to each team. Few things are more frustrating to working engineers than having to sit through meetings on topics that are of little or no interest to them; plus it’s a waste of time and money to have working engineers sitting in nonproductive meetings.

Product development programs usually have documentation called a work breakdown structure (WBS) that assigns code numbers to various elements and  phases of the  work so that budgets can be generated and managed. The WBS can map to the organization to facilitate cost management although this is not a strict constraint.

Figure 3-7 shows that there is systems engineering specialty work to be done in each of the subordinate IPTs even if the person doing the work is called a design engineer rather than a systems engineer. Some design engineers think that they don’t have to do systems engineering work, which just isn’t true. They do systems engineering work even if they don’t use all of the tools used by systems engineering specialists. Since a system is always part of a larger system then there is systems engineering work in all product development at all levels of “systems”. Even though an engineer is developing the design for an assembly or component of a system there is systems engineering work required. Of course this systems engineering work must be tailored to the level of complexity of the design element.

Systems engineers can perform a variety of roles on IPTs, from lead systems engineer to contributing engineer or analyst on one or more other teams. Since the IPTs are multidisciplinary, it is critical that the systems engineers understand their roles and responsibilities on each team. A good practice is to hold roles and responsibilities meetings with all members of an IPT as soon as the team is staffed.

The engineering team for a small product development program can be simplified from that shown in Figure 3-7. An example of an engineering IPT for a small project is shown in Figure 3-8.

Figure 3-8 The engineering IPT for a small development program can be simple with the engineers having responsibility for both systems engineering and design engineering.

Figure 3-8 shows an engineering IPT with just seven engineers; a project engineer (PE), a system engineer (SE), an electrical engineer (EE), a mechanical engineer (ME), a quality engineer (QE), an operations engineer (OE) and a test engineer (TE). This organization might be sufficient for developing the design of a small electrical or electro-mechanical system. Note that this organization clearly illustrates the multidisciplinary nature of IPTs and is what might also be used on one of the subordinate IPTs of a large development program.